build-process

How do I use system environment variables in my project post-build events without having to write and execute an external batch file? I thought that it would be as easy as creating a new environment variable named LHDLLDEPLOY and writing the following in my post-build event textbox: copy $(TargetPath) %LHDLLDEPLOY%\$(TargetFileName) /Y copy $(TargetName).pdb %LHDLLDEPLOY%\$(TargetName).pdb /Y ...but alas, no. The build output shows that it wrote the files to the " %LHDLLDEPLOY% " folder (as " 1 file(s) copied " twice), but the files are not in the equated path and there is not a new folder

I'm developing a medium sized enterprise application. There are many projects / solutions to this. For example: Company.Data Company.Data.LinqToSql Company.Entities (business objects) Company.BLL I then have some applications - for example a windows service: MyWindowsService. When i deploy this (by creating a setup project) it installs a load of DLL's from the output of the above mentioned projects. Is this where i should be using ILMerge? to create one assembly.... Company.dll for example? How would i go about integrating this into my build process? Cheeso The question ILMerge Best Practices

Reading this post has left me wondering; are nightly builds ever better for a situation than continuous integration? The consensus of the answers seems to be pretty lopsided in favor of continuous integration, is that evangelism or is there really no reason to use nightly builds when continuous integration is an option? If you're really doing continuous integration with all available tests, nightly builds would be redundant, since the last thing checked in that day would already have been tested. On the other hand, if your CI regime only involves running a subset of all available tests, for

At my company we are currently researching various strategies for speeding up our CI builds. We have profiled our builds and determined that we are constrained by an I/O bottleneck. We have quite a few options to deal with that in the near future (~1-2 months) but would really like to see an improvement now . I proposed using a ramdisk as the checkout and buildfile location. The build outputs and logs would of course be stored on physical disk. Is that a sensible thing to do or are there significant drawbacks to this approach? I am not looking for answers that regard the hardware side of

I have been learning C++ in school to create small command-line programs. However, I have only built my projects with IDEs, including VS08 and QtCreator. I understand the process behind building a project: compile source to object code, then link them into an executable that is platform specific ( .exe , .app , etc). I also know most projects also use make to streamline the process of compiling and linking multiple source and header files. The thing is, although IDEs do all this under the hood, making life very easy, I don't really know what is really happening, and feel that I need to get