I came across this blog entry that talks about this blog entry. So this blog entry is talking about a blog entry that is talking about a blog entry - whew!
The crux of the story is how an application based on the .NET Framework should be deployed. The post goes into adding the MSM for the framework, etc. The killer quote from the first blog entry by Stéphane Rodriguez is "What should I, as a developer, think about a development framework which by design involves hacks only for my app to be deployed?"
Amen, sister!
I blogged previously about how difficult it is to determine the .NET Framework and again when Aaron Stebner produced some sample code to check this. Stéphane hit exactly on what was in the back of my mind: Why is this so hard?
In theory, the .NET runtimes are mostly backwards compatible. The version detection scheme is not future compatible - I have no idea how to detect the .NET 2.0 RTM runtime today as a setup developer. Even if I can detect this, there are no guarantees that "Compatibility and Breaking Changes" haven't affected me. At least if I could detect the version, I could intelligently deal with it. I may alert the user that the framework version installed has not been tested with my application and let the installation continue. Then again, I may choose to have the old framework downloaded and installed. Or really anything.
The problem that exists is (as a commenter to the quoted blog points out) very similar to Java's problems. Microsoft should have learned from this and done a better job. Looks like they haven't - and mostly from a documentation perspective from what I can tell.
Lastly, there is a lack of tools and guidance to setup developers and how they should handle deployment. In an MSI, why can't I simply tell the engine/tools that my application targets one or more versions, and let the engine handle the detection job along with a warning if installed framework version is greater than what is targeted?
Why must stuff that should be so easy be so difficult?
Monday, October 11, 2004
.NET Deployment
View my LinkedIn profile
1 comment:
From Stephane R.
Thanks for the link. I have two problems with .NET deployment among many :
- Sxs can be the right thing for a lot of apps, unfortunately *your* app may not be compatible with the Sxs requirements. For instance, I never heard/read/seen a .NET app installed using Sxs that is shared across several applications, like a plugin for instance.
- While Sxs solves the dll hell by isolating components, it's no longer in .NET 3.0. Jeffrey Richter who is working on this gave a pretty clear view of what to expect (on dot net rocks two months ago) : As of .NET 3.0, the latest CLR version will always be run.
- The two points above are just details among a big pile of requirements. Deployment requires much more skills than ever. The various flavor of oses, along with the breaking changes introduced by some service pack, is certainly not doing any good. So much that I would be suspicious about an app claiming to run on *Windows* (means, all versions of it), as it looks such a large scope and impossible goal.
Post a Comment