4

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?
Improve this question
4
  • 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). Commented Feb 19, 2013 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? Commented Feb 19, 2013 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. Commented Feb 19, 2013 at 9:46
  • Solution Load Manager for VS2010 may or may not be relevant to your problem. Commented Feb 19, 2013 at 19:53

1 Answer 1

Reset to default
1

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.

Improve this answer
2
  • Hello. Thanks for the answer. We use continous integration and SVN as version control. But how this can really optimize visual studio performance? Commented Feb 21, 2013 at 5:12
  • @sarat: by using nightly builds, instead of compiling the solution on developers' machines. Commented Feb 21, 2013 at 6:40

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.