search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.75k stars 1.07k forks source link

GenerateSupportedRuntimes causes breaking change with targeting specific .NET framework versions #3036

Open ChrisMaddock opened 5 years ago

ChrisMaddock commented 5 years ago

(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.

ChrisMaddock commented 5 years ago

I would also add - previously an exe tagetting .NET 2.0 would by default have run under the lastest .NET Framework version available (I think.) This change appears to change that default, for a .NET 2.0 assembly to always (only?) run under .NET 2.0?

ChrisMaddock commented 5 years ago

Whoops, forgot to add, this has been seen on the following version:

Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
livarcocc commented 5 years ago

@wli3 can you take a look?

livarcocc commented 5 years ago

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

ChrisMaddock commented 5 years ago

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?