Error when .NET461 full framework references .NETStandard nuget packages

After updating MongoDb driver in a C# big project I start having a problem in a Web Project where we have this error after a deploy in test server (but we have no error in local machine of developers)

An assembly with the same identity ‘System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ has already been imported. Try removing one of the duplicate references.

This happens because MongoDB driver > 2.8 reference in the chain System.Buffer 4.4.0. If you take an empty .NET Full Framework 4.6.1 and references MongoDb 2.8.x driver you can verify that you have

image

Figure 1: System.Buffers reference for the project

This seems an innocuous reference, but if you look closely to what is inside System.Buffer you can verify that there is no package for full framework. Just check in the packages directory to verify that there is no .NET full framework package.

image

Figure 2: There is no full framework package inside System.Buffers

This imply that, when you build the project, in the bin directory you will find all the dll of netstandard project, because actually you are referencing netstandard 2.0 dll.

image

Figure 3: All netstandard dlls included in the bin directory of the project.

Now you have a problem, because you have netstandard runtime included in your project, most of the time it is safe, but there are situation where this can generate errors.

You can find the issue in GitHub #39362, that in turn is a duplicate of #39362 (my original issue).

Actually, if you want to avoid problems, you should be 100% sure not to reference any netstandard dll in a .NET 4.6.1 full framework project, or you should use full framework 4.7.2 or greater.

Gian Maria.

Multitarget .NetStandard for Windows and Linux

One of the most important features of DotNetStandard is the ability to run on Linux and Mac, but if you need to use a DotNetStandard compiled library in a project that uses full .NET framework, sometimes you can have little problems. Actually you can reference a dll compiled for DotNetCore from a project that uses full Framework, but in a couple of project we experienced some trouble with some assemblies.

Thanks to multitargeting you can simply instruct DotNet compiler to produce libraries compiled against different versions of frameworks, so you can simply tell the compiler that you want both DotNetStandard 2.0 and full framework 4.6.1, you just need to modify the project file to use TargetFrameworks tag to request compilation for different framework.

<TargetFrameworks>netstandard2.0;net461</TargetFrameworks>

Et voilà, if you run dotnet build command you will find in the output folder both the versions of the assembly.

image

Figure 1: Multiple version of the same library, compiled for different versions of the assembly.

Multitargeting allows you to produce libraries compiled for different version of the framework in a single build.

The nice aspect of MultiTargeting is that you can use dotnet pack command to request the creation of Nuget Packages: generated packages contain libraries for every version of the framework you choose.

image

Figure 2: Package published in MyGet contains both version of the framework.

The only problem of this approach is when you try to compile multitargeted project in Linux or Macintosh, because the compiler is unable to compile for the Full Framewor because full framework can be installed only on Windows machines. To solve this problem you should remember that .csproj files of DotNetCore projects are really similar to standard MsBuild project files so you can use conditional options based on environment variables. This is how I defined multitargeting in a project

image

Figure 3: Conditional multitargeting

The Condition attribute is used to instruct the compiler to consider that XML node only if the condition is true, and with Dollar syntax Ican reference environment variables. The above example can be read in this way: if  DOTNETCORE_MULTITARGET environment variable is defined and equal to true, the compiler will generate netstandard2.0 and net461 libraries, otherwise (no variable defined or defined with false value) the compiler will generate only netstandard2.0 libraries.

Using the Condition attribute you can specify different target framework with an Environment Variable

All the people with Windows machines will define this variable to true and all projects that uses this configuration, automatically will compile for both frameworks. On the contrary, all the people that uses Linux or Macintosh can work perfectly with only netstandard2.0 version simply avoiding defining this variable.

The risk of this solution is: if you always work in Linux, you can potentially introduce code that compiles for netstandard2.0 and not for net461. Even if this situation cannot happen now, working with Linux or Mac actually does not compile and test the code against the full framework. The solution to this problem is simple, just create a build in VSTS that is executed on a Windows agent and remember to set DOTNETCORE_MULTITARGET to true, to be sure that the build will target all desired framework.

image

Figure 4: Use Build variables to setup environment variables during the build

Thanks to VSTS / TFS build system it is super easy to define the DOTNETCORE_MULTITARGET at build level, and you can decide at each build if the value is true or false (and you are able to trigger a build that publish packages only for netstandard2.0). In this build I usually automatically publish NuGet package in MyGet feed, thanks to GitVersion numbering is automatic.

image

Figure 5: Package published in pre-release.

This will publish a pre-release package at each commit, so I can test immediately. Everything is done automatically and is run in parallel with the build running in Linux, so I’m always 100% sure that the code compile both in Windows an Linux and tests are 100% green in each operating system.

Gian Maria.

.NET core 2.0, errors installing on linux

.NET Core 2.0 is finally out, and I immediately try to install it on every machine and especially in my linux test machines. In one of my Ubuntu machine I got an installation problem, a generic error of apt-get and I was a little bit puzzled on why the installation fail.

Since in windows the most common cause of .NET Core installation error is the presence of an old package (especially the preview version), I decide to uninstall all previous installation of .NET core on that machine. Luckly enough, doing this on linux is really simple, first of all I list all installed packages that have dotnet in the name

sudo apt list --installed | grep dotnet

This is what I got after a clean installation of .NET core 2.0

image

Figure 1: List of packages that contains dotnet in the name

But in that specific virtual machine I got several versions and a preview of 2.0, so I decided to uninstall every pacakge using the command sudo apt-get purge packagename, finally, after all packages were uninstalled I issued a sudo apt-get clean and finally I tried to install again .NET core 2.0 and everything went good.

If you have any installation problem of .net core under linux, just uninstall everything related with dotnet core with apt-get purge and this should fix your problems.

Gian Maria.