Upgrade PCL to .NET Standard Class Library

I am going to show you the quickest way to do the upgrade, from an existing PCL, to a .NET Standard Class library, in Visual Studio 2017. Please note this will not work in VS 2015. Many of my previous posts don’t make it too clear on how to do this, due to the constantly changing nature of .NET Standard, especially between VS2015 and VS2017.

There is no way to do this via any upgrade tool, that I am aware of.

  1. Delete your packages.config and/or project.json file. We are going to have to add everything back manually. Keep a backup if you need to keep a reference.
  2. Right click, and press Unload Project
  3. Right click, and press edit projectname.csproj
  4. Delete everything in here.
  5. Replace with this xml
    <Project Sdk="Microsoft.NET.Sdk">
  6. Change the .NET Standard version to the one you want. However you will be able to change it from properties later.
  7. Remove this line, if you don’t want to support references to PCL’s
  8. Or, you can change this to support different profiles, if your project requires them.
  9. Reload your project.
  10. Manually add back references and Nuget Packages. It can be tedious on large projects, but it’s worth it.
  11. You may need to add back the reference to this project, from any other projects that were referencing it.

All Done 🙂


  1. VS 2017 .NET Standard libraries don’t support file nesting yet. As such ALL your *.xaml.cs files will be shown beneath your .xaml files.
  2. You will now be able to edit your .csproj, without unloading the project. Added plus!
  3. You can change the .NET Standard version, from properties now.
  4. I recommend .NET Standard 1.3, as it supports early versions of UWP, Android and iOS. I haven’t needed any API’s beyond this, at this point. But you can change as required.
  5. .NET Standard 2.0, is currently in preview in Android and iOS. UWP support for .NET Standard 2.0 is coming 2017, with the Fall Creators Update. However all Windows devices, must have the Fall Creators Update or higher to be compatible, with .NET Standard 2.0. This may be a good choice if you are starting a new project now, and won’t be releasing until the end of the year, by which time, they will all be out of preview.



        1. aubykhan

          Thanks Adam.

          This tweak is absolutely required in order to avoid random/strange build errors in Xamarin.Forms project. Particularly when you upgrade/downgrade Xamarin.Forms nuget.

  1. Stephan

    Hi Adam,

    I’m just wondering about the fact that you have .xaml files in a PCL/.net standard project. Does this really work? I’m already struggling with moving over my converters from the platform projects to the .net standard class lib (Xamarin.Forms.IValueConverter vs System.Windows.Data.IValueConverter vs Windows.UI.Xaml.Data.IValueConverter, none of which is available in .net standard for now).


    1. Adam Pedley

      If you were using PCL’s before, this won’t be an issue. If you are porting from the shared project into a .NET Standard Class Library, then you need to still check if they support the API’s, or use dependency injection to pass the required classes through.

      But yes, XAML in .NET Standard or PCL’s works really well.

      1. Stephan

        I have my converters in the native projects for now. I used PCLs before but now switched to SCLs. How does DI help here? In Xaml, when using a converter in a binding I have to provide a converter that implements one of the mentioned platform dependent IValueConverter interfaces. That’s why I can’t put the converters into SCLs. Or am I missing something totally obvious here?

        Furthermore, I did another search on how to put XAML in SCLs/PCLs. Without luck. Not sure how this works without the right namespaces/classes like Xamarin.Forms…, or Windows.UI…

        Do you probably have some links with tutorials/posts/… about those two topics?

        1. Adam Pedley

          I think you are confusing Shared with .NET Standard Class Libraries. This post is particularly about .NET Standard Class Libraries. They won’t have all the same APIs as a native project, hence you can’t reference any native API’s from a class library.

          1. Stephan

            “They won’t have all the same APIs as a native project”.

            Exactly. That’s why I can’t put platform independent converters that are used in bindings in XAML into PCLs and SCLs. Simply because a converter either has to implement Xamarin.Forms.IValueConverter or System.Windows.Data.IValueConverter or Windows.UI.Xaml.Data.IValueConverter depending on the framework used which are not available in PCL/SCL APIs.

            And that’s why I’m also confused when you say that “yes, XAML in .NET Standard or PCL’s works really well”.

              1. Stephan

                I just noticed that I might be using the wrong term here. It should be “framework specific” instead of “platform specific”. Of course, Xamarin.Forms.IValueConverters allows me to create platform independent converters. However, I cannot put the classes that implement this interface into SCL because this interface is not available in the .net standard API. That’s why the converters have to be in the Xamarin.Forms project, not the SCL. When I’m creating a UWP project and I want to use the same converters I would have to use the Windows.UI.Xaml.Data.IValueConverter interface. But as converters also contain application logic I would like to add them to the SCL for several reasons.

                (btw. thanks for your patience)

                  1. Stephan

                    Thanks for that article! It’s news to me that the View project (which is a SCL) can also reference Xamarin.

                    I just tried by creating a .net standard project in VS2017, adding a reference to Xamarin.Forms. I also added a dummy converter class that implements Xamarin.Forms.IValueConverter. Build in VS works! Yes! 🙂 Build using dotnet build on CLI doesn’t work. 🙁

                    Error message is error MSB4062: The “Xamarin.Forms.Build.Tasks.FixedCreateCSharpManifestResourceName” task could not be loaded from the assembly … Could not load file or assembly ‘Microsoft.Build.Utilities.v4.0 …

                    Adding Microsoft.Build.Utilities.Core as dependency didn’t work.

  2. Dev Solo

    It’s a bit tedious to tell the new .csproj format how to nest files together, but it is indeed working. The Stackoverflow user Harry has described the procedure in more detail here: https://stackoverflow.com/a/42428004/5400351

    Bottom line is ,you need to add two separate xml tag declarations for each XAML fille:



    Please note that the tags ‘DependentUpon’ and ‘LogicalName’ do not include any directory structure, only the name of the file is referenced.

    1. Dev Solo

      Since WordPress is stripping away most of the characters and I can’t update my previous comment, here’s the main part again but with HTML encoded characters:

      <Compile Include=”Views\MyPage.xaml.cs”>
      <EmbeddedResource Include=”Views\MyPage.xaml”>

    1. Adam Pedley

      If you want to show xml tags in comments, just html encode the comment first. It’s a wordpress thing, to remove all unwanted html tags. And it is rather annoying for a tech blog 🙂

  3. Mohamed Samsudeen

    Thanks for the post. I have the following doubts.

    1. Can I refer the libraries which are dependent of .Net standard in PCL itself. If so, why should I convert my PCL to .Net standard.

    2. If my custom controls was created as PCL, can I add this library in this converted .Net standard project (if my control is not dependent of .NET Standard). If not, what should I do to make library compatible.

    1. Adam Pedley

      1. You can reference a .NET Standard Library in a PCL, only under very certain setups. e.g. I think .NET Standard 1.1 works with PCL profile 259. 1.3 with Profile 111. But would have to double check that.

      Either way it’s hard, and not everything lines up nicely. Since every major nuget package is upgrading to .NET Standard, it is just going to make your life hard, because most of the time these packages don’t match nicely with PCL profiles. Nor will they in the future with .NET Standard 2.0. PCL is dead, it won’t be upgraded or enhanced upon, and Microsoft’s official recommendation is to move to .NET Standard.

      2. PCL’s can easily be referenced by .NET Standard libraries. Just look at the PackageTargetFallback section above in my example. That is what this line is for, enabling PCL’s to be referenced in the .NET Standard Library.

  4. Peter Hedley

    Hi Adam,
    Thanks for the post. I’m in the process of moving my PCL Xamarin.Forms app over to .Net standard libraries but have hit an issue with CocosSharp. I had previously used the CocosSharp for Xamarin.Forms nuget package but this is not compatible with .Net standard libraries. The CocosSharp PCL package also fails to install. I’d like to use the 1.7.1 version of CocosSharp.Forms as I use the CocosSharpView class in my common code. Do you have any experience/advice on getting CocosSharp to work with .Net standard?

  5. Zahir

    This is definitely a crazy time for me as a beginner to be making apps. Thanks for this post I have been searching for days as to why some of the plugins are not installing/working.

  6. Gordon Langford

    Hi Adam,

    I’m experiencing this is issue when converting libraries to NetStandard 1.3

    Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly ‘SomeNugetIPrepredEarlierForNetStandard1.3′, Version=, Culture=neutral, PublicKeyToken=’. Perhaps it doesn’t exist in the Mono for Android profile?

    Any Idea why this happening?