I have been told that I tilt at windmills, and been compared to King Lear raging at the storm. It seems I hold forth about things over which I have no control. So be it.
The deployment model that Microsoft are using for .NET is, in my opinion, outdated and untenable. Each release of the framework is dropped on the world as a monolithic block of CLR, language updates, a new Visual Studio version and a “Base” class library which tries to be all things to all developers. In this post, I would like to call into question the efficacy, if not the sanity, of this approach, particularly regarding the BCL.
The “Base” class library?
The first couple of versions of .NET included two UI paradigms within the BCL: ASP.NET and Windows Forms. If you built an ASP.NET application, you still had Windows Forms in the framework; if you built a Windows Forms application, you still had ASP.NET.
With .NET 3.0, Microsoft added WPF into the mix; the full version of that framework now included 3 UI paradigms. It also added WCF and Workflow, and then in the oddly-numbered 3.5 came the born-moribund LINQ-to-SQL ORM. Whether you wanted them or not, you got them all. This made the framework distribution large and unwieldy, and so the Client Profile was conceived, a “lightweight” version of the BCL which excluded all the server-related classes (and quite a few classes which were very useful for client development, such as HttpUtility).
During the lifetime of .NET 3.5, Microsoft discovered the “out-of-band” release model. They created another ORM, Entity Framework, and distributed it out-of-band. Scott Guthrie got bored on a plane and made ASP.NET MVC, and it was distributed out-of-band. The out-of-band model was good, although Microsoft’s apparent desire to create the kind of framework-proliferation that Java suffered from, but comprised entirely of in-house projects, was bizarre and inexplicable.
Then it was time for .NET 4, and into that was rolled Entity Framework 4.0, and ASP.NET MVC 2, an update to WPF, and a new version of Workflow for good measure. Again, there was a Client Profile. (Again, it was missing useful classes.)
Shortly after .NET 4 was released, ASP.NET MVC 3 became the current version. A little while after that, Entity Framework 4.1 appeared, and it appeared in a way that was new (to .NET) and exciting: NuGet.
Package Management
The idea of package management has been around in various guises for a long time. The Linux distribution Debian introduced the APT package manager in 1999 to distribute everything from system libraries to office application suites. In the software development world, at RubyConf 2003, Ruby programmers were first introduced to the RubyGems system: a centrally-managed repository of libraries large and small which could be installed to your system with a three-word command (plus –no-rdoc –no-ri, of course).
It took a few years, but then suddenly several package management projects were announced for .NET within a relatively short space of time, some based on (and piggy-backing) RubyGems, and others taking a ground-up, self-hosted approach. All of this would probably have remained the bailiwick of open-source enthusiasts and the ALT.NET community, but then Microsoft suddenly snapped up one of the projects, brought it in-house, hosted the repository, (changed the name to NuGet) and generally made it official, and started using it to distribute their own .NET libraries.
Brave NuGet World
So we now have a situation where the current versions of ASP.NET MVC (3) and Entity Framework (4.1) are not a core part of the framework, but are distributed and maintained through NuGet. It seems likely that the new-and-improved WCF Web API will also appear through NuGet before we get another full framework. Of course, to use these packages, you still have to install .NET 4.0, with the now-deprecated versions of all these things in it. That’s annoying.
I’d like to see the next version of .NET, be it 4.5 or 5.0, ship with a BCL that has been stripped down to the absolute basics: fundamental types, I/O, LINQ, the Task Parallel Library and ADO.NET. I don’t want to be able to write anything but Console applications with it. I don’t want ASP.NET, MVC 4, WPF, Windows Forms, WCF, Workflow, LINQ-to-SQL, Entity Framework 5.0 or any of that stuff. Instead, I want the “Add Reference” dialog in Visual Studio 11 to show Packages where currently there are GAC-registered assemblies.
Ideally, within this new Packages reference tab, I would like to see equal weight given to third-party and open-source libraries, so that things like OpenRasta, FubuMVC, Nancy, NHibernate, Dapper and Simple.Data are presented on a par with ASP.NET and Entity Framework.
In conjunction with that, I’d like it if NuGet, the enabler of this new paradigm, were distributed as a core part of the framework, much like RubyGems is now a part of Ruby, so that when I deployed my application to a web server, desktop or shiny new “device”, it could automatically retrieve – and potentially NGen and GAC – those dependencies if they were not already present, thus reducing the size of my deployment.
By adopting this model, Microsoft could not only embrace and support the many excellent third-party solutions that exist; they could also optimise the lifecycle of their DevDiv output. No longer would a release of a new .NET version herald a massive set of breaking changes to existing libraries; no longer would releases have to wait until the combined efforts of countless development teams could be wrangled into a single MSI. A new framework version would mean the next generation of languages with their supporting classes, and potentially a new CLR version. Surely that would be easier to manage than having to wait until the WPF team have got text not to look like it’s been smeared in petroleum jelly?
codeface 
Great points! Having versioned packages, all out-of-band would also make it easier to safely break backwards compatibility for the greater good of .Net. There’s so much old crap in there that something have got to go.
To add to this, I’d like Visual Studio to follow Chrome’s release model. No more a behemoth of a release, but small incremental updates, preferably happening automatically.
But a big release means easy to manage – New release installed, no work done for a day while everyone plays with the new stuff.
Constant releases, hmm, no work ever???
I could only wish that there were some meta-enterprise package management solution that could bridge both the *nix and windows world. Something like Puppet (brilliant software) but with Windows (TM) steroids.
Man, you completely forgot about Java’s Maven. Maven is a classic example of package distribution system. NuGet is nothing compared to what Maven is capable of. That’s my $0.02 🙂
That’s the first time I’ve ever seen Maven mentioned in a sentence without curse words. 🙂
“This made the framework distribution large and unwieldy, and so the Client Profile was conceived, a “lightweight” version of the BCL which excluded all the server-related classes (and quite a few classes which were very useful for client development, such as HttpUtility).”
Why don’t you just upgrade your internet connection. While you wait for the cable guy you should read “Framework Design Guidlines” from the .Net Development Series.
Download times are not the issue. Slow iterations are the issue. And I have read the Framework Design Guidelines, thank you; I suggest you read the “YAGNI” section from the Pragmatic Programmer.
But. But. But, if they constantly release all the little bits here and there, what would we look forward to?
Getting a new version of the framework is a bit like a Birthday, all the new toys to play/work/learn with.
But yeah, I use the client profile, and can see the impending… ahh, that’s not here, problem coming soon!
” I don’t want to be able to write anything but Console applications with it”
So … what about those who want?
Should Microsoft frustrate 53.5% of its developers to please you?
Unfortunately for, fortunately for us, it’s not how Microsoft works. Microsoft is one of those company who has the best records at supporting its technology for a long time.
Some say that make their product bloated. I’d say they do it quite well!
Your experience as a developer would change hardly at all. You’d just be referencing assemblies from an online repository instead of the GAC. Project templates would include references to those repositories.
And yes, they do make their product bloated very well.
I know what you mean, one of the things that MS do well is giving you something that works out of the box. All this downloading bits from everywhere is really hard work for most people.
The new version of NetBeans gives you this exact feature and is done really nicely , it’s hardly any effort to find and download a whole new framework (like MVC)
mm… so I just reference them from the web.. why not? I’d see that as an advantage if it enable more frequent release.
but for the bloated part! this is a Sparta! errr…. bollocks!
example: would removing *insert big number* DLLs from the .NET framework (those you don’t need) from the disk make your application any faster? I don’t think so…
One the other hand but that would sure cause deployment hassle to lots people… (it will even make your app directory messier, watch out! )
mm… so I just reference them from the web.. why not? I’d see that as an advantage if it enable more frequent release.
but for the bloated part! this is a Sparta! errr…. bollocks!
example: would removing *insert big number* DLLs from the .NET framework (those you don’t need) from the disk make your application any faster? I don’t think so…
One the other hand but that would sure cause deployment hassle to lots people… (it will even make your app directory messier, watch out! )
My issue is not with the size of the framework download, or the runtime performance as it relates to framework size. It is that what started out as a relatively small framework with a canonical web API and a canonical smart client API, plus the primitives that make those work, is now an unmanageable behemoth with two web APIs (one deprecated), two smart client APIs, an enterprise grade network services abstraction layer, a workflow runner, and two ORMs (both deprecated). It’s time for Microsoft to stop perceiving it as a single entity, and start maintaining these many and various components independently.
It’s also two workflow runners – since WF3 and WF4 are whole different libraries and both in .Net Framework 4. (Can’t remember if they are both in Client SKU though, if that is what you want to limit it to.)
It’s not just Client Profile I want to limit it to: I don’t even want WPF and Windows Forms in the core install.
Damm I reply to the wrong thread.. sorry… confused by your blog! 😛
I certainly see your point. In an application deployment context, I definitely like the idea where an application and its “custom” libraries are distributed with the application deployment, and the installer is capable of retrieving and deploying only those CLR libraries necessary for the application to operate. That would certainly be something worth striving for.
Also, theoretically, the concept of using NuGet, or something similar, in the actual development environment would conceivably work, but only if object browser and any successor to .NET reflector could be used somehow over the internet, as that is what you are talking about, an internet-based library repository.
The main problem I see with that model is: how much work could you get done on the airplane, bus or train (without wi-fi or 3/4g) if you don’t have “the full book” with you? As a developer, I have a good idea which general library context a library function is in, but not always. I think it would be as much of a pain to think a particular set of functionality is say in ASP.NET web forms, retrieve that, discover it is in ASP.NET MVC, and then need to retrieve that. Then the net result of that is: now your dev machine has “the whole ASP.NET library” installed when you only needed one small part from MVC, defeating a large part of what I believe to be your premise.
Also, with as cluttered as NuGet is already, I do see potential problems with finding a “peripheral” library unless that genre of distribution method is improved.
One other point I want to make is: if you want to strip down the BCL, why should any executable entry point be forced on someone? Take the ability to do a console app out too. Why should ASP.NET MVC developers carry the “baggage” of the ability to create console apps?
So, great suggestion in a deployment context, a la Server Core. In the development context, which I do admit and recognize as already being a bit cluttered now, I see the concept as trading one set of problems for another, with the main adverse side effect being creation of a limitation on the ability to work where and when there is not an internet connection.
Excellent points, and I agree with what you say about being unable to work offline. My view of that is skewed since I compose most of my apps from NuGet these days, so when I’m away from a connection I end up trawling through all my other projects looking for the assemblies I need 🙂
Totally agree that the NuGet model would need to evolve to support everything I’m suggesting, but it’s more of an evolution than a revolution. As an example, many package managers maintain a local cache of metadata which is refreshed when possible/necessary; that would probably help improve the experience.
Then again, there wouldn’t be any reason why you couldn’t have a local repo of the NuGet repo, basically setup a “sync” system to keep your “SDK” repo of NuGet assemblies therefore having them offline and not hammering the online repo all the time.
It is an interesting concept and one I think MS should consider (if they haven’t already)
It does seem pointless having “obsolete” libraries within the new framework (as what happened with .NET 4). Though I wouldn’t expect vNext being the target but more like vAfterNext 😉
I understand what you mean. I am not sure if the management of all those “packages” with the different .Net versions in the wild wouldn’t be hell. Imagine different package supporting different framework version(s).
At least now there is a kind of reset switch at every major version and the once was packages are then integrated into the framework. The only remaining problem is intermediate releases between resets.
But I agree with you on the fact that the actual framework contains too much stuff. Your suggestion is good, but I still like my reset once in a while. Maybe the solution is somewhere between the two.
I like this idea quite a bit
I know some of this has been said above but here’s my take on it.
I think a central online repository housing and maintaining each module of the .Net framework is the obvious move. There still needs to be versioning in-place of each section and released at regular intervals to prevent what would be a “Module & Dependency Hell”. I would go as far as not including any old .Net modules within each new release allowing fasing out of depricated functionality. Any new modules that require functionality or dependencies of earlier modules would include it as part the new version leaving behind the old rubbish. This would eventuate in a cleaner, faster and smaller framework.
When you would use a function or procedure in Visual Studio it would bind the particular module to the application as a dependency for build and deployment scenarios. This would require keeping a local cache of modules and their class names etc to keep performance at a premium.
When an application is deployed or packaged it wouldn’t require any of the framework to go along with it as the installer or application would request those modules from the central repository, thus reducing package size and download times.
I understand your points from a developer side, but you want to bring back global dependency on your users systems? A new “dll-hell”? For one .net programm i need this dll in this version for that one another dll. And still today not every machine is online and just can “download”. So I see your point but I don’t agree.
The model I’m proposing wouldn’t preclude the existence of the GAC; it would just start smaller and get added to by NuGet as the user installed different software packages. For example, if your application uses WPF 5.0.42.0, and the user has already installed an application which uses WPF 5.0.42.0, your app will reference the existing GAC’d assemblies. If your app uses WPF 5.1.23.0, then that version would be installed to the end-user’s GAC alongside the 5.0.42.0 version the other app used. No DLL hell.
I agree completely. I was off the .net scene for 3 years and as far as asp.net goes, I find it overwhelming to catch up with plethora of frameworks to do HTTP 😉 like cmon..
and it is not because someone got bored, but because it is on someone corporate agenda and because he is payed daily to do SMTH!
nuget+ngen+(Debian like repository – source point) is an excellent idea. especially regarding the open source libs ( which can be complied and targeted for each .net version) and I guess nuget must complie a msi for offline isntalls.
p.s. integrate some openid PLS
I really like what you are saying here, and various comments of others. I had a similar, yet different idea about the usage of NuGet to allow Visual Studio be more agile and packaged, which I posted on the Visual Studio UserVoice site (http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2035455-use-nuget-to-install-most-of-the-components)
Yet I do like your idea how you move it even further and basically make .Net = BCL + NuGet. (Where BCL is the real base class library like you say.)
The extra benefits of deployment of libraries makes this story such a MUST.
Would you mind adding your story to the above uservoice idea, or create your own and add a comment to mine? I really want these ideas to be recorded and more visible to MS, and I want to be able to vote on it.
I have voted for and added a comment on your request. You might be pleased to know that I had some very positive feedback from a few people in Microsoft around this story, so we may not just be howling at the wind.
totally agree!
That would be nice! We all see how well the “split it to atoms and update some of them – but at least three – in every day” of the Linux world is going – they are full of killer apps and customers.
That is very fascinating, You are an overly skilled blogger.
I have joined your feeed and look aheadd to seeking extra
of your fantastic post. Additionally, I have shared your web site in my social
networks