FYI you can reproduce this from scratch in Visual Studio 2012 like this:

1. Create a New project of type "ASP.NET MVC 3 Web Application" using .NET Framework 4
2. Add a reference via Nuget to "Async for .NET Framework 4, Silverlight 4 and 5, and Windows Phone 7.5"
3. Create a class and method and in it put: "TaskEx.WhenAll(null);"

Visual Studio will compile and nCrunch will give something like "Class1.cs (13)#0: The name 'TaskEx' does not exist in the current context"

Incidentally this scenario works fine for command line projects, so it must be something specific to web projects. I noticed the project modifies the web.config to add some assembly bindings like this:

<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" />
</dependentAssembly>

But that shouldn't have anything to do with the compiler, right? Anyway, I would love some help here, nCrunch is awesome and I'd really like to get it back as asap.

Thanks,
Lee

Thanks for the response and analysis Remco. I would imagine my main project would be harder to debug. I am surprised about the conflicting MVC versions, that shouldn't be the case, I'll look into it. But for now let's focus on the simple out of the box project that I mentioned in post #2.

Since those repro steps don't work for you I tried upgrading from nCrunch 1.45.0.12 to the latest (1.46.0.11) but sadly that didn't help. Next I uploaded the sample project (DeleteMe.sln) to the contact form you mentioned to see if that works for you. It shouldn't be any different since I just followed the steps in #2, but maybe we'll get lucky and it will fail for you.

Assuming DeleteMe.sln works for you, what other external things could be different? machine.config? Version/Edition of Visual Studio?

Thanks again for your help,
Lee

Thanks for sending through the sample solution. This wasn't easy to figure out, but I think I've established what is happening here.

The binding redirection in the Web.config file is critical to the build for this project, as it looks like these libraries have some dependency issues and they rely on build-time redirections to sort these out.

In order to make these binding redirections work inside the build process, the package includes a special build step (inside Microsoft.Bcl.Build.targets) that overrides normal .config resolution behavior to make it work with web applications and find the web.config - which explains why this has been failing for you on the web application and not on the console app.

NCrunch has been unable to find the Microsoft.Bcl.Build.targets file because the logic used to import it into the project is using a relative path that makes a dangerous assumption about the working directory of MSBuild. Build imports usually make use of MSBuild variables to specify a root path when importing a project (i.e. "$(MSBuildProjectDirectory)\..\packages\Microsoft.Bcl.Build.1.0.7\tools\Microsoft.Bcl.Build.targets"), although this one is just straight relative to an unrooted location (..\packages\Microsoft.Bcl.Build.1.0.7\tools\Microsoft.Bcl.Build.targets), which in most build situations (excluding NCrunch) seems to be consistent with the project's directory.

The Microsoft.Bcl.Build.targets file further introduces more assumptions about the working state of the MSBuild process by checking for the existence of files without specifying a root location for these files (assuming that the MSBuild default will always be the same directory as the host project, which is not necessarily true).

Basically, this framework has been coded with a number of assumptions about build state that just don't hold during an NCrunch build. I've introduced some pending fixes to NCrunch to try and align this better with the defaults that this framework is expecting, but I can't get it 100% as NCrunch still relies on the MSBuild API which does not seem to behave consistently with what this project expects.

So anyway, to work around the issue, just add this to your project file:

<PropertyGroup>
<AppConfig>Web.config</AppConfig>
</PropertyGroup>

This crudely replicates the workaround in the imported framework to make use of the Web.config so that the binding redirections will kick in.

I hope this does the trick!


Cheers,

Remco

The PropertyGroup hack above in theory shouldn't be needed for App.Config files, as the Bcl build above should be able to detect these by default. I think this is the results of another problem. Does putting NCrunch into compatibility mode make any difference?

Sorry for the lack of notification from the forum. It seems to be having some issues at the moment - I'm looking into it.

Thanks again for the sample solution. I'm having some trouble in reproducing the issue. It seems as though the sample solution isn't bringing it out for me. It builds and runs the single test correctly under NCrunch with no signs of any error.

Strangely, it doesn't build outside of NCrunch. When I try build using Visual Studio, it complains about the tests project not referencing Microsoft.Build.Bcl. I guess NCrunch's resolution logic must somehow work around this.

Are you able to share any more detailed information, or perhaps a sample project with a different arrangement that might surface the issue? The sample you sent for the Web.Config issue was very useful - there's no way I could have come up with the workaround without it.

Hi Lee,

I was testing this using 1.46.0.20 in a clean VM. I'm wondering if somehow the issue may be related to the SDKs or frameworks you have installed on your machine. Build behaviour can be affected by a huge range of factors outside the solution itself. Are you able to share any details on the setup you're using? Which versions of Visual Studio and the .NET framework do you have installed? Are you testing using VS2012 or the VS2013 preview?

I'm hoping we can avoid the need for you to build a whole VM just to surface this issue.. it's a bit of a job. Is there any chance you can submit a bug report right after the build has failed? I'd really like to see a full build log if we can get one.


Thanks!

Remco

Thanks for sending the bug report. This helped highlight some interesting information:

The primary reference "C:\Users\Lee\AppData\Local\NCrunch\17572\1\MvcApplication1\bin\MvcApplication1.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "C:\Users\Lee\AppData\Local\NCrunch\17572\1\MvcApplication1\bin\MvcApplication1.dll" or retarget your application to a framework version which contains "System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

The primary reference "C:\Users\Lee\AppData\Local\NCrunch\17572\1\MvcApplication1\bin\MvcApplication1.dll" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "C:\Users\Lee\AppData\Local\NCrunch\17572\1\MvcApplication1\bin\MvcApplication1.dll" or retarget your application to a framework version which contains "System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

I'm wondering if this is somehow related to the binding redirection issue we experienced earlier. It still doesn't make any sense to me why this is appearing on your system but not mine... Perhaps there is some difference in the various SDKs that are loaded or available in the GAC. Does introducing a .config file in the tests project with the appropriate binding redirections make any difference for you?

I'm wondering if you'd also like to try giving this build a spin - http://downloads.ncrunch.net/NCrunch_VS2012_1.47.0.1.msi. This build introduces some changes in the way that references are resolved at load time by NCrunch... which may or may not make a difference in this situation.

These new packages from Microsoft contain all sorts of new build logic including several overrides, so I have a feeling it may take a while to fully understand what is happening here. Let me know how you go with the above suggestions, and if neither of them work, we'll try something else.

Excellent! Just to clarify - was it the app.config change that did the trick, or the new build, or both?

Great. Thanks for letting me know. I've noted this down for a review, as if things were working correctly, such a change shouldn't really be necessary.