Build against .NET 4.6 to avoid problems with .NET Standard

[jcansdale]

@sharwell wrote:

You're compiling against .NET 4.6.1 and referencing packages that ship .NET Standard builds. That can cause problems. You should build against .NET 4.6 to avoid.

https://gitter.im/Microsoft/extendvs?at=5b6b3cac359c70045ca5db89

@sharwell could you elaborate on the potential issues here? I've head about this but never understood the problem.

[jaredpar]

TLDR when building a desktop component for Visual Studio you must target net46 and no higher

The set of assemblies that make up the VS SDK are a mix of desktop and portable assets. Visual Studio itself as a product has a minimum target framework of net46. That is true even though the vast majority of workloads inside of Visual Studio require at least net461 to be installed. The interesting point though is that core Visual Studio targets net46 [*].

Given that Visual Studio targets net46 the largest netstandard it can support is netstandard1.3 (doc). As a result portable assets that ship in Visual Studio target netstandard1.3 and the necessary facades to support this are included in the PrivateAssemblies folder.

For portable components the story is simple: target netstandard1.3. If you like pain you can target a lower version. Going any higher will result in runtime failures.

For desktop components the story is also simple: target net46. Targeting a lower version is also fine. Targeting a higher version though is dangerous can lead to really subtle issues due to how NuPkg assets are resolved. Specifically it can cause the desktop project to reference a different DLL (both in content and version) than the one deployed into Visual Studio:

Consider the following concrete example:

• Desktop VSIX project
  • PackageReference to System.Collections.Immutable
  • TargetFramework is net461

The version of System.Collections.Immutable that gets deployed for the restore / build is different than the one that exists in Visual Studio. This is because the NuPkg has a different lib entry for netstandard1.3 and netstandard2.0. Due to the project targeting net461 NuGet / MSBuild pick the netstandand2.0 lib while VS is deploying the netstandard1.3 one.

In this case the DLLs have virtually the same content and same version number hence you're unlikely to notice (roslyn almost missed this in our test projects). The same though is not true of all NuPkg. They can differ on assembly version, API surface area, behavior, etc ... That could lead to you building and testing against assets simply won't be there at deployment time.

This subtle change in which asset within the NuPkg gets picked is why it's pretty critical that you keep your desktop projects pointed towards net46 instead of net461. Keeping it at net46 sets your maximum netstandard to 1.3 and hence all of the proper assets will be resolved. Doing this is more important now than probably one - two years ago as more NuPkg are specializing on target framework in this way. The same behavior difference for example didn't exist for System.Collections.Immutable in the previous RTM version as there was a single asset.

This is a lesson we've learned the hard way in roslyn.

* Some MSDN pages and other docs suggest VS requires net461. This is incorrect for the purpose of this discussion.

[huysentruitw]

Related https://stackoverflow.com/questions/48060230/system-reference-troubles-when-introducing-netstandard-library-dependency ?

[thuannguy]

It seems to me that my issue https://github.com/dotnet/corefx/issues/31449 is related to this problem which causes us so much trouble.