While some applications will have an easy migration path to .NET Core, especially ones based on ASP.NET MVC, others may run into problems. Not just obvious ones such as porting from WinForms or WPF to Universal Windows Applications (UWP), but subtler issues that are deep within the core of the .NET Framework.
Reflection
The Reflection API has changed a lot in .NET Core. As with WinRT, it has been bifurcated into a lightweight version and a more expensive version. Immo Landwerth of Microsoft writes,
With the advent of .NET Native, we have a technology that allows us to statically link your application with the framework and third party dependencies. For the linking to be viable, it’s important that it can identify the parts of the framework that you’re not using. In other technologies, such as C++, this is somewhat straightforward as these systems don’t have dynamisms such as reflection. Of course, .NET Native still supports reflection but we wanted to make the platform more pay-for-play friendly, meaning that you don’t have to pay for features that you don’t use. This is especially true for reflection, as it imposes significant constraints on what the runtime and compilers can do based on static information.
So ideally, reflection should be an optional component in .NET Core that you might decide not to use in your application at all. The tricky part is that System.Object has a dependency on reflection via Object.GetType(). In order to break that dependency, we decided that System.Type no longer represents the full-blown reflection type information but only the type name. This means that System.Type in .NET Core no longer contains APIs such as GetMembers(), but continues to expose APIs such as Name.
An extension method called GetTypeInfo exposes the rest of the information that you would normally get from the Type object. The TypeInfo class isn’t as rich as the original, but Microsoft has recently decided to bring back some reflection APIs that that weren’t planning on supporting in .NET Core.
In order to make code more portable, .NET 4.5 and later supports a version of TypeInfo that is similar to the one in .NET Core.
App Domains
App Domains are implemented by CoreCLR, but not .NET Native. Due to the amount of runtime support needed, there is no plans on adding it. “For code isolation, we recommend processes and/or containers. For dynamic loading of assemblies, we recommend the new AssemblyLoadContext class.”
Remoting
These days few developers even remember the Remoting library exists, let alone how to use it. And those who did often complained about its performance, complexity, and overall brittleness.
These days, communication between .NET applications on the same machine it has largely replaced with WCF, or for higher performance, pipes or memory mapped files. Across machines, Microsoft recommends “a low-overhead plain text protocol such as HTTP”. Thus Microsoft has no plans to include Remoting in .NET Core.
Serialization
Most of the serializer such as data contract serialization, XML serialization, JSON.NET, and protobuf-net will be supported in .NET Core. The major exception is binary serialization.
After a decade of servicing, we’ve learned that serialization is incredibly complicated and a huge compatibility burden for the types supporting it. Thus, we made the decision that serialization should be a protocol implemented on top of the available public APIs. However, binary serialization requires intimate knowledge of the types because it allows to serialize object graphs, which includes private state.
Sandboxing
In theory sandboxing is a great idea; it allows for the execution of partially trusted code in a secure manner. In practice, it is very difficult to get right and the slightest mistake leads to a security vulnerability. Immo Landwerth also says that it “makes the implementation more complicated and often negatively affects performance of applications that don’t use sandboxing.”
The recommended alternative is to spawn separate processes that run under a user account with restricted permissions. That way the runtime doesn’t need to duplicate the often expensive permission checks the OS is already running.
Other Components
Components on this next list are under consideration for being open sourced and ported to .NET Core.
- System.Data. While the base layer is already part of .NET Core, i.e. the provider model and SQL client, some features are currently not available, such as schema support and DataTable/DataSet.
- System.DirectoryServices. There is currently no support in .NET Core to communicate with LDAP or Active Directory.
- System.Drawing. While strictly speaking it’s a client API, many developers use the drawing API on servers to provide thumbnail generation or watermarking. We currently don’t have support for these APIs in .NET Core.
- System.Transactions. While ADO.NET supports transactions, there is no support for distributed transactions, which includes the notion of ambient transactions and enlistment.
- System.Xml.Xsl and System.Xml.Schema. .NET Core has support for XmlDocument as well as Linq’s XDocument, including XPath. However, currently there is no support for XSD (XmlSchema) or XSLT (XslTransform).
- System.Net.Mail. There is currently no support for sending emails from .NET Core using these APIs.
- System.IO.Ports. .NET Core currently doesn’t include the ability to communicate with a serial port.
- System.Workflow. The Windows Workflow Foundation (WF) is currently unavailable on .NET Core.
- System.Xaml. When creating UWP applications, developers will use the WinRT XAML APIs. Hence, .NET Core currently doesn’t include the managed XAML framework, which includes the ability to parse XAML documents and instantiate the described object graph.
Would you be interested in helping us to port a component? In some cases, the source code of the .NET Framework implementation has been made available under MIT, as part of reference source. We’re looking into ways to enable the community to support our porting efforts. If you’re willing to participate, shoot me an email at immol at microsoft dot com.