Visual C++ Debug Executables On Nondeveloper Machines

Well, If you need only facts then: Debug builds in Visual C++ include dependency on Microsoft.VC90.DebugCRT.dll which is installed with Visual C++ environment. This builds will not run on client machines even with Visual C++ Runtine Redistributable installed. Only Release build will run on such machines.

And here is the history how did I found this.

Recently I found that I couldn't start my application written in C++ on my netbook. At first I thought that this was the problem with hardware: program was compiled on 64-bit OS and machine and I was trying to run it on 32-bit machine. However I've tried to run program on another 32-bit machines and an attempt was succesfull. But on the forth machine it again failed to start. And by the way it provided a rather meaningless message which suggested to reinstall the problem. In .NET applications such an error is displayed if *.config file of executable has en error in XML syntax. but the was no any *.config file in this application.

I've assumed that there are missing dll file. So I've installed the only dependency that could be in this simple application: Microsoft Visual C++ 2008 Runtime Reditributable. That didn't helped. I've installed 2008 SP1 version. The same result. So I've tried to read the manifest file and found the dependency on Microsoft.VC90.DebugCRT.dll. I've compiled my application as a Release build and manifest included dependency on Microsoft.VC90.CRT.dll and application was starting on all required machines! It seems that debug vresion of C Runtime is distributed only with developer environment.

So the summary: Visual Stusio (or at least Visual C++ Express) is required to be installed to run Debug builds of programs.

NAnt over MSBuild

While working on my C# projects I found it useful for me to start using a build tool. Visual Studio builds assembly files, but many other tasks such as generating documentation are not part of assembly build and can not be just added to "pre-build" and "post-build" actions. So I've decided to use NAnt.

After some working with NAnt I decided to try MSBuild. There were some reasons for that: MSBuild is a part of .NET Framework so there is no extra dependencies; moreover it provides a good integration with project files generated by VS. But after a day of converting my NAnt project to MSBuild I've decided to return back to NAnt. There a plenty of reasons for that, which I found during this day.

The most important (for me) is that almost all settings to MSBuild tasks are set through attributes. The question "What to use: attributes or elements?" is long living and still doesn't have a clear answer (e.g. see this and this articles), but I found it a little inconvenient to set up all parameters of task through attributes. I won't speak here about what as I think should be element or property, but properties with long length data doesn't look good (e.g. lists of files).
In NAnt I feel very comfortable with setting tasks up through elements and attributes and in most cases I think that type of XML node is chosen right for property. And what is more NAnt provides and ability to define in custom tasks to define what property should be: attribute or element, while MSBuild follows it's convention and all properties are set up through attributes. Quite inflexible, though it removes a headache of deciding of type of node.

Secondly writing long lists or properties is a little inconvenient in VS: I prefer to have lines of code not very long and I need to write attributes on several lines. And if I press Enter after a property on a new line VS doesn't suggest me a list of possible items. It is need to start typing on previous line and press Enter only after writing property in editor. Of course I can write all in one line and use Wrap lines ability of text editors, but I prefer not to do so.

All-in-all I've returned to NAnt as a build tool. Sometimes I write additional tasks for it (those that are not in NAnt.Contrib) which gives me an ability to use not only for application builds but for other purposes.

Links:

• NAnt official site: http://nant.sourceforge.net/
• NAnt.Contrib (additional tasks): http://nantcontrib.sourceforge.net/
• MSBuild reference (as I found on practice links to MSDN often become broken after some time): http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx
• MSBuild community tasks (additional tasks not included in official release): http://msbuildtasks.tigris.org/