We are motivated to move away from the old .csproj + project.json for our net462 projects.
Building, discovering, running and debugging works perfectly in VS2017 RTM (NUnit test adapter extension installed) and in ReSharper 2017.1 EAP 4.
NCrunch 3.5 (and NCrunch 3.2) builds but does not discover any tests.
One of my test projects is now working properly with NCrunch. The only weird thing with this project is that it gives this warning, even though .NET Core is not in the picture:
I'm used to nuget restore and msbuild /t:restore; I'm not familiar with dotnet restore being used on a .NET Framework-only project. So I was surprised, but anyhow.
The rest of my test projects do not build at all with 3.6. All the errors are of the form "The type or namespace name '*' could not be found (are you missing a using directive or an assembly reference?)"
However all the errors point to missing third-party GAC-referenced assembles. They are not NuGet references.
Would it be helpful if I put together a repro for either of these scenarios?
jnm236 wrote:
One of my test projects is now working properly with NCrunch. The only weird thing with this project is that it gives this warning, even though .NET Core is not in the picture:
I'm used to nuget restore and msbuild /t:restore; I'm not familiar with dotnet restore being used on a .NET Framework-only project. So I was surprised, but anyhow.
I think I can see how this would happen. I'll see if I can do some tuning on this.
jnm236 wrote:
The rest of my test projects do not build at all with 3.6. All the errors are of the form "The type or namespace name '*' could not be found (are you missing a using directive or an assembly reference?)"
However all the errors point to missing third-party GAC-referenced assembles. They are not NuGet references.
Would it be helpful if I put together a repro for either of these scenarios?
If you could, that would be really great. I'm not sure how MSBuild could fail to resolve a GAC reference. This one has me a bit confused.
For the GAC issue, I actually don't think it's your fault. See my second comment:
https://github.com/dotnet/roslyn-project-system/issues/1739#issuecomment-286236502
Somewhere in the course of fixing the GAC issue and other issues like this one, the dotnet restore warning has disappeared too.
jnm236 wrote:For the GAC issue, I actually don't think it's your fault. See my second comment:
https://github.com/dotnet/roslyn-project-system/issues/1739#issuecomment-286236502
Somewhere in the course of fixing the GAC issue and other issues like this one, the dotnet restore warning has disappeared too.
I'll let you know if I can reproduce it again.
This is very interesting. It does definitely feel like assembly referencing is a bit of a mess at the moment.
MS do seem to be moving away from the GAC. I would hope that this move doesn't break too much backwards compatibility.
I have an odd behavior, no idea if it is related. One of the test projects ran (which are all CPS now) and a single test failed. I ran the test a bunch more times.
Later on, NCrunch stopped running tests for that project and I saw that it the project was failing to build. It was giving the good old "file is in use, try 3 of 10" kind of thing.
So I closed Visual Studio and reopened it. Not NCrunch says the project is failing but gives no error. I used the "Resync, rebuild and rerun all" button and it still wouldn't build.
Builds fine in VS.
I tried Advanced > Browse to workspace last built for selected project and nothing happens when I click it.
I'm not sure why that would persist across a restart of VS. Next I'm going to try rebooting.
Edited a file to make it it fail to build in VS. To my surprise, it failed in NCrunch with the correct error message. So I fixed the intentional error. Then the project built in VS but not in NCrunch. NCrunch shows the same error message that it did back when the file had the error.
Hang on, hang on... I reverted all edits to the test and NCrunch started building the project again. I have a hunch it doesn't like my local functions.
Yep, confirmed. Project builds fine in NCrunch until I add an empty local function. Then it gives "Beginning retry 1 in 1000ms. The process cannot access the file 'x.dll' because it is being used by another process." and eventually fails all 10 times.
One time just now I saw it build successfully with an empty local function, so I have no idea why it's not consistent.
What is consistent is that if I remove all local functions, NCrunch never has a problem.
Thanks for sharing this problem. I've reproduced it exactly as you've described.
The problem is caused by NCrunch's IL hashing for impact detection. The recursion here is causing the IL hashing algorithm to bomb out with a stack overflow.
I'll see what I can do to implement a fix.
Meanwhile, you may be able to work around the problem by redesign the code to avoid the recursion, or by changing your 'Impact detection mode' to 'WatchText'.