5

I'm working on a pretty simple C# solution with two projects: a class library and an installer for the library. Building the class library itself takes about a second. Building the installer, however, takes an unpredictably/incredibly long time. More interestingly, the CPU appears to be "taking breaks" during compilation, spiking a single core for 5 to 10 seconds and then hitting near-0 for several seconds.

The installer project is pretty simple. It's just the output from the class library (a single DLL, about 2MB) and a few registry keys.

Any ideas what could cause this?!

svidgen
  • 13,744
  • 4
  • 33
  • 58
  • do you have the build output? – Iain Jun 01 '11 at 14:28
  • Could you provide the output from the build process? Hard to guess w/o more info. – Paul Sasik Jun 01 '11 at 14:29
  • Might be related: http://connect.microsoft.com/VisualStudio/feedback/details/635358/visual-studio-deployment-projects-are-slow-to-build-and-dont-take-advantage-of-multiple-cpus – keyboardP Jun 01 '11 at 14:30
  • I started building again while I posted this actually, and I got an "Unrecoverable build error" -- no details. Investigating further ... – svidgen Jun 01 '11 at 14:52
  • Blog post which might help http://blogs.msdn.com/b/rajnishkaushik/archive/2007/11/19/unrecoverable-build-error-while-building-setup-deployment-project-in-visual-studio.aspx – keyboardP Jun 01 '11 at 19:24

3 Answers3

0

If anyone stumbles across this question on google and none of the other solutions seem to solve your problem and you like myself had your work on a usb drive ... dont use the usb drive . Although you only then setup one workspace in TFS and then drag the usb around its not worth it. Just create another workspace on your local drive and only use the usb when needed.

0

After tinkering with things for awhile, I found that changing the Register setting to NOT REGISTER for COM in favor of having the DLL build perform the registration, the installer build became much more reliable (and faster). I'm not sure this constitutes a solution, since COM registration should simply work. But, I've at least been able to work around the issue.

svidgen
  • 13,744
  • 4
  • 33
  • 58
0

We had this exact problem and found that the msi build process creates vsi*.tmp files in the c:\Documents and Settings\username\Local Settings\Temp folder which are not cleaned up, and thus build up over time. The more of these files that exist, the longer the msi creation takes. We solved our problem by using a scheduled task to delete any of those files that are > 24 hours old.

Note - for our situation the server was Windows Server 2003 R2 - hence the c:\Documents and Settings prefix. If you are using Windows Vista or Windows 7, you'll probably find the files by searching for vsi*.tmp under c:\Users\username instead.

user5487176
  • 1