The case for or against .NET (the beast)

The company I work for uses C++ Builder 6. We've been developing native code since conception. Our flagship product is written completely in native code.

Enters the .NET Framework with its bells and whistles. I fall, hook, line and sinker. I convince management that .NET should absolutely be our new framework for all new software development and that we should start migrating our existing codeline ASAP. With all the benefits it doesn't take much convincing. They accept my proposal as usual.

At this point I start developing my very first .NET application. It's all going as planned. The project is only one component of our product. And so I get to the point of creating an installer for this new component. As a company we pride ourselves in making things for the user as easy as possible. Even Microsoft with thousands of developers don't create installers like we do. When you install Microsoft CRM for instance, you will only get a list of failures and prerequisites that needs installing before you can continue. Not us. Never. If you need something, we will install it for you.

This makes our installations feel so easy. .NET Framework not installed? No problem! We'll do it for you. Need SQL Native client? Fine!

The issue is this, now that one single component of our solution is written in .NET, it complicates the installation process incredibly. Before I can even get to installing our product, I need to do the following:

• Detect whether the prerequisite is installed

• Install it if it isn't

• Verify that it was installed successfully

• Next prerequisite

To install .NET Framework, I need the Windows Installer 4.5 first. But there are different versions for the different OSes, so I add OS detection and launch the correct EXE. Oh, .NET framework is already packaged with 2k8 and the installer exe cannot run on it, you have to run OCSetup.exe with parameters to install it.

And so it carries on. Then SQL Express 2005 needs to be installed. The dependencies increase once again.

I argue with management that even Microsoft don't make it this easy for the user. Their response is that there is no reason for us to not be better than them in this way. I can't argue with that except that I feel that there are very good reasons they've gone with their approach.

Suddenly, our installer is massive. All the prerequisites for .NET, not even talking about 64 bit support which has a whole separate range of EXEs to install. So now it gets to the point where we want users to be able to download a "quick" evaluation. What a joke. You need to download 500MB to get a 30MB application running. The majority of the installation package is prerequisites.

Management feels that we have too many dependencies/prerequisites. I understand completely. They suggest we move away from the .NET framework, back into native land where things were still "easy" in terms of installation. This is where the one part of me wants to stand up for .NET explaining the benefits in the big picture, the improved development experience, easier maintenance and overall code quality. The other part of me agrees with them wholeheartedly! Developing in .NET simply requires you to install too many other prerequisites which complicates the installation.

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.

We are now considering writing native code again and I know we're losing in terms of development speed and all the goodies of .NET. But we are gaining in this area, be it small if you look at the big picture or not. As we have native code development skills and .NET is actually new ground for us, it even makes sense to move back.

My question is this: what is your company's view on this issue if it even is an issue at all and what will the business case look like that I propose to management assuming I want to continue migrating all our products to .NET?

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.

Any Visual C++ app has prerequisites / external dependencies as well: runtime 6.0, 2003, 2005, 2008 or 2010? no SP, SP1 or SP2? x86 or x64? What version of Windows Installer does 2005 SP2 require? And what 2008 SP1? And so on, so on.

Thus that's far-fetched arguments! Like Joel's grumblings about .NET. And look what's now!

I don't see how there are significantly more pre-requisites for .net over C++ Builder. You complain about SQL Server, but you ignore the fact that you have to install some database with C++ builder as well. You complain about x64 vs x32, but .NET doesn't require any change.. the same exe runs on both (and compiles itself optimally for either environment). The same can't be said about C++ Builder. You may need seperate versions of SQL server, but again that would apply to C++ builder (unless you just install x32 on everything).

Yes, there are the new installer version issues, but those components aren't very big. And you really can get the installers to download and install only the aprts that are necessary.

C++ builder is probably easier for you because you've already invested the time in creating a good installer. You need to do the same for .NET, and then you can choose based on real issues.. and not this.

By the way, the reason Microsoft chooses to do things the way they do is that many users, especially corporate users, do not appreciate having things installed for them automatically (perhaps because they have an application that depends on a specific version of a library, and you come along and wipe it out with a new version that they can't easily uninstall).

What you view as "making it easier" for less knowledgable people is actually making things MUCH harder for those that know what they're doing.

Here's a good example. One thing I absolutely despise is when I install an app that needs SQL Server, and it installs its own instance of SQL Server, even though I may already have several instances already that it could use. Easy for the novice, a pain in the ass for me to try and get your app to work with my single instance.

If your app runs under Mono, then shipping your app with the Mono runtime might be less painful.