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
Related
Long story, summarized...
I started working on a solution creating many projects (like class libraries) for the solution. Then I ended up needing to use a third-party SDK for something I had an expensive license for. Come to find out, that third-party SDK only supported .NET Framework.
Because my solution was based in .NET 5/Core and the SDK in .NET Framework I had a big issue. They can not exist in the same environment and reference each other. So, on to biting the bullet and spending hours converting all my projects to .NET Framework 4.8 while singing a neverending song of curse words...
The Issue
My first class library I'm trying to convert from .NET5 to .NET 4.8 happens to have a Nuget package installed. That Nuget is Newtonsoft.Json Version="12.0.3" (https://www.nuget.org/packages/Newtonsoft.Json).
After changing the framework in the project file, VSCode is telling me the Newtonsoft namespace can not be found. This makes me think that the Nuget I have installed is not compatible with .NET Framework 4.8.
The issue I was running into was the namespace Newtonsoft could not be found after changing the framework from net5.0 to net48.
The issue was OmniSharp that was giving a false positive. I restarted VSCode and the issue went away once VSCode loaded with the new framework being used.
.NET supports cross platform targeting which means you can have your SDK style .NET5 project multi-targets both net5 and net48. In future, if the third-party library targets .NET Core then you can simply change the TargetFrameworks property.
A similar issue has been discussed here https://github.com/dotnet/runtime/discussions/40304 incase if that helps.
When I create a new Xamarin.Forms project in Visual Studio 2017, in the project properties I can't target any other framework than
.NET standard 1.0
.NET standard 1.1
.NET standard 1.2
.NET standard 1.3
.NET standard 1.4
.NET standard 1.5
.NET standard 1.6
.NET standard 2.0
I'm trying to use a nuget package targeting .NET Framework 4.6.1 and it doesn't load because of that.
I have a warning when i add that package :
The package CHU.Xamarin.Helpers 1.0.0.1 has been restored using '.NETFramework,Version=v4.6.1' instead of target framework of the project '.NETStandard,Version=v2.0'. The package might not be totally compatible with your project.
Is there a way to target .NET Framework 4.6.1 in the project ?
If i add the nuget package anyway, i've got an error saying it is not compatible with monoandroid71 :
The package CHU.Xamarin.Helpers 1.0.0.1 is not compatible with monoandroid71 (MonoAndroid,Version=v7.1). The package CHU.Xamarin.Helpers 1.0.0.1 handles : net (.NETFramework,Version=v0.0)
The error messages are translated from French so might differs from english counterpart
NOTE: None of the following answers "how to target .NET Framework 4.6.1 for a Xamarin.Forms project". If you really, truly, need to know how to do that, and know what you are doing, and why, then search elsewhere - doing so is an advanced topic, and is no longer recommended. For cross-platform projects, stick with a .NET Standard version.
In this case, despite the question title, doing so is not the solution. Keep reading for more details.
I'm trying to use a nuget package targeting .NET Framework 4.6.1 and it doesn't load because of that.
Actually, it does load. It gives you a warning. You can probably ignore that Framework vs Standard warning - I've been ignoring a Framework 4.6.1 vs Standard 2.0 warning for over a year, without problem.
error .. saying it is not compatible with monoandroid71
This is the real problem that is stopping you.
Is there a packages.config file? If so, open it in a text editor, and search for monoandroid71. If present, then yes, this is the problem -
The packages.config mechanism contains an outdated "hint", OR you ARE targeting an older Android version, that is not compatible with the nuget you wish to use - as the message says.
Possible fix:
Target Android 8.0 or higher. In your Android project (e.g. if you named your Xamarin Forms project "App1", look in solution for the project labeled "App1.Android") / Properties / Application / Compile using Android version (Target Framework) / select Oreo or Pie.
Update all nugets to latest.
If packages.config still mentions monoandroid71, then you have outdated "hints".
Different ways to fix outdated hints in project.config. Do ONE of the following:
Rt-click on project.config in Solution pane, select "Migrate to PackageReferences". This newer mechanism doesn't rely on hints.
OR Delete project.config. Add the nugets again.
OR Manually edit project.config. Change all targetframework=monoandroidXX to be the same - whatever the highest number you find in the file. Probably monoandroid81 or monoandroid90.
OR Start all over. Latest VS 2017 version OR VS 2019. Either works fine for this purpose. New project / C# / Mobile App Xamarin Forms. Copy your source files (.cs, .xaml) to the new projects - DON'T use your old .csproj or package.config. The goal is to use all the latest build options, including PackageReferences.
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!
I have a simple data structure published to NuGet that's semi-popular. It doesn't use any special Windows APIs, so I would expect it to be already compatible with UWP.
However, when people try to add a reference through NuGet, they see
<Project> is not compatible with UAP,Version=v10.0.
Some packages are not compatible with UAP,Version=v10.0.
What do I need to do to make my project compatible with UWP (while still keeping compatibility with non-UWP projects, including .Net 2.0 support)? I've read answers online ranging from "add this .json file" to "you need to maintain an entirely separate project"!
Several approaches right now,
Write a PCL which enables UWP compatibility.
Write a UWP class library which links to the common source files.
Migrate the library to .NET Core.
I use the last for my open source library and the blog post covers the details,
https://blog.lextudio.com/2016/03/how-to-port-snmp-library-to-net-core/
I am creating a fresh Mono for android application using http://xamarin.com/monoforandroid
I selected Mono for Android Application using Visual C# option.
My Android target version is :
I went to references of the project and tried adding my pre existing dlls (made in .NET 4 Framework)
and I got this error:
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
The problem here is that you're trying to reference a .NET 4 DLL from a project that isn't .NET 4. Mono for Android uses its own profile for .NET, which is very similar to that of Silverlight (but not exactly the same). While it's possible that adding a DLL compiled for a different profile will work, it's very risky as you will probably run into problems at runtime where your app will crash, due to something being missing from the Mono for Android profile.
The best answer right now is to create a Mono for Android class library, link in the appropriate files from the library you want to use, and reference that. This will give you compile-time checking that you're not using anything unsupported by the Mono for Android profile, and help keep you more sane in the long run. I have an old blog post up here that talks about how to link files across projects.
That said, in this case you're in luck because someone else has already done that last part for you! Check out this fork of Json.NET which provides versions for MonoTouch and Mono for Android.
The strange stuff is there is no option to change the .NET Framework from project properties. Can you tell me what I am missing?
It's not particularly strange - that dialog box was written by Microsoft, with its own project types in mind. It sounds like Mono for Android doesn't have the same options available.
I strongly suspect you'll just have to use a version of JSON.NET targeting .NET 3.5.
(Having said that, Mono for Android claims to support "dynamic language features" which sounds like it should be targeting .NET 4. Odd. I suspect the fix is the same though.)