The idea behind .NET Core was to reimplement the .NET Framework as an open source, cross-platform project that could operate better in “resource-constrained environments”. As with anything rebuilt “from scratch”, Microsoft wanted to use the opportunity to clean-up the framework, though in its streamlining attempts, it may have cut out a little too much.
As you’d expect, cleaning up meant dropping some libraries and APIs, such as binary serialisation, app domains and anything Windows-specific, such as WinForms and drawing functionality.
Interestingly, reflection became an optional component and the following changes were made to .NET Core:
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.
Of course, reflection is one of the big benefits of .NET; it’s heavily leveraged for dependency injection frameworks and the like. Fortunately, Microsoft listened to feedback on these changes and a few days ago, relented on a few of its choices:
- Reflection will become the same as the .NET Framework, no need for GetTypeInfo(), good old .GetType() is back.
- Types will no longer miss members we’ve removed for clean up reasons (Clone(), Close() vs Dispose(), old APM APIs)
- Binary serialization (BinaryFormatter) will be available again
According to Microsoft’s Scott Hunter, the idea behind these changes is to ease the task of porting to .NET Core from the likes of Mono or the regular .NET Framework. Despite GetTypeInfo()
sounding like a simple change, for applications that use reflection or type information extensively, shifting over could easily become a nightmare.
Making it easier to port to .NET Core [Microsoft]
Comments