We Keep Coding

Change Xamarin.Forms .Net Framework target

I have a Xamarin Forms project and the majority of times that I want to install a nuget package I have an error saying that:
Install-Package : Could not install package 'Microcharts 0.7.1-pre'. You are trying to install this package into a project that targets
'.NETPortable,Version=v4.5,Profile=Profile259', but the package does not contain any assembly references or content files that are compatible with that framework.
I Assume I can work this out by changing the project .net framework target. But when I go and change it, I get an error saying that it cannot change the target because that implies upgrading nuget to 3.0 and It can´t do that.
So my question is: Which is the best way(and simplest) to change the target framework so I have less problems like above with nuget packages.

This library was built to target .NETStandard v1.4. You are trying to use it in a PCL project, that is not possible. PCL is on the way out as the previous not-so-good way to build cross-platform libraries, .NETStandard is the new way.
There is no older version available of this library, rebuilding it from source is a possible option. But realistically it is time to move on to avoid hitting this wall over and over again, you need to update your tooling so you can consume these kind of libraries. The VS2017 Community edition is freeware.

It is time to go from your
.NET PCL Library to an appropriate .NET Standard Library.
Here are some links concerning the migration to .NET Standard.
Upgrade PCL to .NET Standard Class Library
.NET Standard 2.0 Support in Xamarin.Forms
Converting PCL (Portable Class Libraries) to .NET Standard Class Libraries
.NET Standard - PCL Compatibility
.NET Standard Implementation Support
My Suggestion concerning the version of the .NET Standard to use.
If you don't care about backwards compatibility (You want to use the latest OS and SDKs) go all the way to .NET Standard 2.
If you want to have a good backward compatibility you should go on .NET Standard 1.1 - 1.5.
On most projects i use 1.4 - 1.5.

Can I use PCL library in standard .Net application?

I have PCL Library and I want to add it to standard (.net 4.6) C# console application. Everything is fine as long as I don't use any PCL specific classes inside the library. And if I do, I get an error "unsupported PCL profile". This error is not googlable. But the same library works fine in UWP application. I am searching for a solution or official explanation why I can't use PCL in non UWP application.

Yes you can. PCL is basically intersection of available API's across different platforms. The disadvantage is that the more target platforms you choose the smaller is the intersection:
Another disadvantage of PCL is that it generates separate assembly for each platform.
That's why Microsoft comes with .NET Standard - a replacement of PCL that uses different approach.
Think about .NET Standard as an interface, that defines set of API's. Then the platforms like .NET Framework, .NET Core, Xamarin.iOS, Xamarin.Android will implement the .NET Standard.
interface NetStandard1_0 {
}
interface NetStandard1_1 : NetStandard1_0{
}
interface NetStandard1_2 : NetStandard1_1{
}
net46: NetStandard1_6 {
}
dnxcode46: NetStandard1_6 {
}
As a result, you won't target specific platforms, but a version of .NET Standard instead. When your library targets .NET Standard, it can be used in any platform that implements the .NET Standards. Another advantage is you wont need separate assemblies for different platforms anymore. There will be single assembly that runs just everywhere.
However, I recommend you to wait until April 2017 when .NET Standrard 2.0 should be released. Microsoft promised that all platforms (.NET Framework, .NET Core, Xamarin.iOS, Xamarin.Android) will support this version of .NET Standard and it will have official support in Visual Studio. Also, Visual Studio projects using project.json will be converted to .csproj, so all Visual Studio projects will use the same format and it will solve a lot of compatibility issues. Cleanning of the mess that appeared in .NET last years was absolutelly necessary

Sure you can.
Just add .NET 4.6 to selected platforms:
It's appears at time when you create PCL.
More information here:
Cross-Platform Development with the Portable Class Library
Or you can change platforms in existing PCL. Just go to properties page and you will see:
Here is a good blog post about how to call UWP API from desktop App:
How to call UWP APIs from a desktop VB/C# app

Class library references on Visual Studio 2015

I've added a new Class Library (Package) project to my solution. It's my first experience with a .NET Core (or whatever I'm using, still confused)
My class library contains two references: .NET Framework 4.5.1 and .NET Platform 5.4
I'm trying to import some code from a sample project that uses IPrincipal. For some reason it's saying that it doesn't exist on namespace "System.Security" altohugh I can get it trough intellisense.
What's wrong with my project settings?

The new feature of .NET Core and Class Library (Package) is that it targets multiple platform and will compile into multiple assemblies which get automatically packaged into a nuget package.
When your class library targets multiple targets, it will compile to all of them. So if a certain library is only available on full .NET framework but not on .NET Core or other target framework, then you may receive intellisense if your editor is set to .NET 4.5. More information can be found in my other recent answer.
You can switch back and forth with the pull down menu on top left of the coding window, show in the screenshot below.
If you do not want to target a certain framework, you have to remove it's moniker from the project.json file or use preprocessor directives to write platform specific code or libraries/replacements.
.NET Core is heavily modularized and most of only the core modules are referenced in the default project and if you need additional one you need to reference them within the dotnet5.x section.
Basically you have multiple places with "dependencies" in your project.json, a global one where you can add dependencies which are available on all targeted frameworks and one within each "frameworks" section for each of the targets only.

Though the other answer covers some basic concepts, it would require some attention on which classes are available and which are not.
Microsoft temporarily host a web site at http://packagesearch.azurewebsites.net to assist.
If you can find a suitable package for RC1 from there, then you can add it to your project.json file. If not, you will have to conditional compile it to a desktop profile or use other alternatives.

Is there any way to share code between UWP apps and WPF apps?

To be clear, I follow the MVVM pattern, and I want to structure my project such that I can share my model code between a UWP app and a standard WPF app. The code I want to share has no UI. I don't relish the thought of finding new tools to replace the ones that I've been using for years that take care of certain tasks like logging, connecting to a document oriented database, etc.
I attempted to start writing a UWP wrapper around some code I already have and reference the model project directly. Visual Studio refused to let that happen, showing me an error message that says "Unable to add a reference to project 'ACK.Model'". The same thing happened when I attempted to put the model in a Universal Library and reference it from a WPF app. I'm not trying to share WPF code. Just the model layer that has no reference to UI libraries.
This is a scary proposition, because it means that if I want to do anything substantial I have to choose to either jump 100% to UWP or stay 100% WPF. NewtonSoft.JSON might have a universal distribution (ASP.NET MVC), but what about ElasticSearch.NET, and other tools needed to make important apps?
I found where the "Portable Class Library" project type was hiding. PCLs will allow me to share my code across WPF and Universal apps as that was one of the options. This solves the simple case of the Model part of my code, but I (still) can't use some of the libraries I want. There are still a large number of libraries that I need that do not have PCL available.

About a year later, with the advent of Visual Studio 2017 there is a more complete solution. If you target your libraries to .Net Standard then the library is compatible with both .Net Core apps and the monolithic .Net targeted app. The support for standard .Net libraries and APIs is fairly complete, as is the support for modern C# language features.
The general advice now is this:
Target .Net Standard for all libraries
Target the appropriate platform for your actual application. (UWP or WPF).
NOTE: if your library has to interact with C libraries or applications, you have to take extra care to make sure you load the correct version.
It appears that there is a solution, but it has to be adopted by the whole tool chain you want to use. When Microsoft introduced Windows Store apps in Windows 8, they also introduced a Portable Class Library (PCL). The purpose of the PCL is to share code between different parts of your application.
When you create a PCL in Visual Studio 2015, you can specify the types of APIs you want it to be accessible from:
Universal Apps
Mono
.Net Core 5
.Net 4.6
This of course, limits the APIs available to you but most of the ones you want to use are OK as long as it's not UI related. There are other limitations as well:
Your project can only be edited in Visual Studio 2015 or greater
You don't have access to special directories from the Environment variable (i.e. user Documents directory, etc.)
You can't link to a library designed for only one of your target platforms (i.e. libgit2sharp, etc.)
There's no way to browse the API for this subset--MSDN needs to get on the stick. MSDN has updated much of the API documentation, but it's still difficult to figure out what applies to your PCL
However, you can link any library designed for a single target platform to your PCL. It's not ideal, but it's better than nothing.
The ASP.NET MVC stack has been ported to using PCLs, so you can use NewtonSoft.JSON directly as well as any other of those libraries used by that application. However, there are several libraries that have not been ported.
This arrangement forces you to think about how you want to integrate better. The .Net Core 5 seems to be stable, but support is in it's infancy. The current generation of Universal Apps as of VS 2015 update 1 uses .Net Core 5 directly.
There are several features from Nuget that are not currently supported even though work is under way:
MS Build extensions (major changes to MSBuild and the project.json structure)
Install/uninstall scripts (related to the removal of the concept of install)
Content (related to install/uninstall, but work is in progress on this)
Content transforms (related to lack of install/uninstall)
I wish I had a more complete answer. But this is as far as I got once I discovered the PCL and how it evolved for the current infrastructure.
I'm in the process of creating a game creation toolkit that incorporates version control right off the bat. I want to be able to deploy a game as a Windows 10 app, or as a standard WPF app, but due to the libraries I'm using to integrate version control I need to create the editor as a standard WPF app. I had to be a bit creative in building the shared code and importing the correct libraries.
First, my project hierarchy:
Project.Model (Portable Class Library)
Project.Model.Versioning (standard C# library)
Mvvm.Toolkit (Portable Class Library)
Editor (Standard WPF application)
I want the core PCL to be able to load a project and deserialize the JSON encoded objects. The PCL did have access to System.IO, but surprisingly it is not the same as the one defined in the standard C# library. Here's how I had to fix things:
After adding the package reference to NewtonSoft.JSON, I had to change the target framework in the packages.config file:
<package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />
All projects dependent on my Project.Model class had to install the `system.io.filesystem' package from nuget so that the System.IO.FileInfo etc. objects were the same.
While this is definitely not a panacea, it's also not a dead end. I'm sure there are more gotchas, but this will at least help with some of the problems.

a .NET Standard library could be used to share a Model-View-ViewModel architecture between a WPF project and a UWP project.
https://www.syncfusion.com/ebooks/xamarin-forms-succinctly/sharing-code-among-platforms
https://devblogs.microsoft.com/dotnet/announcing-uwp-support-for-net-standard-2-0/

Can "legacy" .NET projects also use the new NuGet 3 features?

The new NuGet version fixes lots of problems (e.g. transitive dependency capabilities, dependency resolution at build time, single packages repository cache, etc.).
However I could only test it with the ASP.NET vNext and UWP projects.
Will these new features also be available for "legacy" projects (e.g. full .NET 4.5/4.6 projects, WPF, etc.)?

As of 8/19/2015, it seems that the new features are not supported for "legacy" projects but may be added later. According to the NuGet documentation:
project.json is mandatory for UWP apps and ASP.NET 5 apps, is
optional for PCLs, and currently is not fully supported on other
project systems.
and
Starting from Visual Studio 2015, several project types are utilizing
this technology, with more to follow in the future.
1.Universal Windows Platform managed apps (UWP).
2.Portable class libraries (PCL).
3.ASP.NET 5 applications.