It has been almost a year since I wrote this post on creating a .NET Standard Library which was before Visual Studio 2017 was released. This post is going to cover the same basic idea, but for the new tooling which has vastly simplified the process.
.NET Standard Library
The .NET Standard Library specifies what .NET APIs are available based on the version of the .NET Standard Library being implemented. The following is a comparison to portable class libraries that really helped me understand the difference. This was pulled from the .NET Standard Library link above.
.NET Standard Library can be thought of as the next generation of Portable Class Libraries (PCL). The .NET Standard Library improves on the experience of creating portable libraries by curating a standard BCL and establishing greater uniformity across .NET runtimes as a result. A library that targets the .NET Standard Library is a PCL or a “.NET Standard-based PCL”. Existing PCLs are “profile-based PCLs”.
The .NET Standard Library and PCL profiles were created for similar purposes but also differ in key ways.
- Defines APIs that can be used for binary code sharing.
- The .NET Standard Library is a curated set of APIs, while PCL profiles are defined by intersections of existing platforms.
- The .NET Standard Library linearly versions, while PCL profiles do not.
- PCL profiles represents Microsoft platforms while the .NET Standard Library is agnostic to platform.
Create a .NET Standard Library
In Visual Studio click File > New > Project.
This will launch the New Project dialog. Find the .NET Standard templates and select Class Library.
Now that the library has been created right click on the project and go to properties. On the Application tab, there is an option to for Target framework which currently defaults to .NETStandard 1.4. Depending on your platform your library needs to support will decide which version of the .NET Standard you need to use.
See the chart on this page for help with picking a version of the standard. The lower the version of the standard you target the more platforms your library will run on, but keep in mind the lower the version the smaller the API surface that is available.
This process is so much easier than it was in Visual Studio 2015. The tooling around .NET Core and .NET Standard has gotten so much better. This type of library is the future and I highly recommend using .NET Standard when you have the option over portable class libraries.
I have a couple of computers I work between for the samples I use on this blog and when switching to between of them I got the following error last week.
The project doesn’t know how to run the profile IIS Express.
I verified the project would still run on the other computer with no issues. I also verified that on the computer with the issues the project would still work using
dotnet run from the command line still worked.
Next, I went to verify the project properties. Here I noticed a strange thing on the computer with the error the Debug tab of the project properties was missing a lot of setting. The following is a screen shot of the computer with the issues.
And here is the same tab on the same project, but from a different computer.
After more time that I would like to admit I was able to track down the issue. On the computer with the issue, I often work on projects that are very large which tend to slow down Visual Studio pretty bad. In an effort to speed things up a bit I when through and disabled all the extensions that I could including the Microsoft Azure App Service Tools. Turns out that disabling the previous extension caused the Microsft ASP.NET and Web Tools extension to be disabled as well (with no warning).
The only way I was able to get the project to work properly was to enable both the Microsft ASP.NET and Web Tools extension AND the Microsoft Azure App Service Tools extension. I am not sure why the Microsft ASP.NET and Web Tools extension need the Microsoft Azure App Service Tools extension but based on my experience they are related in some way.
Going through the process of getting Visual Studio 2017 installed on all my machines has been pretty smooth. The new installer works great and makes it much clearer what needs to be installed.
The one issue I have had, which was only an issue on one install, is an error when trying to clone a repo from GitHub. I say GitHub but really it would be a problem with any Git repo. The following is the error I was getting.
Error encountered while cloning the remote repository: Git failed with a fatal error.
After searching I found a lot of things to try. I uninstalled and reinstalled Git for Windows multiple times using both the Visual Studio Installer and the stand alone installer. I finally stumbled onto this forum thread which had a solution that worked for me. The following is a quote of the reason for the issue and a fix posted by J Wyman who is a software engineer for Microsoft’s Developer Division.
After intensive investigation we were able to determine that Git was accidentally loading an incorrect version of libeay32.dll and ssleay32.dll due to library loading search order and precedence rules. Multiple users have confirmed that copying the binaries from the “<VS_INSTALL>\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\bin\” folder to the “<VS_INSTALL>\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\libexec\git-core\” folder completely resolved the issue for him.
Any other users seeing similar problem should attempt the same solution.
I hope this gets other people up and running as it did me. My only worry about this fix is what happens with Git gets updated.