How do you define a good installer?

Did read Christopher Painter blog “Back To Basics – Installation Principles” today. It contain some very basic rules of creating an installer. In his blog he lists 14 point of what to avoid and what you installer should do to be a good installer? I have personally seen big problem rise from his advice number 12 about using standard installation part and avoid using you home maid as much as possible. So to make it short, I think every installer developer should really look into this list to avoid doing the same mistakes.

And here is the list copied from Christopher.
1) Remember that your install is the very first impression the user gets of your application. If your install sucks or worse fails that will not want to use your software or your support desk will get flooded with calls. I can not understate this point. I have saved companies from the brink of bankruptcy by fixing their deployment problems and I’ve seen companies fail that were unwilling to take their problems seriously.

Read more

The pain of .NET “AnyCPU” build typ for installers

Today I found an interesting post about why we should avoid using “AnyCPU” as build type when we are building managed assemblies. The problem simple is that when installing the application and are writing registrie key we need to define if it’s a 32 bit or 64 bit application in the MSI. You can build an EXE as “AnyCPU” and on an x86 windows machine it will run on the 32bit CLR and on an x64 windows machine it will run as a 64bit process.

Christopher Painter gives this example on his blog post to explain the problem:
So let’s start with a simple example. Let’s go back 10 years in time and pretend we are writing an x86 application and x86 installer with no concern for x64. Someone hands you a vb6 EXE and a regfile ( HKLM\SOFTWARE\Company\Product type entries ) and says this is what needs to be deployed. You go off and create an MSI that writes the registry values, deploys the EXE and creates a shortcut. Now let’s come back to present. You take that MSI and throw it on a modern Windows 7 x64 box and it works just fine.

But now let’s pretend that the EXE was a .NET application. If it was compiled as x86 it would behave the same way. But if that application was built at AnyCPU ( the default for all versions of Visual Studio prior to VS2010 ) we are going to land in one of those traps. Here’s why:

MSI is marked as an x86 package so it writes the registry data to the Wow6432Node of the registry so the expected x86 application can find it. While the EXE gets installed to ProgramFiles(x86) it will actually JIT as a 64 bit process. This process will fail to find it’s registry resource at runtime and crash. This is because the .NET BCL Win32.Registry class cares about bitness.

You can find his complete post here