NCrunch doesn't use the 4.6.2 engine host

lguilhou

#9178 9 years ago 19 Sep 2016 15:53 UTC

I can't seem to make NCrunch (2.26) use the 4.6.2 version of its engine, even though the framework is properly installed, as well as its dev (and targeting) pack. It keeps using the 4.6.1 version.

However using a grid node on a 2008 r2 server with the 4.6.2 framework installed does use the 4.6.2 version properly. But locally, it always ends up in an analysis failure "The requested version of the .NET framework, 'Framework462' is not installed on this system"

This is on a Win10 x64 Enterprise (with all updates) with VS2015 Enterprise. I've just reinstalled the entire system (clean install, up to and including recreating the partition, can't do much cleaner than that :) from the Win10 anniversary update ISO. Even with only that, VS2015, ReSharper and NCrunch, the 4.6.2 engine is still not being used.

This happens on any project, even just creating a new class library and adding the NUnit package (or xUnit, doesn't matter). The project is created targeting the 4.5.2 framework by default, NCrunch when enabled starts up the 4.6.1 host and a 4.5.2 runner, and when switching the project to 4.6.2... no more NCrunch.

The 4.6.2 framework does work properly, can be use to compile and run the projects without any issues, the ReSharper test runner works fine with it, it's just NCrunch that doesn't seem to like it.

I may be missing something obvious but I'm currently out of ideas.

Remco NCrunch Developer

#9179 9 years ago 20 Sep 2016 08:32 UTC

Edited 9 years ago 20 Sep 2016 08:32 UTC

lguilhou

#9180 9 years ago 20 Sep 2016 10:13 UTC

2.27 uses the 4.6.2 engine without problem, thanks :)

Remco NCrunch Developer

#9181 9 years ago 20 Sep 2016 10:54 UTC

Great! Thanks for confirming!

Remco NCrunch Developer

#9241 9 years ago 02 Oct 2016 06:06 UTC

v2.27 has now been fully released - https://www.ncrunch.net/download.

lguilhou

#9244 9 years ago 02 Oct 2016 10:13 UTC

Still works with framework 4.6.2 \o/

Little side question: is it normal that the test runner is always the x86 version even when both the NCrunch configuration and the project platforms are set to x64? The engine and build hosts are x64 but test hosts are always x86.

It doesn't cause any issue for me but I thought I'd mention it just in case :)

Remco NCrunch Developer

#9245 9 years ago 02 Oct 2016 11:37 UTC

lguilhou wrote:Still works with framework 4.6.2 \o/

Excellent! :)

lguilhou wrote:
Little side question: is it normal that the test runner is always the x86 version even when both the NCrunch configuration and the project platforms are set to x64? The engine and build hosts are x64 but test hosts are always x86.

It doesn't cause any issue for me but I thought I'd mention it just in case :)

Yes, this is by intention. See here for more details.

Rupert

#10735 9 years ago 03 Jul 2017 12:36 UTC

Hi,
I'm using NCrunch 3.9.0.1, integrated into VS 2017, running on Windows 7.

I am getting the following error when trying to test an assembly that targets .Net Framework 4.6.2: System.Exception: The requested version of the .NET framework, 'Framework462' is not installed on this system.
.Net 4.6.2 is installed on the system.

Any ideas?!?

thanks,
Rupert

Remco NCrunch Developer

#10739 9 years ago 03 Jul 2017 23:21 UTC

Hi Rupert,

When creating a test environment, NCrunch will always use the version of .NET targeted by the test project.

This means that if you have a test project targeting .NET v4.6.2, you will need to have .NET v4.6.2 installed. NCrunch detects v4.6.2 by inspecting the "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Release" registry value. For v4.6.2 to be installed correctly, this registry value must be 394802 or above (according to MS specs). If you have v4.6.2 installed but the registry key is lower than this value, you probably have a broken installation of .NET v4.6.2 and may need to reinstall it.

Rupert

#10742 9 years ago 05 Jul 2017 06:42 UTC

Hi Remco,
Thanks for getting back to me. Looks like the registry setting described above was below 394802, and a re-install of .NET 4.6.2 resolved the issue. Everything working fine now.

cheers,
Rupert

Post a reply