A month or so ago we made the decision to upgrade some of the portable libraries we use for projects from being based on PCL Profiles (eg profile 111 or profile 259) across to .NET Standard. To do this, we followed the upgrade prompt in the project properties page in Visual Studio.
After clicking the “Target .NET Platform Standard” you can then pick which .NET Standard you want. Where possible we try for .NETStandard 1.0, which aligns with PCL Profile 259, or .NETStandard 1.1, which aligns with PCL Profile 111 (see https://docs.nuget.org/ndocs/schema/target-frameworks). The theory being that a .NETStandard 1.0 library can be consumed by any .NETStandard library 1.0 and above, as well as any PCL profile library that is profile 259 – in other words, we’re aiming for maximum reach.
Take for example, BuildIt.General, which is a general purpose utility library. This is now a .NETStandard 1.0 library….. or so we thought. I was doing some testing on the current stable version of the library to make sure it could be added into a Xamarin Forms application. In my previous post I showed how easily you can create a new Xamarin Forms project that has a PCL that contains all the UI for the application, and then head projects for each target platform (iOS, Android, UWP). Before adding in BuildIt.General I upgraded all the existing NuGet references – always good practice when creating new project (disclaimer: this sounds easier than it is due to an issue with the current Xamarin.Forms template which makes it hard to upgrade – more on this in a future post).
Next I added a reference to the BuildIt.General NuGet package – I made sure it was added to all projects as it includes a UWP library that has some useful extensions such as converters that are specific to UWP. At this point everything was able to build and I was able to run the UWP application (I didn’t get round to running the other platforms but I assumed that they would also work since I hadn’t really modified anything from what comes out of the box). I then wanted to test that I could invoke functions from the BuildIt.General library, so I added the following into the MainPage.xaml.cs file within the Xamarin.Forms PCL library:
LogHelper.Log(“test”);
Now, when I attempted to build the library I got the following error:
The primary reference “BuildIt.General, Version=1.0.0.20, Culture=neutral, processorArchitecture=MSIL” could not be resolved because it was built against the “.NETPortable,Version=v5.0” framework. This is a higher version than the currently targeted framework “.NETPortable,Version=v4.5,Profile=Profile259”.
This completely confused me….. what’s this reference to .NETPortable and what’s the difference between v5.0 and v4.5. Immediately I thought that it was an issue with Visual Studio 2017 but after a bit of investigating it turns out that it’s a more fundamental issue with the way that we, actually MSBuild/Visual Studio, is creating the BuildIt.General library. I came across this thread which includes this comment:
(Oren has one of the best explanations on the whole .NET Standard v’s PCL Profile discussion at https://oren.codes/2016/06/23/portable-is-dead-long-live-netstandard/)
Anyhow, I wondered whether our library was suffering from the same ill fate. Using ILSpy I took a look at what was included as the TargetFramework and sure enough it’s listed as .NETPortable, v5.0.
The workaround for this was listed in this changeset. In summary it requires a change to the project file to override the default generation of the Target Framework Moniker (See bold pieces in the following extract). There are two parts to the change: the first specifies the filename where the TargetFrameworkMoniker assembly attribute will be written to, and then included in the build of the application; the second overwrites the generated TargetFrameworkMoniker.
<?xml version=”1.0″ encoding=”utf-8″?>
<Project ToolsVersion=”14.0″ DefaultTargets=”Build” “>“>
<Import Project=”$(MSBuildExtensionsPath)$(MSBuildToolsVersion)Microsoft.Common.props” Condition=”Exists(‘$(MSBuildExtensionsPath)$(MSBuildToolsVersion)Microsoft.Common.props’)” />
<PropertyGroup>
<MinimumVisualStudioVersion>14.0</MinimumVisualStudioVersion>
…
<ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<TargetFrameworkProfile>
</TargetFrameworkProfile>
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
<TargetFrameworkMonikerAssemblyAttributesPath>$(IntermediateOutputPath)AssemblyTFMAttribute.cs.exclude</TargetFrameworkMonikerAssemblyAttributesPath>
…
</PropertyGroup>
…
<Import Project=”$(MSBuildExtensionsPath32)MicrosoftPortable$(TargetFrameworkVersion)Microsoft.Portable.CSharp.targets” />
<Target Name=”_SetTargetFrameworkMonikerAttribute” BeforeTargets=”GenerateTargetFrameworkMonikerAttribute”>
<PropertyGroup>
<RealTargetFrameworkMoniker>.NETStandard,Version=v1.0</RealTargetFrameworkMoniker>
<RealTargetFrameworkMonikerDisplayName>$(RealTargetFrameworkMoniker)</RealTargetFrameworkMonikerDisplayName>
<TargetFrameworkMonikerAssemblyAttributeText Condition=”‘$(RealTargetFrameworkMoniker)’ != ” and ‘$(TargetingClr2Framework)’ != ‘true'”>
// <autogenerated />
using System%3b
using System.Reflection%3b
[assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute("$(RealTargetFrameworkMoniker)", FrameworkDisplayName = "$(RealTargetFrameworkMonikerDisplayName)")]
</TargetFrameworkMonikerAssemblyAttributeText>
</PropertyGroup>
</Target>
</Project>
After making this change, and building a new version of the BuildIt.General library I can now see the correct Target Framework:
Out of interest, it appears that if you’re using the xproj project format targeting .NETStandard, it creates a library with the correct target framework. Hopefully this fix, will help you if you’re not.