The case for or against .NET (the beast) [closed]
This is the reason to why many companies have switched to web installers that download all prerequisites on the fly from your homepage. Since in most of the cases, the OS have 99% of what's needed (if they have been updated using Windows Update).
I would not put everything for x64 and x32 in the same installer. Create two installers, one for each architecture.
Paint.NET wraps the installation of prerequisites up nicely without bundling the .NET framework with it by default. The end result is an unmanaged shim executable that checks for the .NET framework and some other stuff and holds your hand as it gets installed; all downloaded on the fly as they are needed. They then run a WinForms application that pInvokes into MSI to further wrap the installation up in cotton-wool.
Worth a Google.
Also likely is the fact that a lot of client machines will already have some version of the .NET Framework installed as it is part of Microsoft Update - making it more easily consumable in the business world.
Paint.NET blog posts about installing:
http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/
http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (thanks Rup!)
Reading into the story a little more, presumably management had to go through the pain of deployment with the C++ application at least once, but it is now done and classed as "easy". Put some time against the deployment and present this to management and, hiding the pain, show them how easy it is to install :)
Let's go back to why you wanted to switch from native code to .NET code in the first place: it's more efficient for you, as a programmer. Many things are easier in .NET than they are in C++ (or whatever native language you're using), and so you can develop your applications much more quickly.
Then, how does the time you spend developing the application compare to the time you spend developing the installer? Even if you have to spend a couple weeks nailing down the installer (specifically the framework setup portion), that should be more or less the only time you have to go through that.
For all future applications, you would be using an almost identical installer; you would still do all the prerequisite checks, but instead of copying files to C:\Foo, you're copying some different files to C:\bar.
In my opinion, this is a simple question of economics. Yes, it's more expensive to develop a (good/complete) installer for a .NET application, but if that's the step you need to take once to dramatically improve your development time, it's a no-brainer. Your return on investment would probably be in the order of weeks.
I feel I need to respond to this statement:
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
If your user is insistent on shooting themselves in the foot by operating a system that the vendor has informed them is no longer fit for purpose, then there's nothing much you can do to 'help' them. I'm aware that this makes me look like something of an obnoxious activist, but I look at it in the same way that a manual tradesman might - it is up to the customer to ensure that the environment in which they want me to work is sound and appropriate for the product. If it isn't, I'll accept further renumeration to do that job as well, but it might still cause them extra work because they haven't had the foresight to make sure they understood what they were buying.
I believe software customers have been allowed to remain ignorant for long enough, and that they should now be required to understand what it is they are buying. Operating a corporate IT environment that isn't properly patched is the same as continuing to run a vehicle that has been subject to a manufacturer's recall - a Windows service pack is equivalent to a recall in many respects. You're not legally obliged to submit to a recall, but it's in your best interest as a business and you may be held responsible for damages caused by your shirking of responsibility.