These postings are provided "AS IS" with no warranties, and confer no rights.
Several folks forwarded to me Joel Spolsky's post Please Sir May I Have a Linker in which he outlines the issues with the .NET Framework redist distribution problems and calls for a simpler solution: a linker that could take your managed application and produce one atomic exe combining only the frameworks and engine components you needed to run. Now deployment is simpler and smaller, config issues are far less worrisome, and you don't need to track tons of versions of the CLR coming out. It's an appealing idea. Such technologies have been around for 50 years now, and we've played with some of them in our own space for prototyping purposes.
But do you really want a linker?
As is usually the case with this kind of technology there are lots of pros and cons. Joel's post covers most of the pros so I won't repeat them. I admit I have been tempted to write such a tool myself. I was the lead developer for the Metadata team in V1, wrote the file format spec (along with SusanRS), and helped design the CLR portion of the MC++ compiler ("IJW" -- yes, I own my fair share of blame for that damn loader lock bug -- Whibey is on its way). Although I don't code full time any more, I know I could create such a tool and it wouldn't even be that hard. I personally would use it to isolate our build tools from interim breaking changes because compiling yourself with an older version of yourself can get tricky.
But consider the down sides:
Intellectual Property - There will be people left, right, and center on this one. I don't want to provoke that debate with this post. Suffice it to say it would have to be thought out. Honestly it isn't even the worst of my worries at least for the core engine -- we already give away a lion's share of the code through Rotor (SSCLI). Let's acknowledge it's an issue and move on.
Working Set - Say this kind of tool was wildly successful, and the majority of applications out there using the CLR wound up deploying this way. Each of those processes would wind up with their own copies of the code used to run themselves, using their own address ranges because it's a linkers job to merge pieces into a new thing. There would be no sharing of pages whatsoever between processes. This would drive up system wide working set, making all of us want to go to Fry's for more memory cursing on the way there about what a pig Windows had become now that the CLR is so popular. There are legitimate working set issues we are addressing now; this makes a tough job even harder.
Servicing - I have a love/hate relationship with this one. I hate the fact that there is no way for me to patch the code with new bug fixes that may be making the system more unstable than it should be. But as an app writer I love the fact that fixes other people apply to my machine don't muck up my perfectly working application. You now understand why I am so conflicted about technologies like the GAC. Call this one a wash.
Security - But here's the real kicker: security. Put aside stereotypes and flames you might be tempted to hurl for a minute and think rationally about the problem. Say you used a tool like this and produced a little P2P file share utility ala iTunes sharing music between computers. You have this program resident on the Start bar on all your machines, listening on a port for any friends to come along. Now along comes a virus that Microsoft needs to patch in a hurry. How do I do that? You've statically linked the code with the defect I need to patch into your P2P app and who knows how many other such apps? The vulnerable app might have simply been copied to the disk making it harder to find. How do I go patch that thing and not leave your machine vulnerable? Such issues already exist for template libraries where updates can only occur through recompilation of anyone who has ever written and deployed a program using them.
There are more potential cons but you get the idea. We could have a good and spirited debate about mitigation strategies, how in a perfect world security bugs could never exist, and you could point out that Lawn Darts were only dangerous for those who didn't know what they were doing. There may even come a point where enough mitigation techniques can be brought to bare that I could be convinced it was ok to do this. But I feel there is a lot of risk associated with such a tool, and even though it is appealing in a number of ways, it isn't necessarily the right thing to do.