Canvassing to get Microsoft to provide the option to stop on the first error

For all sort of good reasons, it would be great to have the option to stop a build in C++ or a compilation in C# at the first error; there are a lot of scenarios where we would save a lot of time (and therefore money).

It seems Microsoft hasn't been keen on solving those issues for years, and while it is possible to find work around on certain circumstances using macros (calling DTE.ExecuteCommand("Build.Cancel")), it would be a good idea advising Microsoft to revert his opinion about the severity of those issue.

If you have a Microsoft Connect account, when available please invest a minute on voting those issues:

• C# : Compiler should stop on First Error for C#
  
• C++: Add an option to stop build on error
  

From my own point of view they both deserve 5 stars.

Thank you,

How to fix fatal error A1000 while compiling Crypto++ 5.5.2 on VS 2005

The possible cause

A white space on the path to the asm file.

The possible solution

If so, the solution is really simple (well, once you know it or you read it here or in such a place): open the solution in VS 2005, in the solution explorer locate x64masm.asm (should be between the Source Files of the crypdll project), right click on the file name (or do whatever you need to do to get the context menu), select the property menu item, go to Configuration Properties/Custom Build Step/General, and change the Command Line property from:

ml64.exe /c /nologo /Fo"$(IntDir)\x64masm.obj" /Zi $(InputPath)

to:

ml64.exe /c /nologo /Fo"$(IntDir)\x64masm.obj" /Zi "$(InputPath)"

Remember to do it for each configuration (Release, Debug, ..)

The story behind that possible solution

A long time ago, while trying to compile Crypto++ in Microsoft Visual Studio 2005, I got a "MASM : fatal error A1000: cannot open file : C:\Projects\Blabla\My" compile error.
The file name actually gave me straight away the lead on what was going wrong, as the asm file was located in something like "C:\Projects\Blabla\My Project\myasm.asm", and it was self evident the issue was with the space on the path.
After spending an inordinate amount of time to find out to fix it, I did fix it only for the Release x64 configuration, so the issue came back to haunt me later on, that's it this morning, when I was wishing to compile again Crypto++ (5.5.2, I don't know if they fixed it on 5.6.0), this time in the Debug x64 configuration.
After spending another inordinate amount of time on the issue and finding again the way to fix it, I decided to put in on my blog, so next time I may have the chance to google my own solution.

Web Site Projects vs Web Application Projects

For web development, Visual Studio 2005 (VS 2005) supports two project options: Web Site Projects (WSPs) and Web Application Projects (WAPs). The earlier was built-in with the initial release of VS 2005, the latter were introduced later and are included on the VS 2005 SP1.

WSPs are leveraging the very same dynamic compilation system used by the ASP.NET 2.0 at runtime; when using this option, you don't need a project file (you just need to follow some easy and intuitive folder conventions).

WAPs are leveraging the MSBuild buld system, and when using them, all the code in a project is builded in a single assembly; when using this option, you do need a project file.

There are various pro and cons for each of those models, but if we focalize just on the speed of the build, the WAP option wins hand down every time you build from scratch or rebuild.

Why?

The main reason, as explained from Scott Guthrie, is that with the WAP, only the code-behind and the /app_code/* classes are built, while with the WSP the ASP.NET runtime spend its time analyzing and compiling each ASP.NET related code (content/controls/inline code).

Monorail case:

First and foremost, having a MSBuild capable project, as in the WAP option, helps when you have to integrate your projects with tools like CruiseControl.Net. Now, it is possible to do that also for the WSP option, but it is not as neat.

Second, using Monorail, the amount of ASP.NET pages in the web projects is probable negligible (usually just 1, quite trivial in every chances, which is left there to "fire" the build on certain circumstances), so there is not really any reason to use the deep verification features of the WSP model: there are not ASP.NET related file to build.

From experience and from investigation, I can add that on the web there are various tips and tricks to speed up the WSP, but the point is that as much as you can speed up a WSP build, the main target of this kind of exercise is to make it as fast as a WAP build.

Conclusion:

On non trivial web projects, and when you don't need deep verification of ASP.NET related files, use ever the WAP option.

p.s.: I shouldn't add this, but really, don't use the /app_code folder under almost any circumstance. Put your logic in different layers (VS class projects), and if really you need to use the /app_code folder, leave there only very stable classes.