I have a Xamarin Forms application that uses shared code. It has three projects, shared, iOS and Android. These are very similar to those which are created when I create a sample application from the Xamarin new project menu.
I am looking to have the application updated and published by a company that has experience in doing this but I am not sure I understand a couple of the work items that have been suggested to me:
Currently, architecture is PCL which is becoming
obsolete.
Move to .NET standards
Could someone explain to me what these work items might mean?
Yes, it will become obsolete at some point. .NET Standard is the evolvement of the PCL libraries.
With PCL libraries you could target a number of platforms and only the functionality that was supported for all targeted platforms were available to you. Associated with each combination of platforms were the profiles. A profile was identified by two or three digits. Notable ones for Xamarin were 111 or 259. Read more on PCLs here: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/pcl
.NET Standard is a specification of the APIs associated to it. If a platform supports a certain version of the .NET Standard, you are guaranteed that all APIs are available. This way, you can simply target a specific .NET Standard version and each platform that supports it will support your application. The .NET Standard specification has gained a lot of traction and is already more cross-platform than a PCL ever was. Most of the creators of NuGet packages are supporting it already and also Xamarin/Microsoft has replaced the PCL with a .NET Standard library in their templates. Read more on .NET Standard as a concept here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
So, if you have the possibility it might be wise to start moving to the .NET Standard library. That is, if you want to keep supporting your app and need new libraries coming in. If your app is fine the way it is, you can probably keep going with the PCL for a while. Converting is basically: change the csproj structure to the new structure. Retarget your library to netstandard and reinstall all the libraries you have installed, this time to download the .NET Standard compatible version. The last step might be a bit of a pain.
A good resource on converting might be this by Adam Pedley: https://xamarinhelp.com/upgrade-pcl-net-standard-class-library/
There is also a solution to do it automatically: https://smellyc0de.wordpress.com/2018/03/23/automatically-converting-pcl-to-net-standard-2-0-project/
.Net Standard is a specification for a set of APIs. and is the way things are going. With it, comes a higher level of range of .Net SDK APIs you can use, plus most 3rd party Nuget packages will support it. They can support a wider range of platforms. by targeting .Net Standard. Thus you will get access to a larger number of nuget packages. See https://learn.microsoft.com/en-us/dotnet/standard/net-standard
I put my Forms Apps into a .Net Standard library, because it easier to unit test. There is a Xamarin Forms nuget package you can use for testing, which means a lot of UI paths can be verified in code, where previously you had to do it on a device, perhaps with automated testing. https://github.com/jonathanpeppers/Xamarin.Forms.Mocks
Upgrading an existing PCL project to .net standard is a pain. Any more, I just create a new Xamarin Forms solution with the same name/root namespace, with the app as .Net Standard, then copy files over.
Related
I have a C# project which was created using NetFramework 4.6. I want to convert it to using the NetCore 2.1.
I checked the network, and people say I can just change the Target Framework value in the project's properties page. But on my computer, I cannot see options for NetCore.
I already have the NetCore 2.1 SDK installed.
Is there another way to convert the project? Is there something wrong with my project that prevents it getting converted?
People are wrong, there is no such "one step" approach.
Remember that .NET Core is not a higher version of .NET Framework, it is rather a rewrite from scratch. So it does not work like retargeting .NET Framework version form 4.0 to 4.5.
Porting to .NET Core from .NET Framework is a good place to get started.
Edit: This page lists some differences between .NET Core and .NET Framework.
You can't do this simply like this; because of their totally different frameworks, not different versions of same framework. You have to port your project to .net core; there is one of the nice extension for visual studio that generate a report for you about how portable your code is between .NET Framework and .NET Core.
This is also one of the article about the issue that may be useful for you.
I've created a Cross platform Application for Xamarin in Visual Studio. The application is running on .NET Standard 2.0 and it's not possible to select a higher version.
Isn't possible to run a Xamarin project on a newer .NET version? The problem is that a want to install nuget packages that requires at least .NET 4.5.
Thanks in advance.
You are confusing .net and .net standard. .net standard gathers many other .net platform (for example .net core, uwp, windows phone etc...) including the classical .net (from 4.5 to 4.6.1). Take a look at this table to have a better understanding.
This means that you should be able to include your library that targets .net 4.5.
Now that you know that, you can define a fallback version if the library does not target .net standard. To do so add this line in your .net standard .csproj in the PropertyGroup node
<PackageTargetFallback>$(PackageTargetFallback);portable-win+net45+wp8+win81+wpa8</PackageTargetFallback>
.NET Standard is a standard, official documentation is nicely covering it. Beside that must read, here is a compatibility table.
So please, read the official documentation. Setup your mind and come back with a proper question. Currently it does not make sense.
Good luck!
P.S.: Currently you are trying to use an outdated library that does not support .NET Standard, you might want to look for alternatives.
I have one PC with Microsoft Visual Studio Community 2017
Version 15.2 and it has a project template for Class Library (Portable).
Another PC with Version 15.3.1 has a template for Class Library (Legacy Portable). Are PCLs now legacy ?
Any current news on what I should be using instead ?
Well, "should", I won't say that without seeing exactly what you're doing but yes, PCLs are now "legacy", the new way is .NET Standard and .NET Core.
Please note that legacy does not mean "will stop working" so there shouldn't be a need to do anything as of yet.
To figure out which kind of .NET Standard version you want to target to get-out-of-legacy, you can consult the compatibility list on the .NET Standard web page.
Specifically, you likely want to consult the other matrix on the same web page, the .NET Implementation Support matrix and figure out which platforms you want to target, then create a "Class Library (.NET Standard)" project targetting the highest .NET Standard version you can get away with.
I build a lot of packages that have cross-platform targeting. I like using NuGet as a deployment for all of the obvious reasons, but I'm having difficulty understanding how I target a specific binary for Mono on Linux.
As an example I have a library that, in the Mono for Linux version, references `Mono.Posix.Helper.dll. This is very specific to Mono on Linux. It's not for the desktop. It's not for Mono on Android or Mono on iOS. The same library has different implementations for .NET of the desktop, .NET on Windows CE, Mono on Android and Mono on iOS.
It seems that I need two things, neither of which I can seem to find:
A way to tell NuGet that a specific set of binaries targets Mono on Linux. I see nothing in the official documentation of the NuGet schema target frameworks.
A way to tell Visual Studio that my project that will consume those binaries targets Mono on Linux. I've found this nice list of project GUIDs but, of course, there's nothing in there for Mono that isn't targeting Android or iOS.
Right now I'm solving this with a less-than-friendly post-build task, but that's really not fun when I need to create a new project that uses one of these packages.
I know Microsoft has been trying to get more Linux-friendly over the past few years, but this seems like a pretty big hole. I can't be the only person out here that's building code for Mono on Linux, can I? What's the solution here?
Currently, this isn't possible.
NuGet (3.*, 4) does have a concept of "runtimes" but those are referring to the operating system that the "runtime" runs on. So while you can have a specific asset for linux-x64, this cannot tell if you are on mono or .net core. In fact, even when you use a net461 target framework with a runtimes/linux-x64/lib/net461/linux-specific.dll file, this may even be used in a .NET Core 2.0 app since .NET Core 2.0 can use net461+ libraries.
The only way this is currently possible is to have managed shim that resolves the right assembly on runtime. This would also make the consuming project "portable" - meaning it can be run on windows directly and on linux through mono, assuming all libraries can be loaded dynamically.
I have a Windows Phone 7.1 project with a Portable Class Library targeted to SL4, .Net4.5, WP7.5, Store Apps, but this is not available: http://msdn.microsoft.com/en-us/library/dd642331.aspx
It says it should be available in .Net 4.5. Of course I can program it myself, but I prefer to use functionality provided by the framework.
If I change to Windows Phone 8 (and remove SL4) it is available. Any hacks possible to get it working targeting WP7.5 / SL4?
You'll need to implement it yourself for WP7.5 and SL4. However, you can make it so that on platforms that already support it (ie .NET 4.5, WP8, etc), it will use the in-box version (and thus you can share it with other libraries that use the "official" version.
Basically, create your implementation as a PCL that targets all the platforms you want. Then create another PCL targeting the platforms that do support System.Lazy. This second library should have the exact same assembly identity as the first one, but instead of having an implementation of the type, it should use the TypeForwardedToAttribute to forward to the existing version of the type.
Then PCLs targeting broader platforms can use the first assembly you created, while platform-specific projects or PCLs targeting narrower platforms can reference the second one. You can make it easy to reference the right version of the assembly from the right projects by packaging them up into a NuGet package.