Shaping the next generation deployment experience


We are thinking about the next version of Visual Studio’s deployment experience. I need your help to make the next version of Visual Studio’s installation and deployment as valuable as possible.


Please send me your feedback. For example, I am looking for feedback in the following areas:



  • Do people like a lot of install options or just as few as possible.

  • Installation type: 


    • Do people install through the UI or silently?

    • Do you launch and forget about the installation or watch it go?

    • Is there a silent installation method that you would like to see supported in the future?

  • What is a reasonable time to install the product?

  • Do people like the companion products that we install?

  • Do people ever look at the installation logs? If so, what for?

  • How do you deploy your applications to your customers?

  • How often and under what circumstances do you uninstall Visual Studio?

  • How often and under what circumstances do you add/remove features to/from Visual Studio?

Additionally, Have you installed any applications recently, which had a cool install experience?  Tell us about it.


Send feedback and comments to aaronru@nospam_microsoft.com (prior to sending please remove “nospam_”)


Thanks for improving Visual Studio.

Comments (28)

  1. Summary and action required We need your help to improve the Visual Studio Deployment experience. We

  2. Aaron Ruckman is looking for feedback on your experience of installing and deploying Visual Studio.

  3. Aaron Ruckman is looking for feedback on your experience of installing and deploying Visual Studio.

  4. Summary and action required We need your help to improve the Visual Studio Deployment experience. We

  5. What are your thoughts on the Visual Studio deployment experience? Have some feedback you’d like to share?

  6. What are your thoughts on the Visual Studio deployment experience? Have some feedback you'd like

  7. Do you want to help shape the future of deployment for Visual Studio code name "Dev10"? Aaron Ruckman

  8. 我们正在思考下一代Visual Studio的部署体验。我们需要您帮助使下一版本Visual Studio的安装和部署尽可能有价值。 请发送您的意见,比如: Do people like a lot of

  9. Do you want to help shape the future of deployment for Visual Studio code name "Dev10"? Aaron

  10. 我们正在思考下一代Visual Studio的部署体验。我们需要您帮助使下一版本Visual Studio的安装和部署尽可能有价值。 请发送您的意见,比如: Do people like a lot of

  11. Summary and action required We need your help to improve the Visual Studio Deployment experience. We

  12. Aiutiamo a migliorare la procedura di installazione di Visual Studio!

  13. G.T says:

    I would like next VS.NET to again double its installation time, hours are not enough, and I think you should move to days.

    I would love to press the “yes please install that too” dialog box over and over and over in your service packs, for example SP1 for VS.NET 2005 was wonderful, 4 hours to install, and a dialog box that popup every hour that asks you if you still want to continue the install, keep the good work!

    Now about MSDN, the initial installer is just too fast, GBs of contents are copied to the hard drive in no time, thanks god that the last step of the installer there takes an hour of recompiling and rebuilding the MSDN indexes and content merge, that’s what I am taking about.

    We, developers all over the world, will be calling the next VS.NET installation the “deployment day” or D-Day, where we will be installing the developer edition, then the database additions, then the TFS client, then the SQL server, then the additional libraries, then the SP1 and …….

  14. If it does, let Aaron Ruckman know 🙂 Well, he asked, in fact, he’s asked if there are better/cooler

  15. If it does, let Aaron Ruckman know 🙂 Well, he asked, in fact, he's asked if there are better/cooler

  16. G.T says:

    I wish if the installation performance was faster, all what the deployment does at the end is copying files from a DVD or a set of zip files to the hard drive, then it creates and modifies a long list of registry entries, nothing more than that.

    To understand me better, forget about the tons of artificial complexities introduced in this deployment tool, forget all these wonderful layers and ideas inside, forget all the rocket science, and perform that test:

    • Write a small tool to track all the files modified on the hard drive, and all registry entries during the installation, and log them to a text file.
    • After the installation, gather all registry modification in a text file (.reg) and all files copied from the installer above to a zip file.

    • On a new machine, extract the zip file and merge the registry file, and you will find that this will install VS.NET One thousand times faster or maybe more!

    • Then think about it again, if it was just a zip file and a reg file, how many machines will it work on? We have 2 CPUs (Intel and AMD) (which may mean 2 sets of zip files only, 3 perhaps?)

    When too much ideas in an installer are really too much? When will Microsoftians start thing about the user really want not about what a Microsoftian really wants to code today 🙂

    Think of it the opposite way, if a microsoftian added on his resume “I wrote the installer of VS.NET 2005 SP1” and he applied for a position in a company where developers lost thousands of working hours updating that product and pressing the ok button once every half an hour, do you think he will get hired? 🙂

  17. The Other Steve says:

    The VS2005 SP1 install was probably the best in class.  Everything should be done like that in the future!

  18. Aaron Ruckman has posted a request for feedback on his blog at http://blogs.msdn.com/aaronru/archive

  19. Want to tell us about your cool / not so cool experiences with deployment of your apps? Then go here

  20. Installed it, failed! Installed .net framework 3.5 by myself. Tried to install again, worked like a charm!

  21. dankline says:

    Hi Aaron,

    Visual Studio 2007 was one of the most difficult installs in my career … but that was probably becasue of trials, CTPs, and  BETAs.  I’m aware of the recommendations against installing these on production machines, but it’s almost inevitable that some of this code will end up on production machines.  One of the key reasons to install the code is to get familiar and confortable with the changes coming in our tool sets.

    The short message is, please make the uninstall a part of the packaging and testing of these previews.

    My personal preferences for install are GUI with recommended options for default, but the ability to fine tune the installation by changing installed options if I choose.

    Installation durations aren’t a huge issue for me.  If it takes longer to get it right, I prefer that to having to troubleshoot unresolved issues during install.  

    I don’t generally use the companion products … more often than not because it becomes just another tool to learn.  

    I never look at the install logs unless something goes wrong.  In many cases, the logs aren’t helpful enough to be useful.

    My deployments are generally done personally.  Thank God for Flash Drives.  But I prefer to see the application operational in the customer’s environment before I hand it over.  I can’t afford a lot of support time and effort.

    I would never choose to unistall Visual Studio or its components.  But I did uninstall VS2005 trying to troubleshoot my VS2008 BETA.  It didn’t help.  In the end, I ended up reinstalling Vista, reinstalling VS2005, and installing the VS2008 Beta.  That worked, but as you can imagine, it was painful and time consuming.

    BTW – Your blog provides the most useful info on VS install issues… thanks for your help.

  22. kevin@kevindavlin.com says:

    G.T. said: "I wish if the installation performance was faster, all what the deployment does at the end is copying files from a DVD or a set of zip files to the hard drive, then it creates and modifies a long list of registry entries, nothing more than that."

    You have obviously NEVER written an installer before have you?? I have and I’m DYING to know how they built they Visual Studio installer!! 🙂

    If I answer the survey will you guys send me the WiX source for that installer??? 🙂 (Seriously?)

  23. CerfurMark says:

    I want to complain about the VS 2005 for Vista Update.  My Vista machine tried to install this update over and over again via Windows Update.  Every morning, I would turn on my machine and it would be unusable for 30 minutes as the TrustedInstaller tried to install this update.  Then, apparently it would fail, and I would suffer the same fate the next morning.  Today, I downloaded this update manually and ran the update as Administrator.  The progress bar sat at 3 seconds remaining for 15 minutes, and the finally and supposedly, it completed.

    My request, then, is that all installers should display progress.  Show me what’s happening.  Make me fell warm and fuzzy inside that the system is not locked up.  The example I really like from Microsoft is the SQL Server Data Extract user interface.  It really gives a clear graphical display of what’s happening in the extract process.

    Please don’t make any more installations where all you see is a spinning circle or no progress bar movement.

    Thank you.

  24. whyaduck says:

    "It means that I work to make sure that the End-user’s and devloper’s Windows Vista Experience is pleasant for supported versions of the .Net Framework."

    FAIL!!!11!!

    I’m done installing ANY and ALL Microsoft beta development software.  I continually get burned by it, and the latest fiasco with VS 2008 is the last straw.  Done done done and done.

    Sorry if that was overly negative, but there’s no way your development team should be throwing beta software over the wall if you’re not going to be able to come up with a simple upgrade path on release of the retail version.

  25. ColinBowern says:

    A few scattered thoughts…

    I think you’ll find several profiles of developers out there (e.g. the VC# web developer, the VC# winforms developers, etc..).  To each their idea of what they need will differ.  I never install Crystal, for example.  I generally prefer fewer options, less bundling of stuff within the core install.  I don’t mind that you bundle SQL Express, but leave it out of the core because they rev at different time frames (e.g. SQL 2008 will come out with their own express, or a service pack that renders the version on your media out of date).

    I would like to be able to silently install so we can automate dev workstation rebuilds.  It should be easy and leverage the existing Windows Installer infrastructure (please don’t reinvent the wheel again!).  I would like to be able to build an MST with what I want installed where and re-use that MST elsewhere (heck, it would be great to run through an install and instead of hitting "Install" I hit "Generate MST" and it works.  Worst case scenario look to the Office team for their tools for creating custom MSTs.

    A reasonable time is as long as it takes.  VS is a big product, we understand that.  Don’t bake in products that you don’t control or that are needed.  That will keep it nice and small.  I look at install logs when things go wrong for some indication of what I can do.  VS, though, has become too big to reasonably expect to find anything useful beyond an obscure acronym or component ID.

    We are working on evolving our deployment story in house.  The idea is that setup consists of two distinct phases – installation and configuration.  Installation gets the necessary bits in place where configuration is the tuning the default settings to your liking.  For Visual Studio the tools | options section is all about configuration.  There is a lot of power there not exposed to end users.  Assume as well that I want to preseve/migrate my existing settings, or at least detect that during uninstall/reinstall.

    I reinstall VS every four to six months when I rebuild my dev workstation to clean all of the beta garbage out.  That’s why I want to automate it.  I rarely add/remove features because I spend time to understand what I’m installing the first time.

    When you uninstall though please remove everything.  I understand that there are some challenges with a shared shell environment, but it sucks that I uninstall the team suite trial, install the team dev edition and find that some components from the trial are still loaded.  Separate your concerns from .NET runtime bits and development components too.  Ask all other product groups that plug-in to follow a install/uninstall guideline too so they don’t contaminate the experience.

  26. MSDN Archive says:

    Please ship me a hard drive in the box 🙂

  27. GM says:

    I had two very simple applications that I could never deploy to a Windows XP  computer for testing. I created several setup/deployment projects, installed several redist for 2005, 2008 still I could never get either application to run. I kept getting the same error that it could find Microsoft.VC90.DebugCRT when it was installed in the winsxs and winsxs/manifest folders. The dependency check indicated no issues with any of the DLLs. But still the application failed to even start. I finally removed Visual Studio 2008 and went back to 2005 and I was able to rebuild and test my applications. The online formation was useless. Microsoft information offered no way to debug such a problem other than the dependency checker. This is one of the reasons I don't care to upgrade my Microsoft products unless I have no choice. To upgrade is always a nightmare and not easy to go back. Thank goodness of backups

Skip to main content