Develop Reference

Xamarin.Forms - "Target .NET Platform Standard" option not appearing

I'm currently using a PCL in my Xamarin.Forms project and would like to change it to a .NET Standard library. I've looked up tutorials and as far as I understand the first step is to click the "Target .NET Platform Standard" option in the PCL project's properties. The issue is this option is not shown to me, instead, to me, there's a text saying "Learn More" which when clicked takes me to a page comparing .NET Standard to PCL and more https://learn.microsoft.com/en-us/dotnet/standard/net-standard#comparison-to-portable-class-libraries. What should I do?

I did run into the same problem. We tried to convert all our PCLs to .NET Standard. And we thought, that let them "Target .NET Standard" makes them pure .NET Standard libs, but this assumption was wrong. We ran into several problems, untill we realized, that there are some small differences between a PCL Targeting .NET Standard and a pure .NET Standard library.
The Solution was to create new libraries for every PCL and copy the files into the .NET Standard libraries. We are working on .NET Standard 2.0 libs in our Xamarin project now and everything works as expected. Atleast after we updated our VisualStudio to the newest version and after updating resharper to an EAP Release.
So i'd recommend you to go the same way and just create new .NET Standard libraries for your PCL projects and copy the contents.
Additional Information
Microsoft.NetCore.CompatibilityPack
You will run into issues of incopatibility with nuget Packages that do not support .NET Standard yet. You will need this package
Channel9 How To
The following links provides a Channel9 video showing how to migrate to .NET Standard. The guy also talks about the CompatibilityPack and fallback targets https://channel9.msdn.com/Shows/XamarinShow/Snack-Pack-15-Upgrading-to-XamarinForms-to-NET-Standard

Can I reference a .NetStandard library from my Windows 10 UWP app?

There are TONS of posts, blogs, articles, etc... explaining all of this confusing stuff with regard to .Net/.NetCore/.NetStandard and I have read many of them.
Here is the issue, I have a Windows 10 UWP app and I need to reference a library that I created. I first created the library as a NetCore library but I could not reference that from my UWP app (which is confusing because UWP uses .Net Core but the .Net Core library I created assumed this was for ASP.NET?).
So, then I tried to create the library as a PCL library and targeted ONLY Windows 10 UWP (which it then forces you to Windows 8.1 because they are the same). With this type of library I am confident I would be able to reference it from my UWP app but it caused me to lose too many .Net namespaces that I could not get the library to build.
Finally, I then selected the link, in the project properties, to target the .Net Standard instead. I selected .Net Standard 1.4 and suddenly, I had all the namespaces I needed available to me and I was able to build my library. I am also able to successfully add it as a reference to my UWP app.
However, I am getting the following 6 exceptions and they don't tell me too much about the root cause so I can fix it.
So, my main question is, can you reference a .Net Standard 1.4 library in your UWP app? Second, any ideas what these exceptions mean?
Thanks!
EDIT - I have uploaded both csproj files here:csproj files

Okay, I found that answer but it was based mainly on this answer which I did not see before posting my question due to search terms (I have literally spent over a day searching and trying to find an answer).
Answer that helped:
Here is a summary:
.NetStandard 1.4 is supported by UWP.
By default, VS 2015 Update 3 template for a UWP project imports Microsoft.NetCore.UniversalWindowsPlatform version 5.1.0. I am sure the VS 2017 template will start off with a newer version, 5.1.0 is fairly old. So, based on the answer linked above, I updated (using NuGet) to the newest version allowed by VS 2015 Update 3 which at the time of this answer, is version 5.2.3. There is a 5.3.x version but it requires VS 2017.
Finally, I modified the project.json in my UWP project to import the netstandard1.4 framework. It looks like this:
"frameworks": {
"uap10.0": {
"imports": "netstandard1.4"
}
And, with those simple steps, I can get the UWP project to build and those 6 errors above go away.
Hope this helps!

Share code between multiple .NET Core projects

I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?

.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?

I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).

Can PCL libraries run with ASP.NET MVC?

I wish to write a library that can run on a number of targets such as WPF, Windows Phone/Mobile, Mono, and ASP.NET. I keep searching for information on this but it seems PCL's are not supported in ASP.NET?
Even VS indicates PCL can't be used with ASP.NET:
So what should I do to be able to write a PCL that runs on all the platforms? Use PCL for everything apart from ASP.NET, and create a normal Class Library for ASP.NET and basically copy+paste the code?

The short answer is YES, as long as the PCL profile supports the same .NET framework version your MVC application is targeting, you will be fine.
When you create a Portable Class Library, you can choose a combination of platforms that you want your code to run on. The compatibility choices you make when creating a Portable Class Library are translated into a "Profile” identifier, which describes which platforms the library supports.
What probably confused you, was the fact that ASP.NET was not mentioned in the list of supported software frameworks (platforms). The reason is that ASP.NET is not really a software framework, but an application framework (higher level). This means that whatever application frameworks target the software framework the PCL supports, the application frameworks will also work.
Be sure to take extra caution when choosing the supported platforms when creating a new PCL project, since the API that is available for use in that project depends on that choice!
You can read more about portable class libraries on MSDN.

Why do some NuGet packages provide both a Portable Library and an Platform Specific One?

It is my understanding that Portable Class Libraries can be used on many platforms, based upon the subset of the framework the designer of the library choose to support.
I noticed that many libraries available via NuGet also include a platform specific implementation and wonder what is the need for this.
For instance, the Microsoft.Net.Http package comes with many variations, including :
Net 4.0 version
WinRT (Windows Store Apps) Windows 8 Version
Portable Class Library supporting Net 4.0, WinRT and others
Why is there a need to distribute separate .Net 4.0 or WinRT versions of the Library ?
Isn't the Portable Class Library sufficient ?
When I'm designing my own custom Portable Libraries, should I adhere to this convention ?
To be clear, I'm not talking about Portable Class Libraries that need a small portion of platform specific code to work. Those usually have an accompanying managed Library whose name ends with .PlatformServices. But I'm talking about the core library distributed by the NuGet package.

Sure, the PCL version might well be sufficient for your needs. However, as you are bound to find out when you create your own PCL class library project, the sub-set of .NET Framework classes and methods that you can actually use in a PCL project is a rather small one. That sub-set is created by taking the full .NET Framework and subtracting out the parts that cannot work on another platform.
The most restrictive platforms are Silverlight and Phone7, they are based on the .NETCore version of the CLR. And Store and Phone8, based on the services available through the WinRT api. Targeting any of these quickly dwindles down the number of things you can do in your library.
The Microsoft.Net.Http package was optimized to still make some of the Http relevant methods and properties available if you are not limited by one of those restricted platforms. You can have a look-see in the packages subdirectory, the System.Net.Http.Extensions.xml files that provide IntelliSense shows you what is possible on one platform but not another. I see:
HttpWebRequest.AllowAutoRedirect
AuthenticationManager.PreAuthenticate
HttpWebRequest.ProtocolVersion
HttpRequestHeaders.TransferEncodingChunked
HttpClientHandler.UseProxy
Do note that these properties are mapped with extension methods.