Deployment issues in VS 2003 addressed (hopefully!) in VS 2005

seer asked a question in an earlier post about deployment issues with VS 2003:


Why I can't create setup that install framework and MSDE? Why I must use external tools to create such setup? And please don't fix it by just adding MSDE option - I want to include my other setups also.

I forwarded this question to the Sean Draine, who is responsible for the area, and he replied to the effect that the issues are addressed in VS 2005:


We’ve addressed this scenario with the Visual Studio 2005 Bootstrapper, which handles detection, downloading, and installing prerequisite components like the the .NET FX and SSE. Out of the box, developers can choose to redistribute the FX + lang packs, J#, SSE, MDAC, MSI 3.0, the VC runtime, and Crystal Reports runtime with their ClickOnce or Windows Installer application. Developers can also leverage the bootstrapper’s extensibility model to intelligently predeploy other MS or 3rd party components as well.

You should point people to this MSDN magazine article for an overview and more details.



seer, it would be great if you could try out these features in one of the VS 2005 pre-release SKU's and let us know if your pain points with VS 2003 are entirely addressed in VS 2005.  Feel free to email me (scottwil) or Sean (seandr).

Thanks for the feedback, seer.  I wish you some happy C# coding the rest of the week!


Comments (15)

  1. James Hancock says:

    I’ve said this a million times….

    This is not a solution for MSDE. Everythign else here is just fine, but MSDE is a different beast.

    Here’s why:

    1. It’s a pig. It eats ram and is a security risk because it listens on internet ports. It should not be installed unless the application absolutely needs it. Thus if the application fails to install or the install is reversed MSDE must also be uninstalled.

    2. This way, if someone later uninstalls the application, the instance of MSDE is left on the machine unless the user knows to remove it separately (this is a problem with the way 2005 is installed too btw, way to much crap left on uninstall) End result is security risk and just bad software installation because uninstall should leave the computer exactly the way it was before the software was there. This doesn’t happen when uninstall becomes a two phase process. (Symantec should be shot for this too)

    3. There are LOTS of cases where your installer could have options in it that decide if MSDE is installed or not. (i.e. an application that can be installed as a network client that connects directly to a server that hosts the database, and can also be installed as a remote installation with it’s own database that replicates with a central server.) This very usage scenario is actually one of your center point for the disconnected univese that you brag about for Smart Client technology. (see your own web page deticated to this very thing) Thus the boot strapper cannot be the place where MSDE is installed, it MUST be installed in the Installer itself.

    Thus by opting for this stupid hack job (as I mentioned before when I was talking to the people in the SQL Server delpoyment team) you have basically created an nightmare for security, a nightmare for deployment and completely cut off one of the scenarios that you yourselves are bragging about 2005 allowing you to do ultra-effectively.

    Fix the real problem. Make the MSDE installer nestable so that we can call a custom action in Windows Installer that nests the installer for MSDE and installs the instance if we need it as part of a feature in the Installer and on uninstall calls the nested installer’s uninstall so that it gets uninstalled automatically and correctly.

    In this way, you solve the one problem you have which is patching and you address all of the other issues that I have mentioned.

    The ONLY thing that should EVER be bootstrapped is the Windows Installer runtime itself. EVERYTHING else should have merge modules or be installable through your windows installer package as part of the progress of the install. IE, MDAC, .net framework should never be installed on the machine as anything other than part of the install of your software and should be automatically removed on uninstall of your software if nothing else on the computer is using the version that you installed.

    This is reckless laziness on the part of MS and will result in a mess. PLEASE DON’T LET THIS BE THE LAST WORD ON THIS. SOMEONE STEP IN AND TELL THE RIGHT PEOPLE TO GO BACK AND DO IT RIGHT INSTEAD OF THIS HALF-ASSED APPROACH. If you have to do things to Windows Installer to make this work, SO BE IT. Give us a new runtime for Windows installer that we bootstrap to get our installer working. Anything else is not an acceptable solution.

    As it stands right now, my solution once you have removed the merge modules from SQL Server 2005 Express is to bootstrap the .net framework and then write my own installer in C# much like VB 6 had that calls all of the right controls and deals with all of this. I don’t want to, but that’s what you’re forcing me to do. Windows certification requirements to use Windows Installer be damned.

  2. Lance Delano, VS Data says:

    Let me address a couple of points that you’ve raised. First, SSE *does not* by default listen on network ports. Networking is turned off for SSE by default. So, the security risk you mention from that angle does not exist. It can be turned on, but it’s an explicit step.

    Second, wrt RAM, SSE hunkers down pretty small when not in use. It’s not eating up 40 meg of RAM sitting around doing nothing. The SQL team has also done a lot of to make SQL "get out of the way quickly" under memory pressure. It’s pretty well behaved. It sits at around 7 meg with no activity. That said, it’s not notepad either. But, for the size, it offers a lot of benefits.

    Third, since MSDE previously installed via merge modules, the thousands of installations out there in the world made slammer an incredibly hard problem for us to solve for our customers. Merge modules hide the installation and hamper the ability of MS to help customers once the developer who installed it is long gone. Given the choice between the difficulty caused by merge modules in light of some potential future slammer and the difficulty you describe with uninstall of apps, the SQL team decided for the MSI approach.

    Your call for a nestable installer is one I’ve certainly made myself many times — before I joined MS and after. It’s really bad that we don’t do this. It makes for a number of bad situations — like this one. I agree that the solution you’re suggesting is the one that we should have. The problem is that we just don’t have it yet. This doesn’t make this part of the situation any better, but I hope you understand that we agree and want the same thing here.

  3. Uwe Keim says:

    Hopefully you provide an option to include JET setup files, too. MDB files are just enough most of the times for small applications.

  4. seer says:

    Thanks for this answer. 🙂

    This bootstraper from VS 2005 will solve my problem for now. But I must agree with James Hancock that there is still need for conditional prerequisites setup – I don’t want to install MSDE if client will use his SQL Server.

    I must check if it’s present in Express edition of VS 2005 Beta to look it closely, coz this is the only one available for me now (no MSDN subscription).

  5. G. Man says:

    I dont understand this discussion. Don’t merge modules already accomplish this purpose?

  6. James Hancock says:

    Sorry, but ANY footprint left behind by an installer = I will not install that software. It shows bad programming and laziness and if they can’t even get the install/uninstall right for their software, then the rest is likely CRAP anyhow.

    And since the very case that you outline as the future of computing (smart clients with optionally disconnected states) doesn’t work with your scenario unless you’re willing to inflict overhead that isn’t needed on some users simply to solve an installer problem (see first point) you’ve completely made your product useless as it currently stands.

    If you at ms all believe that the only right way is a nested installer, then do it the right way and stop wasting time on this crap that doesn’t work, and doesn’t address the real issue.

    I understand that there is a security risk with the merge modules (and they’re buggy as hell and I have to break the DMCA just to make them work right). But consider WHY they are a security risk: 2003 (and really MSI technology in general) makes it really really hard to release updaters. V3 is a little better, but the installer tool in 2003 is CRAP. It should be as simple to create an update patch as when you build your install solution again, that it builds a patch from the original version at the same time that it builds the new installer. If you do this, then it wouldn’t have been so bad.

    Further, if you nested installs, then you could release your own patches and even use Windows update to update them.

    Further, by using nested isntalls you don’t leave a security risk on a person’s computer after uninstall.

    etc. etc.

    The windows installer team is right now working on 3.1 of the technology. My assumption is that 3.1 will be released well before 2005 and the .net framework. Hell I bet 3.2 will be released before the .net 2.0 framework. Work with them to fix whatever is wrong with the nested install approach (I have yet to get a straight answer as to what’s really wrong with it, other than my own observations that the uninstall fails) and get this all solved the right way. It can’t be that hard to address this. In fact I would suggest that if you worked with the MSI team it would take you less effort to fix this the right way with nested installs than it has already to build this bootstrap hatchet job.

    This is a prime example of the rot that is slowly killing MS. It’s this acceptance of less than excellent, that a compromised solution that is short term at best is a solution at all, that agrivates customers to no end. (see my posts about the Winforms datetimepicker control not supporting nulls after 15 years of bug reports on the subject, or my comments about the combobox control in winforms being less functional than the one in and VB6 for more examples of this stupidity that has taken over at MS)

    Fix this the right way. Accept nothing but the right way. I would argue that MSI technology is out of date and needs to be done with a .net installer that runs from an .xml file that outlines everything, and is extensible and pluginable so that we can write .net applications that consume the installer and inherit from it to make our own installs. Since that isn’t going to happen, take the way to overly complex MSI stuff and fix it so that it actually works for one of the most important cases there is. Otherwise you guys should never have pushed people away from Access and to MSDE, because you STILL don’t have a clean upgrade route for people releasing software.

  7. James Hancock says:

    G. Man

    Merge modules are being killed off because it’s hard to upgrade them. MS can’t patch a merge module install of MSDE and fix security vulnerabilities, they have to rely on the software developer to release a patch which of course is impossible to do with the tools built into 2003.

    End result is this mess that they are creating right now that doesn’t solve the problem at all. (IE install shouldn’t even be part of a pre-requisits install, it should be integrated into the installer of your application and be removed automatically to the old version of it if it is no longer used on the computer by any other application just like everything else that is installed by MS’s pre-requisits)

    Consider 2005 installer (the full one, not the express version). It installs about 7 things into your add/remove programs list. Some of which you’d never look for. To uninstall 2005 you have to uninstall each and every one of these. AND YOU HAVE TO DO IT IN THE RIGHT ORDER. If you, for instance, uninstall the .net 2.0 framework first, you’re screwed, you can’t uninstall the rest of it.

    SQL Server 2005 (full, not express) is exactly the same way. Further you must have the EXACTLY RIGHT VERSION NUMBER OF THE .NET 2.0 FRAMEWORK, or the uninstaller won’t work.

    End result? A nightmare when patches to the framework come out (I’ve tested this already btw, so I’m talking authoritatively) the SQL Server 2005 uninstaller will refuse to run and uninstall because the version number of the .net framework isn’t what it expects. So you end up having to either uninstall whatever verison your’e running and install the version it expects and then uninstall SQL Server 2005, or you have to format your hard drive.

    Tell me that this isn’t half-assed.

  8. seer says:

    Uhh, I don’t know about that.

    Why Uninstaller can’t check other aps before whole uninstall proces and then ask for user acceptance with info about apps that depends on it.


    I have one more thing that annoys me in VS 2003. In typed dataset editor there is no support in PropertyGrid for other namespaces. What I mean is that when I add


    attribute to the "xs:schema" element I want in PropertyGrid new properties to show for appriopriate elements – codegen:typedName, codegen:typedPlural and such.

  9. seer says:

    sorry I mean other schemas not other namespaces 🙂

  10. James Hancock says:

    Windows Installer Technology asside from having a huge number of holes that you can drive a truck through that can cause serious problems on install that cannot be addressed (see the windows installer blogging guys posts for this) is very very not flexible, and very very complex and as a result doesn’t allow most of the things you actually need to do with it to be done, or you have to write special custom scripts and other junk to do them.

    The biggest problem is that you can’t run to installers at the same time so you have to nest.

    Because of this and windows system file protection stuff that windows installer can’t deal with (even with a security tolken from MS to overwrite them!) we have this hatchet job known as bootstrapping.

    Bootstrapping is only there for the windows installer itself. Everything else should be done in the installer.

    Time for a new project to replace Windows Installer with something that actually works consistantly, reliably is easy to script and add on to, and addresses all of these issues.

  11. Adam Hill says:

    I agree with 99% of the above. MSDE has been PITA to install for the past 3-4 years and when Slammer came out, the patch was incredibly hard to apply.

    The biggest issue has been MS NEVER CARED TO FIX IT. No matter now much ‘suggesting’ we do to the team we get nothing but half-assed solutions. When 3rd parties cant even do automatic MSDE installs, something is terribly wrong.

  12. Brian says:

    This is somewhat related, but why haven’t there been any updates or service packs or ANY fixes for Visual Studio.NET 2003? VS6 had at least six service packs… Even Help | Check for Updates doesn’t appear to work, at least right now I’m getting the following from computers in two different locations (home and work):


    Microsoft Visual Studio .NET 2003


    Visual Studio .NET 2003 setup encountered errors while attempting to download required files. Check your Web browser configuration settings and your connection hardware, and then try again.


    Retry Cancel


Skip to main content