Cannot get Rx.NET to work with NCrunch

Hi,

I'm getting several different errors trying to get Rx.NET to work with NCrunch. It all builds/tests correctly in VS and in the xunit console runners.

You can see it here:

https://github.com/Reactive-Extensions/Rx.NET/
checkout the add-ncrunch branch

Open Rx.NET\Source\System.Reactive.sln

You will need the UWP workload installed btw.

Error 1: NCrunch is erroring out building uap10.0 things that are part of the projects.
Error 2: System.Reactive.dll, Microsoft.Reactive.Testing.dll and System.Reactive.Observable.Aliases.dll are not copied to the workspace directory. Can't figure out what config would make that work either. Those need to be in the workspace directory as the tests create appdomains and hence are failing in NCrunch. I've tried the suggested options of copying referenced projects to the workspace, pre-loading assemblies, etc. No dice.

Thanks!

Hi,

Sorry but universal windows applications are not currently supported by NCrunch. Are the problems you are encountering related only to UWP projects?

Hi,

I don't expect UWP to work directly with NCrunch, but the library itself multi-targets it:

https://github.com/Reactive-Extensions/Rx.NET/blob/develop/Rx.NET/Source/src/System.Reactive/System.Reactive.csproj

One thing NCrunch can do to improve perf is to pass /p:TargetFramework= foo and not try to build all TFM's.

The other issues I'm hitting are related to App Domains -- namely that it cannot load System.Reactive.dll and when I look at the AppDomain.Current.BaseDirectory, indeed it's not there.

From v3.6, NCrunch supports multi-targeted projects by splitting them out into virtual projects within the engine. This naturally means that each target will be built independently. Forcing the engine to work with a single target would greatly restrict the application of the engine (essentially regressing to v3.5).

If you wish to disable a target framework for NCrunch, you can use a build override inside the .csproj file to give a different <TargetFrameworks> element under NCrunch.

For example:

<TargetFrameworks Condition="'$(NCrunch)' == '1'">netcoreapp1.1;net462</TargetFrameworks>
<TargetFrameworks Condition="'$(NCrunch)' != '1'">netcoreapp1.1;net462;uwp</TargetFrameworks>


The problem you're experiencing with app domains is likely to be an implicit dependency on referenced assemblies being in the build output directory. See here for information on how to solve this: http://www.ncrunch.net/documentation/troubleshooting_tests-that-build-their-own-appdomains.

I really don't like the idea of putting tool specific information in my project file like that. It would be much cleaner if NCrunch could read the TFM list and then use a /p:TargetFrameworks=foo parameter as it builds and can filter out only the TFM's it supports (net and netcoreapp). Then projects don't have to adapt to a tool.

For AppDomains, I tried the items on that page, setting "copy referenced assemblies to works pace" but that didn't work. The referenced assemblies were NOT in the workspace directory and that's the problem.

onovotny wrote:I really don't like the idea of putting tool specific information in my project file like that. It would be much cleaner if NCrunch could read the TFM list and then use a /p:TargetFrameworks=foo parameter as it builds and can filter out only the TFM's it supports (net and netcoreapp). Then projects don't have to adapt to a tool.

As the situation stands, support for this feature has been around for just 5 days, so this is still a very immature feature. You may need to make some compromises here for the time being.

NCrunch actually does read the TFM list, and injects the individual target frameworks into the build in a similar manner to what you've described. This is how it is able to build the project targets independently. The problem is that there is currently no way to specify which target frameworks should be built by NCrunch vs the default. It isn't safe for NCrunch to assume which TFMs it supports and which it doesn't, as we need to factor in forward compatibility for new frameworks that MS release. The ideal solution to this would be to have NCrunch's configuration system factor in the TFM when it generates the configuration file for each project. In this way, we could have a separate config file for each TFM for each project, allowing you to turn on the 'Ignore this component completely' setting on frameworks that you want NCrunch to leave alone.

onovotny wrote:
For AppDomains, I tried the items on that page, setting "copy referenced assemblies to works pace" but that didn't work. The referenced assemblies were NOT in the workspace directory and that's the problem.

Make sure you turn on this setting for all projects in the dependency chain, as using it on only a top level project may still result in some assemblies not being copied to the output directory (dependencies of dependencies).

> As the situation stands, support for this feature has been around for just 5 days, so this is still a very immature feature. You may need to make some compromises here for the time being.

Totally get it and making that change worked. Was making a suggestion as an enhancement for NCrunch to detect/work better for projects that contained unrecognized TFMs for future releases :)

For the AppDomains, setting "copy referenced assemblies to workspace" on all projects in the chain did the trick. I only had it on the Test project before as it wasn't clear that I had to do the rest.

Thanks for your help, Rx is now all set with NCrunch!
https://github.com/Reactive-Extensions/Rx.NET/commit/0f38563c169217d1ea732ee47a08ab7f91e2ea48

Hmm...actually, spoke a little too soon. While using a conditional on the TargetFrameworks element allowed NCrunch to work, I had tons of other issues within P2P refs in VS. The UWP -> System.Reactive project wouldn't even build that way. I don't think conditionals will work here :/

I'll have to wait until NCrunch can either filter out unknown/unsupported TFM's or maybe provide an arbitrary MSBuild override so I can specify /p:TargetFrameworks=foo;bar that the NCrunch build uses.

onovotny wrote:Hmm...actually, spoke a little too soon. While using a conditional on the TargetFrameworks element allowed NCrunch to work, I had tons of other issues within P2P refs in VS. The UWP -> System.Reactive project wouldn't even build that way. I don't think conditionals will work here :/

Sorry, just to confirm.. is VS taking issue to the build condition workaround I described? So NCrunch builds OK but VS doesn't?

I saw issues both with VS IntelliSense, VS Builds and with R#. I suspect R# was the same underlying issue as VS as R# gets much of its data from the VS object model. NCrunch was the only thing that built ok in that case :/

Ok, try this:

1. Create a file adjacent to the project file. Call it 'ncrunch.targets'. Place inside it:

<Project xmlns="(- BROKEN LINK -)">
<PropertyGroup>
<TargetFrameworks>place;supported;targets;by;ncrunch;here</TargetFrameworks>
</PropertyGroup>
</Project>

2. Add a line to the bottom of the .csproj as such:

<Import Project="ncrunch.targets" Condition="'$(NCrunch)' == '1'" />


In theory, this should sidestep any parsing being done by VS/R#, while still allowing you to override the TFMs for NCrunch.