Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have pretty large code base for the client product I am working on. I am using Visual Studio 2010 for my development and it's hectically slow. I can get rid off this by disabling the installer project within the solution file.

  • Is it a good idea to include setup projects within the same solution?
  • How can I increase the performance of Visual Studio when working with large projects (including installer?)
  • How about a different build configuration separately for installer? Will that help?
share|improve this question
    
If I remember well, installer projects have an option which you can turn on and off which actually builds the setup.exe; by default, it's turned off. Also, disabling projects (even other than the installer) is totally ok to optimize the compile time (and the time it takes to open the solution in Visual Studio). –  MainMa Feb 19 '13 at 9:07
    
to add upon, in the large projects how developers managing the the installer projects? Is it in the same way? or they work with some scripts or external solution itself to make the packages? –  sarat Feb 19 '13 at 9:34
    
In large projects, nightly builds are used. The nightly build can sometimes take hours. Those of the companies which use external solutions like Windows Installer XML (WiX) are using them not because the ordinary installer project is slow, but because it is missing features they need. –  MainMa Feb 19 '13 at 9:46
    
Solution Load Manager for VS2010 may or may not be relevant to your problem. –  Brian Feb 19 '13 at 19:53
add comment

1 Answer

If you're really sure that the slowness you notice is due to the time spent by Visual Studio packaging the application in an MSI file, then you can:

  • either turn off the building of the setup every time you compile the solution,

  • or simply unload, like you already do, the installer project. This is perfectly fine and is not limited to installer projects; you can unload anything you're not using right now, and reload those projects later when you need them. Note that you can even unload the projects which are referenced in other projects, as far as they were built successfully.

    For example I'm currently working on a project which has 35 small projects. Most of the time, only two of them (the code I'm working on and the corresponding unit tests) are available, every other being unloaded.

    Unloading projects you're not using right now has also a benefit on time spent by Visual Studio when loading the solution.

Note that companies working on large projects are using nightly builds, which may often take hours. If you're feeling that you're waiting for too long while the code is compiling, consider using nightly builds (and/or continuous integration in general; it's never too soon to start using it).

The famous "The #1 programmer excuse for legitimately slacking off: 'My code's compiling'." drawing from xkcd.com

Once you have continuous integration, you may heavily optimize Visual Studio performance by loading from the version control only the projects you need.

share|improve this answer
    
Hello. Thanks for the answer. We use continous integration and SVN as version control. But how this can really optimize visual studio performance? –  sarat Feb 21 '13 at 5:12
    
@sarat: by using nightly builds, instead of compiling the solution on developers' machines. –  MainMa Feb 21 '13 at 6:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.