Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

GenerateSupportedRuntimes causes breaking change with targeting specific .NET framework versions

See original GitHub issue

(I think that…) The new GenerateSupportedRuntimes functionality (https://github.com/dotnet/sdk/pull/2447) caused a breaking change, when using the complus_version environment variable, to launch a process running on a specific version of the .NET Framework. This change broke the NUnit Console, which relies on this behaviour. The solution to this may be to “not do that” - but I thought I should report for awareness.

The NUnit Console by default runs all test assemblies in external processes (called “agent processes”), and uses the complus_version environment to run these agent processes on a specific version of the .NET Framework. (The target version of the test assembly in question.)

For complus_version to be respected, it’s required that no supportedRuntime elements exist in the app.config. Otherwise, these elements appear to override complus_version. Because the agent executable currently targets .NET 2.0 (as the lowest runtime we support), the new GenerateSupportedRuntimes functionality added <supportedRuntime version="v2.0.50727" /> to the app.config, forcing the agent processes to always run on .NET 2.0, and therefore fail to load any assemblies targetting .NET 4.0 or higher.

Because we potentially need to launch multiple agent processes under various different frameworks at runtime, having fixed values in the app.config is not an option. We’ve currently added <GenerateSupportedRuntimes>false</GenerateSupportedRuntimes> to our csproj’s to suppress this behaviour.

I’m aware complus_version isn’t ‘documented’…is there a better solution we should be using to support this situation instead?

Apologies if I’ve incorrectly pinpointed the cause here - I’m not too familiar with MSBuild.

Issue Analytics

State:
Created 4 years ago
Comments:5 (2 by maintainers)

Top GitHub Comments

1reaction

livarcocccommented, Mar 24, 2019

Also, @ChrisMaddock we don’t officially support .NET Framework 2.0 on the .NET Core SDK.

0reactions

ChrisMaddockcommented, Mar 25, 2019

Thanks @livarcocc.

Also, @ChrisMaddock we don’t officially support .NET Framework 2.0 on the .NET Core SDK.

Thanks - I wasn’t aware of this. I just checked, and I don’t see this behaviour when building in VS 15.9.9.

Stupid question then, sorry: I have csproj’s that multi-target net20;netstandard20. What’s the supported way of building those, outside of VS?

Top Results From Across the Web

Troubleshoot .NET Framework targeting errors

To resolve the error, make sure that your application targets a .NET version that's compatible with the version that's targeted by the projects ......

Older framework versions dropped from packages - .NET

NET 6 breaking change in core .NET libraries where older framework versions have been dropped from the core libraries packages.

Targeted .NET Frameworks - Visual Studio (Windows)

NET Framework that you want your project to target so the application can only use functionality that's available in the specified version.

Version compatibility in .NET Framework

In practice, this compatibility can be broken by seemingly inconsequential changes in the .NET Framework and changes in programming techniques.

NET Framework - Runtime and retargeting changes

Retargeting changes are those that arise when an assembly is recompiled to target a newer version. Targeting a newer version means the assembly ......