MissingManifestResourceException when using 4.6.25-alpha in UAP

[corsairmarks]

It appears the Times.*() methods use a *.resx file to hold their string resources. That apparently won't work in UAP/UWP.

Notably, this breaks doing things like:

myMock.Verify(m => m.Method(), Times.Once);

A potential solution is moving to using *.resw files instead. I'm not sure how that would affect backwards compatibility.

I have an repo where I can point at code causing this exception when running xUnit tests for a UAP library. Please let me know whether that would be helpful and I'll link it here if so.

[corsairmarks]

I found some potential helpful advice from 2014 when this was discovered to be an issue with WinRT as well.

https://blogs.msdn.microsoft.com/philliphoff/2014/11/19/missingmanifestresourceexception-when-using-portable-class-libraries-within-winrt/

If this sounds like a good solution, then I'm happy to help contribute to the branch targeting UAP/UWP.

[kzu]

Interesting, thanks for sharing that!

I'd suggest a slightly less hacky approach: mark the Resources file for
public class generation (from within the resx designer itself).

Add a partial class extending the generated one that exposes a
SetResourceManager(...) method, which would allow anyone to call to
override that behavior (I.e. your code that runs the tests in a UWP device).

How does it sound?

On Fri, Jul 22, 2016, 11:52 AM Nick Butcher notifications@github.com
wrote:

I found some potential helpful advice from 2014 when this was discovered
to be an issue with WinRT as well.

https://blogs.msdn.microsoft.com/philliphoff/2014/11/19/missingmanifestresourceexception-when-using-portable-class-libraries-within-winrt/

If this sounds like a good solution, then I'm happy to help contribute to
the branch targeting UAP/UWP.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#274 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKW62OZIC70fsiW3eqDvMwQiq16wx2Lks5qYNk_gaJpZM4JRQ-X
.

/kzu from mobile

[corsairmarks]

That's a great idea. What branch is the UWP-compatible one so I can target my code at the right place? netcore?

I've forked the repo and I'll test this idea there.

[kzu]

netcore should be the right one, yes.

Thanks!

On Fri, Jul 22, 2016 at 1:12 PM Nick Butcher notifications@github.com
wrote:

That's a great idea. What branch is the UWP-compatible one so I can target
my code at the right place? netcore?

I've forked the repo and I'll test this idea there.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#274 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKW6ztSH9VcTYu4bUjKEswzkaszBEZ1ks5qYOwHgaJpZM4JRQ-X
.

/kzu from mobile

[achocron]

This still seems to be an issue in the latest stable release. Is there any workaround?

[stakx]

@achocron: Meaning, do you get a MissingManifestResourceException, or just the warning about a missing NeutralResourcesLanguageAttribute?

[stakx]

[M]ark the Resources file for public class generation (from within the resx designer itself). Add a partial class extending the generated one that exposes a SetResourceManager(...) method, which would allow anyone to call to override that behavior (I.e. your code that runs the tests in a UWP device).

I was going to take a look at this, but the resource generator doesn't add a partial attribute to the generated class (cast a vote on UserVoice to have this changed), so it's probably impossible to let people install their own UWP-compatible ResourceManager.

I also don't know whether .resw files are even understood by the build tools if you don't target a project at the Windows Universal Platform. VS doesn't offer a project item for .resw files, either way.

Other options:

• Write our own (maybe strongly-typed, maybe not) resource class instead of having it generated, and put an extensibility point in there for swapping out the ResourceManager used.
• Don't use resources at all. Just hard-code all strings in code. (Or has anyone created a localized version of Moq already?)
• Let Microsoft fix that bug.

I find none of those options very appealing.

@corsairmarks, did you by change ever find a solution when you were looking at this issue?

[corsairmarks]

@stakx I never circled back, sadly.

I can offer this additional comment on .resw files: at present, the file is exactly the same as .resx. I can't find the exact docs, but I recall reading it on MSDN somewhere.

As a fourth option, would it be possible to work around this by, at build time, copying the .resx files to files of the same name as .resw, and then generate the netcore assemblies?

The reason this came up for me is that in order to test UWP assemblies (even libraries), the tests have to run as a UWP app.

[corsairmarks]

I believe .resw files were introduced with Win RT (alongside Win 8). https://msdn.microsoft.com/en-us/library/windows/apps/hh694557.aspx I think its Windows Store apps, not explicitly UWP (since Windows Store was first on Win RT, and UWP appears to be an outgrowth of Win RT at this point).

In any case – I believe we’d get the same output running a .resw through resgen, since that's what it's using according to the linked article.

If I’ve got some spare time soon, I’ll try a couple variations in my fork of the repo and see what we get and what trade-offs there are.

[stakx]

@corsairmarks: That would be welcome. I am currently not set up to experiment with Windows Runtime development.

I also believe that just changing the file extension won't achieve anything as long as the same build tool processes it. And if processing the resw results in a .pri file getting created, .NET 4.5 & .NET Core likely won't be able to use it since they're missing the ResourceLoader class.

I think completely giving up a resources file would be a pity, but perhaps justifiable on the grounds that many messages in the code base are already hardcoded into code. Giving up a resources file however should be a last option if it's the only way to unblock UWP.

[corsairmarks]

Enabling localization capabilities is always a good goal, in my opinion.

[stakx]

Closing this due to a lack of activity. Given that Moq doesn't offficially support UWP and even a hacky, reflection-based approach by which ResourceManager is exchanged for a ResourceLoader-based implementation, we'd have to keep all string resources around in double (once as embedded resx, once as a pri file). Not exactly neat, we're probably better off not solving this in a hacky way.