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.
Related
I wanted to know the difference between the two packages and if it had anything to do with .NETCore and NETStandard and compatibility. I found this:
The NETStandard target framework is an abstract target framework that represents API surface of many frameworks and platforms. As such NETStandard assemblies can run on any platform that supports the NETStandard targeted by that assembly, for example: .NET Desktop, Windows Phone, Universal Windows Platform applications, .NET Core applications, etc. NETCoreApplication is a concrete target framework that represents a single platform with both API surface and implementation. .NET Core applications are runnable on their own. .NETStandard libraries must be published-for or consumed-by a specific concrete target framework to be used in that type of application.
on https://masteringalm.github.io/framework/2018/07/24/NetStandardvsNetCoreApp-Project-Types.html
But I’m not really sure how to use this to describe the differences between the two packages. I saw a post on this link: What's difference between .NetCoreApp and .NetStandard.Library?
Where it said:
NetCoreApp is a platform and .NetStandard.Library is a library supposed to be cross platform (portable class library) for various .NET platforms runtimes.
I think this connects to differences between the two specific packages mentioned in the question header, but could anyone describe the differences between the packages in a not so convoluted way?
.net standard
Each implementation of the managed framework has its own set of Base Class Libraries. The Base Class Library (BCL) contains classes such as exception handling, strings, XML, I/O, networking, and collections.
.NET Standard is a specification for implementing the BCL. Since a .NET implementation is required to follow this standard, application developers will not have to worry about different versions of the BCL for each managed framework implementation.
Framework Class Libraries (FCL) such as WPF, WCF, and ASP.NET are not part of the BCL, and therefore are not included in .NET Standard.
The relationship between .NET Standard and a .NET implementation is the same as between the HTML specification and a browser. The second is an implementation of the first.
Hence, the .NET Framework, Xamarin, and .NET Core each implement .NET Standard for the BCL in their managed framework. Since the computer industry will continue to introduce new hardware and operating systems, there will be new managed frameworks for .NET. This standard allows application developers to know that there will be a consistent set of APIs that they can rely on.
Each .NET version has an associated version of the .NET Standard.
.NET Core is a free, cross-platform, open source implementation of the managed framework. It supports four types of applications: console, ASP.NET Core, cloud, and Universal Windows Platform (UWP). Windows Forms and Windows Presentation Foundation(WPF) are not part of .NET Core.
Technically, .NET Core only supports console applications. ASP.NET Core and UWP are application models built on top of .NET Core.
Unlike the .NET Framework, .NET Core is not considered a Windows component. Therefore, updates come as NuGet packages, not through Windows Update. Since the .NET Core runtime is installed App-Local, and applications are updated through the package manager, applications can be associated with a particular .NET Core version and be updated individually.
For more information visit https://www.infoq.com/news/2017/10/dotnet-core-standard-difference/
Overly simplistic, but think of .NET Standard as a library that runs on any platform that can run .NET. This means it can run on Linux, Mac, Windows, etc. .NET Core is a minimalistic version of the "framework", so you can keep your your apps as small as possible and only add what you need. Core means only the core functionality that is absolutely required for an app to run.
Why is standard and core different? It is largely because the functionality of .NET on other platforms started open source with someone other than Microsoft. As such, the features have lagged behind .NET. The name of the .NET "framework" on other platforms was Mono. As some point .NET Core may well replace standard, but certain things have to get to the same level.
I imagine some purist will disagree with my oversimplification, but it is an easy way to get your head around the libraries.
As for what specifically is different between the two (or "what is missing from standard to be equivalent to core") - I am not sure. I am sure it can be looked up. In many cases, I have found Core works fine, such as dockerizing the application (Yeah, I made the word "dockerizing", but meaning running in a Docker container). The problems are when you run some package that cannot be handled in "Mono".
When it comes to packages you add into the standard or Core (Nuget anybody?), where there is a difference deals with one having features that cannot run in standard.
Currently I'm working on an WPF app that will be packaged as UWP app so I can publish it in Windows Store. I'm following this video in making this happened (https://www.youtube.com/watch?v=fJkbYPyd08w)
Now, I want my application to implement Subscription Base service. So I found this link: https://learn.microsoft.com/en-us/windows/uwp/monetize/enable-subscription-add-ons-for-your-app
But it seems that I can't add UWP Windows.Services.Store Namespace library into my project. I try to seek in Nuget without success.
Where can I get this library? How to use it in WPF?
Thanks
You only need to add the Microsoft.Windows.SDK.Contracts NuGet package to your project. For details, see this blog post.
tl;dr: WPF runs on .NET Framework, UWP on .NET Core. .NET Framework and .NET Core cannot directly share code with each other, for this you require .NET Standard class libraries.
I see that you're quite new to C#, so I'll try to keep it short and simple.
.NET is a lot more than people think it is, what most people mean by .NET is the .NET Framework. What it actually is, is the Common Language Infrastructure (CLI) and the Common Intermediate Language (Historically MSIL now CIL), on top of which you have the .NET Standard, this is a base collection of classes that all .NET implementations must have and is the way of sharing code between different Frameworks.
Another layer up you get the Frameworks. .NET Framework being the most popular but also the oldest, it features ASP.NET, WinForms, WPF and more.
The .NET Core is the Framework form Microsoft featuring Cross-Platform support, so your programs can run on Windows, Linux and OS X, UWP runs on the .NET Core.
Here is a great diagram visualizing this
Note: In the upcoming release of the .NET Core 3.0, you will be able to create WPF applications running on windows (WPF will not be supported on Linux or OS X)
New to UWP. I like the idea that it is difficult (or impossible) to decompile UWP application because it is built on the .NET Native/Core... I'm wondering if is possible/a way to use UWP dll in normal .NET Framework?
I thought perhaps I could code my logic and stuff in UWP dll instead and leave all the UI stuff intact in my .NET application... so far everything I read online are the other way around, people try to reuse their existing .NET Framework libraries in UWP.
You can write a DLL targeting .Net Standard version 1.0 all the way up to 2.0 (which is the max that UWP supports in the Fall Creators Update). Once your DLL is ready, you can use it in UWP and .Net framework.
Look at the chart in this page https://learn.microsoft.com/en-us/dotnet/standard/net-standard it will help you decide which .Net Standard version to target and shows you the compatibility with various other .Net tech.
This is what I do now when I need to share code between UWP, WPF, ASP.NET, and other types of projects.
Be advised that sometimes this is not very easy, as it might require you to make some changes to your code in order for it to be compatible with .Net Standard.
I strongly suggest you look into .Net Standard as it will help you a lot.
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.
I'm using a portable library class and I'm targeting to .NET 4.5, Silverlight 5 and Windows Store apps.
According to MSDN, it's possible to use MEF in these three plattforms: http://msdn.microsoft.com/en-us/library/gg597391.aspx
But I can't accomplished to use MEF in these plattforms. What is the correct way to use MEF in PCL?
The documentation is incorrect. MEF was originally available in the box for Store apps, but due to a variety of reasons it was pulled before RTM. Currently, we have a newer version of MEF available between .NET 4.5 and Store apps (https://nuget.org/packages/microsoft.composition) but not between Silverlight, .NET and Store apps.
It's something we're considering for a future version. If you feel its important, can you file a suggestion over on uservoice: http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481-net. Customer feedback/requests are weighted heavily when determining what we work on next.