Moving from Wise to VS.NET Deployment

I just finished ditching my company's use of Wise Installer for .NET. I replaced it with the built-in Setup and Deployment project of Visual Studio .NET. Why did we choose Wise to begin with? Mostly ignorance -- I'm not a build engineer, and I was told to pick Wise or InstallShield. I was sadly too ignorant to even consider the VS.NET built-in tool. I had read it was better than the one in VB6, but the VB6 one was so bad that I just assumed VS.NET was still not up to par. I assume the person that told me to pick Wise or InstallShield has similar excuses, but he's gone now. Anyhow, my "upgrade" to the free VS.NET installer from the much more expensive Wise installer is now done -- and I'm glad to be rid of Wise.

What was wrong with Wise? First, I need to state that its probably just as good, if not better, if you are a build engineer that knows WiseScript, and the idiosyncrasies of Wise. I assume something similar can be said about InstallShield, but I don't have any recent experience with it to even talk about. The first problem I had with Wise was that it kept removing valid references or adding unnecessary ones, including duplicates, which became very annoying. I also started to experience crashes when I was doing several things, which forced me to start saving after every change. Then there was the fact that I simply don't know WiseScript, so I had no idea how to do the custom things that were starting to arise. The final blow was that Wise, at least not in my simpleton attempts, did not install assemblies in the GAC when it was told to do so! All the help documentation, and rave reviews, say its trivial -- just drag the file into the GAC folder in Wise -- but that did not work for us. My one attempt to fix this in a workaround by including GacUtil in the install, and then calling it to manually register my assemblies with one of their custom actions, did not work either. Again, maybe it was all a case of my being a stupid user, and I'll admit that I also never called Wise for help.

So why the VS.NET Installer? First, I started hearing more people ask me why I wasn't using the one built into VS.NET, which got me at least thinking. Then I read an article somewhere that really opened my eyes -- sorry, I can't find it anywhere now. So I finally decided to convert my Wise project to a VS.NET Deployment project, which the wizard in VS.NET made very easy to do. I now have my assemblies getting deployed to the GAC as effortlessly as should be, and I haven't encountered many idiosyncrasies, at least none that keep happening. One problem I found is that the deployment packages won't automatically uninstall old versions, even when you tell them to check for them they just stop and tell you to do the uninstall yourself. The fix for this was to change both the version number and the GUID product code of the deployment project itself before every build. This was easy to automate since the project file is plain text, unlike Wise's project file, so I just have a command-line app that is called from my batch file that changes these things, much like it already changed the application version numbers in all my AssemblyInfo files. I also no longer have a single EXE that includes the .NET framework, but that's not a big deal with the Setup.exe bootstrapper, so I can live with that. The main thing is that now I look forward to working with it, since I can use C# or VB to write my custom actions in the future, and therefore be far more productive. Its also nice that its free (if you have VS.NET), so all of our developers can open the deployment project now if necessary, and all of our other projects can also use it, so I guess I can even say I've saved my company thousands of dollars!

By the way, my batch file I referred to starts each build by deleting all my old code and binaries, then it gets everything from Visual SourceSafe, either from a label or the latest depending on settings.  Then it changes all the version numbers, before building all binaries, finishing with the build of the deployment project.  Finally it copies the installation files to an appropriate location.

8 Comments

  • VS.NET is ok if you've got nothing custom that you have to do, such as specialized screens to collect information about installing a database, for example. You can get around this by writing cutsom applications to assist your install, but then you lose the 'look and feel' that customers expect of your install.

    Sorry about your problems with Wise. My observations have been that Wise presents more problems at design time in the IDE, and Installshield presents more runtime problems. Of course, this is only one datapoint.



    I'm not impressed with VS.NET deployment solutions for anything but the most basic of installs - if that's what you've got, then go for it!



    I'm working in InstallShield DevStudio 9 right now, writing an install. It's not bad, but it is also quirky. Once you figure out the quirks, you can get around them. The problem is then that you get strange code to fix quirks from 3 versions ago!

  • Another thing that I forgot to mention - by changing the product code and upgrade code affects your ability to use windows installer for patching or upgrading your product in future releases. While changing the product code in development may be ok, it's not a good idea to do this in the field.

  • All the docs say that changing the version and product code should be done, and I tested that they were required in order to get old versions auto-removed. Actually, try to change the version inside the IDE and will ask if it can also change the product code (and package code), and it warns you that you should do so. The upgrade code, however, is clearly marked in the docs as not something that should be changed, and I have therefore not changed it. Is my understanding correct, or is there something else?

  • Ok, I should clarify - I was kinda vague, but this is a pretty involved topic that not even the windows installer documentation is very clear on. For example, the guidance on when to change the product code goes something like: A Major Upgrade is "a comprehensive update of the product that warrants a change in the ProductCode property."



    Changing the product code is required to get the experience you are looking for, ie, a removal of the old product and an install of the new.



    However, this is not always what you might want. For example, if you were issuing a patch or a minor revision, changing the product code might not be a good idea.



    Again, this is an involved topic, and as long as what you have works the way you want and expect, I really wouldn't sweat the small stuff. Other than upgrade behavior, changing these GUIDs shouldn't affect you.

  • I use Installshield with Windows Installer every day, pretty much. It's honestly not that hard to use once you get used to it/familiar with it.



    If you're curious how VS.Net does the GAC actions and what have you in the MSI, build an MSI, and then crack it open in Wise. You could probably even rip the custom action out of the MSI and use it later if you wanted to. Not sure though, never tried opening a VS MSI in Installshield.



    --brian



  • We use SMS Installer. It was based on an old version of Wise and seems to work very well.



    A bit strange but we install 40-50 systems with this.



    We are also going to be looking at the latest version of Wise.

  • Anybody figured out how to specify the physical location of your web site when the MSI is installing into IIS?



  • I create packages for over 16,000 workstations and though I've used different products, WISE, makes it so much easier. If you need any specifc custome actions, you can either use the quirky WiseScript languange or VBscipt/Javascript, or call your own custom dll.s

Comments have been disabled for this content.