I have a .NET Assembly, which contains resources. And I have a dotnet core 2.1 UnitTest Project.

In the Unit Test i try to access the resources. this works fine in Visual Studio, ReSharper and via dotnet test.

But not in NCrunch, if i look in the temp folder of NCrunch then the satellite resource assemblies are missing.



Result of dotnet test


Here is the Sample solution
https://1drv.ms/u/s!AmXNl8dqs5HUpMpSHg7qHwCfZsciyQ

Also, i add the missing assemblies in the ncrunch configuration for the test project, the satellite assemblies get not updated reliable and have old values in there (after saving the resource files files, and running tests again, even manually). But there seems only dotnet test run fine. even resharper and visual studio have problems with that.

Thanks for sharing this problem.

This looks to be a classic case of framework code assuming that dependency DLLs are collocated with the project's output assembly. Turning on the 'Copy referenced assemblies to workspace' seems to resolve this problem.

The root of the issue is that the ResourceManagerStringLocalizerFactory assumes that 'TheLibrary.dll' is sitting adjacent to 'nCrunchNETCoreLocalizationTests', which just isn't the case when you're working with NCrunch's optimised build.

There are two ways to solve this problem:

1. Turn on 'Copy referenced assemblies to workspace' then deal with the degraded performance that comes with this setting

2. Find a way to tell the ResourceManagerStringLocalizerFactory where to load the external resources from. It looks like this class has an alternative constructor that allows you to inject an option specifying relative file path. Could it be possible to force it to load from somewhere else?
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.localization.resourcemanagerstringlocalizerfactory.-ctor?view=aspnetcore-2.1
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.localization.localizationoptions?view=aspnetcore-2.1

When the 'Copy Referenced Assemblies to Workspace' setting is enabled for a project, NCrunch will always copy its references to the project build output directory. This means that TheLibrary.dll lands inside NCrunchNETCoreLocalizationTests\bin\Debug\netcoreapp2.1, and its satellite assemblies are also accordingly underneath this path.

Because both TheLibrary and its satellite assemblies now need to be copied by MSBuild into the output directory for NCrunchNETCoreLocalizationTests, it isn't possible for us to make any kind of code change to TheLibrary without re-copying its output files into the output directory of NCrunchNETCoreLocalizationTests. The copying of these files is handled by build steps inside the NCrunchNETCoreLocalizationTests project. Therefore, whenever TheLibrary is changed, NCrunchNETCoreLocalizationTests must be rebuilt. This is the normal behaviour for MSBuild, which under NCrunch we try to suppress by default because we can provide test results faster when we only need to build a minimal number of projects after the code is changed.

When there are other projects referencing NCrunchNETCoreLocalizationTests, the issue gets bigger, because any code running in these projects would likely be using the same resource code in NCrunchNETCoreLocalizationTests, and therefore would have the same constraints. So these projects would likely need to be rebuilt too. So instead of building just TheLibrary when it changes, we need to build TheLibrary and everything else that depends on it. Then everything else that depends on that. Once again, this is the default behaviour of MSBuild, and it's one of the main reasons why NCrunch is able to run tests so much faster than other runners. When possible we try to be more selective with what we build.

You could make the argument that the resolution of resources at run time is extremely common, so NCrunch should implement a special mechanism to handle copying of these resources to referencing projects without the need for a build step. Such a thing could certainly be implemented, but it would be very challenging and expensive to do so, because it involves breaking a number of abstractions in the build system that would further expose us to breaking changes introduced at platform level. From the side of NCrunch, a better solution would be to instead find ways of improving performance in general so that we can build projects faster.

Above all, the best solution would be to find a way to tell the ResourceManagerStringLocalizerFactory where it needs to look for the assembly it's trying to find. If you can find a way to pass the path of the dependency into this component, the problem is entirely resolved. You can easily find the resource assemblies by using the location of the assemblies NCrunch has already loaded into the current application domain (i.e. typeof(ExternalResource).Assembly.Location). Alternatively, you can use the routines in NCrunch.Framework to find them. Here's some more information about how this can be done.