I have a few legacy projects which use native x64 dlls, which means they need to be executed as x64.
I have this in my .v3.ncrunchproject and have it checked into source control (TFS) but when I load the solution, the configuration UI shows "AutoDetect" and the local file gets silently overridden without a TFS checkout.
This causes every project which needs to be run in x64 to fail its tests.
I need to either re-configure every project in the UI or disable ncrunch, run "tf get /force /recursive *.v3.ncrunchproject" and re-enable ncrunch to fix this every time.
This worked in NCrunch 2 but has stopped working in NCrunch 3 and is very annoying.
It seems like a bug that it's completely ignoring the previous configuration and overwriting it, but is there at least a way to prevent it from overwriting the local files each time in the meantime?
Windows 8.1 x64 running VS Enterprise 2015 Update 3
A few questions to try and work out what's happening here:
- Does NCrunch give you any errors in the Tests Window about your settings failing to load?
- Are you using the simplified configuration mode? (identified with the checkbox on the configuration window)
- If not, is this setting being stored in your user 'My' config, or in your shared config?
- Do you have any V2 config files next to this project config file? If so, does deleting them help?
- Can you get this to happen with any project/solution? Or does it affect just the one in particular?
Remco wrote:- Does NCrunch give you any errors in the Tests Window about your settings failing to load?
No. The errors I get are things like BadImageFormatException when it tries to load a 64 bit dll into a 32 bit process.
Remco wrote:- Are you using the simplified configuration mode? (identified with the checkbox on the configuration window)
- If not, is this setting being stored in your user 'My' config, or in your shared config?
Yes, I am using the simplified configuration mode.
Remco wrote:- Do you have any V2 config files next to this project config file? If so, does deleting them help?
Yes. The v2 files are also set to x64. However, I can't delete them yet because other people (including build servers) are relying on them.
Deleting the V2 file, ensuring the V3 has x64 and re-loading the solution may help. It loaded as x64 at least once, but this problem doesn't happen every time the solution is opened (although once it starts happening, it doesn't stop until fixed) so I can't be completely sure.
Remco wrote:- Can you get this to happen with any project/solution? Or does it affect just the one in particular?
I only have one solution to test it with. It happens with multiple projects in that solution.
Sorry, this problem is quite elusive (I haven't recreated it yet), so I'll need to ask a few more questions:
- What is your 'Engine hosting strategy' global configuration setting set to? I.e. is NCrunch hosted in the IDE or in a Satellite Process?
- If you create a simple dummy solution with just one project, are you able to get the issue to appear?
- Could you submit a bug report after you've had this happen to you? The log file may yield some useful information
ghelyar wrote:
Where can I find the log file once it happens?
The bug report dialog has an option to export the log to disk. From here, you can open the ZIP and read its contents (all is in text form). Hitting the submit button will send the ZIP through to me for review.
I've just reproduced it losing the configuration on a blank solution with 1 project (with v2 files in the same directory, not sure if that was necessary)
With a single NUnit 3.5 test:
Assert.That(Environment.Is64BitProcess);
The unit test passed (presumably auto detected as x64), but when I looked into the configuration UI after loading the solution a few times Use CPU Architecture was set to AutoDetect, where all previous loads had been set to x64.
I deleted the v2 files and it was still happening.
It's not overwritten the .v3.ncrunchproject file; that still says x64, but I have seen it overwrite in my main solution (possibly due to writing PreviouslyBuiltSuccessfully after loading the configuration incorrectly - I was not making any changes in this test project, just repeatedly loading it)
It happened a few times in a row, then went back to correctly loading as x64.
If you need it, how is the best way of getting a zipped solution to you?
Thanks!! I'd really like to take a look at the sample solution you've made. You're welcome to submit it through the contact form if you like.
I'll take a look at the data you've sent through and will get back to you. It looks like there may be a race condition involved. Something that could be worth trying is changing your 'Engine hosting strategy' (global configuration setting) to HostInIDE. This may suppress the issue, as there is then less complexity with the IDE's in-memory configuration needing to be synchronised with the background engine.
With the solution you've provided, I've managed to isolate and resolve an issue where closing and re-opening the same solution within the same IDE session would cause NCrunch to neglect to correctly load project configuration.
I'm not entirely sure if this is the same issue you originally reported, as from your description, I had the impression that you've been experiencing this much more consistently. It's possible that you have a workflow that surfaces the issue quite frequently (for example, switching branches or opening different solutions with the same structure can also surface it).
I'm wondering if you might be interested in trying the build below. This build contains a fix targeted to address the issue I've isolated. If it doesn't also solve your original problem, I'll keep digging :)
Thanks, I'll give it a go. Today is my last day until the new year but I'll let you know if it happens today.
With the solution zip I provided I could get it to happen even after opening a completely new VS 2015 instance at the solution i.e.
1) unzip
2) open .sln in VS 2015
3) check if the ncrunch configuration UI shows Use CPU Architecture: AutoDetect on the project
4) if it shows x64, close VS and goto 2
This usually took about 3-5 attempts
After that I was probably actively working on the real solution, causing the read-only flag to be removed and the bad config to be written back to the file, then it would always load that configuration (hence when it started happening, I had to manually fix it or do a TFS force get to overwrite the local files to stop it from happening)
Update:
I opened the dummy solution 10 times and it loaded correctly each time.