Just Completed a Conversion From an Imake-based Build System Over to MSBuild

Some stats up front, the old system was comprised of 37 Imakefiles with 2333 lines altogether. The msbuild system has roughly the same number of MSBuild project files (.csproj and a single .targets) with a total of 2022 lines. The cool thing is that even though none of these are C# projects I can use a .csproj file and trick VS 2005 into building the MSBuild projects for me. WRT build times, MSBuild appears to be a bit slower but then again it is still in beta. The build system builds: yacc files, objective C, C, C++ and managed C++ source files.

Overall the port has gone really well and I have to say that custom item metadata has come in real handy (great idea). The target dependency analysis works really well, the output from MSBuild is pretty good for a V1 and creating custom tasks is a breeze (I did two for this port - SetEnvVar and SmtpMail).

Areas that could use some improvement IMO. This is just a docs issue but I found myself fumbling around with whether or not a new property or property override should come before or after the imported targets file. I still struggle a bit with when to use a transform vs item metadata directly. I wish there was a "/preview" option like the /N command on nmake that just shows what would happen without actually executing anything. I want to see an output format that sheds more light on the dependency analysis phase (primarily for debugging dependencies in targets). A feature to "defeat" dependency analysis (/ignoreDependency) would occassionally be handy, like the /A nmake switch to just have MSBuild build everything for a target. Finally, with how I am using .csproj files in VS 2005, I find that the "Cancel Build" command is not very responsive. In fact, it only cancels after it finishes building the current .csproj file. From the command line, I can Ctrl+C kill MSBuild right away.

All in all, I'm really impressed with V1 of MSBuild and look forward to seeing some enhancements made for Orcas (like direct support in VS for MSBuild project types). :-)

Answer this question

Just Completed a Conversion From an Imake-based Build System Over to MSBuild

moodyj
I see this when I have build errors and then hit Ctrl+C. After that, all text in the console session is red. I really like the color differentiation on the console. Perhaps in the next version this can be made configurable or perhaps take the current fg/bg colors into account.
s0ulburn24
The cancel build suggestion is logged:

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=c05a918c-78b2-4530-9e60-36062e61f7bd

Regarding performance, I think it's off by only ~10%. That's acceptable IMO. WRT to sticky console colors, yeah I could have been hitting Ctrl+C at an inopportune time. I'll keep an eye out for that and see if that is indeed the case.
HForcht
I'm in a similar sitaution, having moved from nmake to msbuild.

I have colours staying around even when I haven't hit ^C. Is there anyway to turn the colours off altogeather Or a default consoleLogger which doesn't have colors.

Also the colors assume that you run your console with a black background, and I don't (it's a bit more like the background colour of this edit pad), so I end up with text like this, which isn't very visible.

I'm using the console logger because sometimes the build will be run interactively and users will want to abort the build early if they hav an issue. If the build is run in the background I pipe the output to a file. So I have a build script wrapped in an another command to capture the output, trying to pass this context down thru multiple levels to switch between a fileLogger or consoleLogegr would be a trifle tricky.
Bone
I've discoverd that vcbuild has a /nocolor option, and as all I'm doing is building individual projects this suits my purpose ....

I suspect the colors hanging around are related to the fact that I pipe the output to other processes. Maybe there should be a plain text logger

The multiproc stuff would be much better if it compiled files within a project in parallel. It's frustrating to sit there and wait 2 hours for a project to build using only 25% of the CPU, hopefully IncrediBuild will have a beta for VC8.0 soon :-). It would also be good if multiproc understood assembly import for managed C++. You can start compiling files in the project which aren't dependent upon assemblies, and just queue those that are until the assembly is linked.

Dan
irtaza

You should be able to derive from ConsoleLogger to implement a different color scheme. Probably you would override Initialize to call your own event handlers, which would likely set appropriate colors and call the base handlers to generate the text. You might have to override the WriteHandler, like the FileLogger does.

I haven't tried this but in a quick look you should probably be able to do it.

We figured we wouldn't devote huge resources to things like this because it's an extensibility point -- better to spend time on things like multiproc.

Dan
James Wilkinson
The best place for feedback on vcbuild.exe is probably the C++ forum http://forums.microsoft.com/msdn/ShowForum.aspx ForumID=29
P Glenn
Thanks for the feedback Keith (this and all your previous postings).

-- /preview and /ignoreDependency: Good suggestions. We've had other requests for both of these and they're on our list to consider for next version. Whidbey's in bug-fix only mode right now.

-- Cancel Build. You're correct that this has limitations. It's that way for architectural reasons.. but perhaps we can improve it in future. Could you open a betaplace suggestion for this that we can postpone and consider for Orcas

-- Console colors sticking around. I think this only happens if you hit Ctrl-C when it's outputting a line in color Perhaps we should unregister loggers in a ConsoleCancelEventHandler so ConsoleLogger could reset colors. I've put this possibility on the Orcas list.

-- Performance. We have made some improvements since Beta, but if you have more detail about what specifically is slower it might help us identify a bug.

If you have other suggestions, Betaplace (or whatever its called) is a good place to log them, because we can't lose track of them there.

Dan
Larry Cleeton
Hi,

I don't know how the colors are getting changed short of a rude-abort: if you can devise good repro steps, please log an issue with us so we can look into it.

There is no built-in switch to disable color. It might just be possible to derive from the ConsoleLogger class to disable it. Or, derive from the built-in FileLogger class to write to the console without color. That's just speculation as I can't check either at this moment but I'll look into it. Of course, you can write your own logger, although that's some work, or perhaps borrow one that someone else has written.

Note that you can attach multiple loggers: maybe this would help with the other scenario you describe - or perhaps you're already aware of this and it wouldn't.

Dan (msbuild@microsoft.com)
hero281
One other thing. I did a lot of testing from the console and in general I love the fact that you are using console colors to differentiate output. However, occassionally I run into errors that cause the output to turn red - permanently. I have to close the CMD console and start a new one. I would have thought that maybe CLS would clear up the problem but it doesn't.
Just Completed a Conversion From an Imake-based Build System Over to MSBuild

Answer this question