+972 52-548-6969
.NET Packaging mess
In the past few years, we had:
- .NET Full
- .NET Micro
- .NET Client Profile
- .NET Silverlight
- .NET Portable Class Library
- .NET WinRT
- Core CLR
- Core CLR (Cloud Optimized)*
- MessingWithYa CLR
* Can’t care enough to figure out if this is the same as the previous one or not.
In each of those cases, they offered similar, but not identical API and options. That is completely ignoring the versioning side of things ,where we have .NET 2.0 (1.0 finally died a while ago), .NET 3.5, .NET 4.0 and .NET 4.5. I don’t think that something can be done about versioning, but the packaging issue is painful.
Here is a small example why:
In each case, we need to subtly tweak the system to accommodate the new packaging option. This is pure additional cost to the system, with zero net benefit. Each time that we have to do that, we add a whole new dimension to the testing and support matrix, leaving aside the fact that the complexity of the solution is increasing.
I wouldn’t mind it so much, if it weren’t for the fact that a lot of those are effectively drive-bys, it feels. Silverlight took a lot of effort, and it is dead. WinRT took a lot of effort, and it is effectively dead.
This adds a real cost in time and effort, and it is hurting the platform as a whole.
Now users are running into issues with the Core CLR not supporting stuff that we use. So we need to rip out MEF from some of our code, and implement it ourselves just to get things in the same place as before.
Comments
Well said. For every 2 steps forward Microsoft takes with packaging it takes 2 steps back.
They really need to make the CLR support all of these in a unified execution, that it doesn't matter what flavor you use that it just works.
I couldn't agree more. Even with the supposedly portable PCLs, there's so may subtle issues you can run into, especially when using external packages. The very Newtonsoft.Json for example is packaged in a way that it doesn't use a PCL when you install it into a .NET45 project, but a supposedly optimized binary. The problem is, that binary has a different API surface area than the PCL. We got bitten by this when we referenced a PCL project of our own that used a PCL version of json.net and that pcl version did overwrite the .net45 json.net assembly during the build to a single outdir (i.e. Asp.net projects).
Bitten, as in production crash with TypeLoadException.
I'm really unsure why Microsoft does this. They must be aware of this mess, yet they create additional SKUs. Is it really that hard to create 2-3 well-defined subsets for the various use cases?
I recently ran this CoreCLR compat analyzer tool on a 100KLOC codebase that I run. They are using CoreCLR to get rid of obsolete (but working) stuff. This has never been Microsofts policy before. They are no longer that committed to maintaining a very high compat standard. They removed so much stuff that I will probably never make the switch and be able to use "Cloud Optimized" (which has nothing to do with cloud at all).
Maybe the community needs to speak up publicly. I'm thinking of figures like you and Marc Gravell who runs protobuf-net. This post does the community a great service. Individual grains of sand like me are not heard.
Uh? WinRT is pretty much alive; it's the primary platform for writing Windows Phone apps. On Windows itself, ModernUI apps never really took off, but I suspect this is going to change with Windows 10.
Thomas, When talking about WinRT being dead I mean that we have no requests for implementing it, no one is asking for it. It seems to be pretty much limited to Windows Phone, and working on Windows is very rare, if at all.
The Renaissance of the DLL Hell. Just this time via packages.
I think people have it backwards. One of the purposes of the CoreCLR is to try and fix the mess of incompatible APIs across the many flavors of .Net. CoreCLR is a work in progress and in many ways is like early versions of .NET which tried to focus on core use cases first.
Joe, What the CoreCLR does right now is make it harder for us to release software, because there is yet another incompatible thing that we have to worry about
Interesting background info: https://github.com/aspnet/XRE/issues/819.
Looks like there are baby steps forward at the end of the thread.
I totally feel this pain. The first time i encountered dll version conflicts I didn't even know what was happening. It took me days to figure it out. And the default error messages are not clear about this either. Imagine trying to solve this kind of problem in production that only 1 client experiences and they can't give you access remotely and the IT person on their side does not know a log4net.config file is (not all clients have advanced IT dept's).
Actually, WinRT is not dead just yet, but once Windows 10 comes into the scene, WinRT will become officially dead.
Comment preview