printf(“Hello MSBuild!n”);

Hello everyone. I’m Marian Luparu and I am a Program Manager in the Visual C++ IDE team. Last week I was in Barcelona attending TechEd EMEA 2008 where I had two talks delving into the areas where the VC++ IDE team is making major investments in the upcoming release:

·Building Visual C++ Applications – focusing on the Build System and the Project System changes and

In this post I want to go through some of the key points of the C++ Build System talk and touch on the changes we’re making in this space.

As the title suggests the biggest piece of news is that we’re addingsupport to MSBuild to build C++ projects. You may ask what’s different from previous versions when MSBuild was able to build a .vcproj file? Well, rather than enabling MSBuild to delegate the build of C++ projects to VCBuild as we did in previous releases, we actually went and defined the whole build process in MSBuild’s terms – that is by writing the targets and tasks specific to the C++ build. Why is this important?

First, with this move we’re consolidating MSBuild as the one common build system from Microsoft, a build system that you can use both in your build lab as well as on your developer machine. The big advantage of MSBuild is that it allows orchestration of complex builds in a completely transparent fashion – it gives the developer access to the internal details of the build process while keeping multiple levels of abstractions.

Another key strength of MSBuild is the ease of integration and ability to customize a build . This allows us to ship a build system that will be sufficient in 90% of the cases, while still permitting the other 10% of our customers to go in and make additions or changes to adapt to their own needs. Also, this enables us to provide a well integrated Project System on top of our MSBuild-based build system (more about that later on).

Getting the C++ Build System on MSBuild was an interesting process – the C++ team on one hand was looking at the MSBuild feature set and thinking of ways to best take advantage of its capabilities, the MSBuild team on the other hand was peeking at the VCBuild system and evaluating what new functionality MSBuild should add to ease the migration. The result was a successful mix of new features we added in both MSBuild and the C++ Build System.

Some of the new features in MSBuild that the C++ build system took immediate advantage in its implementation are:

·Item Definition Groups – a way to define metadata values that apply to all items in a certain ItemGroup (similar to how C++ project level settings are inherited by each file in VCBuild)

·Parallel builds – multiple projects build in parallel both in the IDE and on the command line

·Improved logging – a lot more useful information in the console and file logs

·Task factories – ability to create tasks on the fly based on a meta-language

·Import *.targets support – import all targets in a subfolder

·Remove and modify items during build – what the title says 🙂

·BeforeTargets/AfterTargets – a more flexible alternative to DependsOn to hook your target to a build

On the C++ side, there are also several benefits that you will be seeing immediately once you migrate to MSBuild:

·Better diagnostics – turning the verbosity of the logger in MSBuild gives you plenty of information about what happens during the build.

·Extensibility – a lot more extensibility points that we, 3rd parties and you will take advantage of.

·Native multi-targeting – the ability to use different toolsets (compiler and libraries) without requiring you to switch between different versions of the IDE.

·Enlistment-friendly – enabling large teams to create build environments that are a lot less dependent on the developer machine configuration and more friendly with the build lab and Source Control integrations.

Of course, this is not the full list and as features come online, both us and the MSBuild team [http://blogs.msdn.com/msbuild] will be blogging about them. I already started drafting posts about our Extensibility story and the Native Multi-targeting support so stay tuned 🙂

Probably the most striking difference from VCBuild is the uncoupling of the Build System from the Project System. The Visual C++ 2010 Project System will provide the same UI components you are accustomed to (Solution Explorer, Property Pages and its Property Editors, Property Manager, Configuration Manager, etc) but behind the scenes, the implementation will talk directly with the MSBuild Object Model in a way that is agnostic of the build system specific implementation. This translates into three different characteristics of the new project system:

·It understands the generic MSBuild process: by talking directly with the MSBuild Object Model, the Project System knows everything there is to know about how properties are defined in an MSBuild project, how they inherit and transform values, how targets are wired in the build, etc. You will see this information visible in the different UI components of the Project System regardless of how customized your project may be.

·It doesn’t get stuck on build customizations it knows nothing about: If you edit project files by hand or author build tools you will be happy to hear that once you add your customizations to a C++ project file, the Project System will continue to work without ever discarding or misinterpreting any of your changes.

·It allows build customizations to be surfaced to the user: If you want to go one step further with your build customizations and allow the developer to configure them, you certainly can do so in the same way we allow developers to configure the C++ compiler settings in the Property Pages.

One thing you will note in general about the Project System is that our current implementation takes advantage of the same extensibility mechanisms you would. As I mentioned earlier, adding a new tool to the build is as easy as writing an XML file in the same format as the CL.xml or Link.xml files we’re using to provide you the Property Pages for the C++ Compiler and the Linker. Some of the extensibility points of the Project System that will be available in Visual Studio 2010 are:

·Platform Extensibility

·Build process: define a new platform in the same way we define the Win32 or X64 platforms.

·Debuggers: provide your own debugger for an existing platform or one that you developed.

·Property Pages Extensibility

·Tools: once you added a tool to the build process, allow it to interface with the user by exposing which properties control its behavior.

·Type providers: some of the properties you expose may have possible values that depend on some specific contexts – you can write a component that will provide those values dynamically.

·Custom UI: for even more customization, if you don’t want to use a property grid for your property page, you can write your own custom UI as a component that will communicate with the Project system to read and write properties.

We will have more documentation and samples for these extensibility points in the near future. One blog that you should add to your blogroll is the VSProject Team blog [http://blogs.msdn.com/vsproject] where Brian Tyler – the team’s Tech Lead – assured me he’ll soon post some really cool articles about the new Project System’s capabilities.

To wrap this blog post, I have a call-to-action for you:

We have released the CTP that contains some early bits of our Build System and Project System – the CTP is available here: [http://go.microsoft.com/fwlink/?LinkId=129231]. The new Project System is not turned on by default, so you will need to run this script: “c:Program FilesMicrosoft Visual Studio 10.0Common7IDENewVcProjectSystem.cmd” before you try anything. After you run this script, you are all set for trying out VCUpgrade and MSBuild.

Action item: Copy your projects to the Virtual PC machine running the CTP, go through the process of converting your projects and then building them using MSBuild and let us know if you run into any issues as soon as you can. We are still in the development phase and we definitely want to address any issues you run into before shipping the final version.

Any plans to improve the Project Settings GUI? This is still awful in 2008 in that it is not possible to see the settings for multiple platforms (x86 & x64) and builds (debug & release) at once, and requires a lot of clicking when switching between them.

I lost count of the number of times I have found inconsistent settings between builds as a result of this GUI and whenever I have to make changes or create a new project I end up swearing at it.

Improving that would make the new VC worth buying even if there were no other changes!

…adding to what I just posted: You could improve the Project Settings UI if it showed a grid with the settings for each build type.

At the moment each page has a two column grid with setting name and setting value.

That could be expanded to show a column for each build type instead of a single value column.

It wouldn’t matter if a lot of build combinations caused lots of columns and scrolling because that would still be a million times better than the current setup.

Right now you have to click on two drop-downs, and then click "Yes" to apply your changes in a dialog that appears in a different place, to change between build types. You have to remember, or put in the clipboard, each setting and then change types to see if they are consistent based on what you can remember. It’s horrible. If we could see all the configurations side-by-side, even if scrolling was required, then that would be so much better.

Locking the name column so that it doesn’t scroll out of view might help.

Making the project settings dialog resizable would also help, of course.

E.g. in a case where you have a ProjectA.vcproj, ProjectB.vcproj etc. using multiple common property sheets tailored to your specific needs such as Libraries_x86-32_Debug.vsprops and Libraries_x86-64_Release.vsprops etc.

The property page UI is pretty much the same in VS2010 and VS2008. I’ll agree that there is a lot we can do to improve the experience – both for basic and advanced scenarios (which is always the rub). However, I’m a little confused by your comment that you can’t multi-select. If you go into the Configuration or Platform dropdowns, you’ll see All Configurations/All Platforms (unless you have 3 or more, in which case you also get Multiple – where you can pick).

The UI then only shows the values that are the same for all the selected configurations.

@Niels

Yes, the project upgrade wizard and the command line upgrade tool both handle property sheets. The Property Sheet concept is a very central idea in the concept of the project system.

@Brian: Regards Leo Davidson’s comment, I would like to chime in with a +1.

At the VERY least, even if you’re not going to change the interface of the Project Settings, PLEASE make the dialog resizeable!

And yes you can view the common properties of multiple builds simultaneously, but I believe what Leo is asking (and what I would like to see) is a way to see all properties (common and otherwise) simultaneously in a grid-format.

@Jalf: So what about building translation units within a project in parallel?

cl.exe /MP will still be supported – we are finally adding it as a property in the Property Pages rather than asking you to pass it as an Additional Options. Also, the number of cores you want to spend on /MP will be configurable from Tools/Options. Depending on your projects organization, you will continue to have the choice to mix and match both techniques of building in parallel (file-level and project-level).

@Brain: As Jon suggests, seeing the common settings for different projects isn’t enough.

Consider a C++ Debug and Release project. You want to add a pre-processor definition, or you want to add an additional link library. (Or you just want to compare the two to see if they are consistent).

Those two things will almost always be different between a Debug and Release project.

With the pre-proc definitions you’ll always have DEBUG defined for one and NDEBUG for the other.

With the link libraries you’ll often have some debug-only and release-only link libraries (e.g. for components you have the source code to which provide you with debug versions) while other libraries will be release-only (3rd party libs).

In both cases, and several others, the result is that you just get a blank field (or a message saying the settings differ by project; I forget) if you select both Debug and Release configs.

As well as not being able to see and compare the settings side-by-side, there is no way to edit the settings in one place.

To compare the two configs you have to keep flicking between them which takes far too many mouse clicks and requires you to keep long, cryptic lists of symbols, library names, etc. in your head.

I have lost count of the number of times I’ve discovered inconsistent settings between configs as a result of this.

It’s like a memory game rather than a GUI designed for speed and accuracy.

This is made even worse by having x64 and x86 projects since you now have four different project types, each with their own differences from the others (yet with commonalities as well). The GUI is so bad at this that I sometimes end up editing the project settings in a text editor instead.

I am just thankful that x64 became important around the time that ANSI builds became unimportant, else there would be eight configs to worry about instead of four!

If the settings were shown in a grid then that would solve it.

Or at least make it quicker to switch between configs after making changes to the current one. i.e. It should be one click, on a list of configs that is always on screen, no drop-downs and no confirmation dialogs.

Or make if so that you can open several project settings dialogs and view & edit different configs side-by-side that way.

Lots of ways to solve the problem which would be a million times better than what we’ve had to put up with for some many years in the current design.

(And, as Jon also said, making the dialog resizable is badly needed as well. It is so frustrating that it doesn’t size when it is so normal to be dealing with long values in some of the fields.)

I should stress that I love Visual Studio. It’s just this particular bit of if that I hate and find inexplicably neglected in terms of GUI design.

Since your primary interest is the MSBUILD process, I would request another feature (that is, in case it is not present):

Let us troublelessly build Device Driver projects.

We have the BUILD.EXE from DDK, with its own bunch of rules, macros, makefiles and various build ‘environments’ making it a herculian feat to batch-build all targets and platforms from the same shell window. Most people end up using OSR’s DDKBUILD.BAT to get through the build process without brain damage. Please save the day!

Then let’s get back to project settings…

PPPppplease… Fix the project settings dialogs. They are a source of constant pain and frustration. I realize that it is a very difficult UI problem because there are 3-degrees of freedom (build type, platform, setting), but I assume you have access to some internal UI experts to give you better advice. Have someone ‘sane’ propose some UI designs, someone that is not a developer 😉 someone from the Office team for example.

I have the following feature suggestions with regards to settings:

(1) Let us enter comments to explain project settings.

(2) Let us verify the value of settings through preprocessor definitions/macros.

This way I can have a dummy source file that simply checks for the correct values in some crucial options and thus make sure the build is sane. Moreover I could have various such files that get added on every project (depending on the type of project) to make sure for example that all my DLLs and EXEs for example use static CRT linking.

People go to great extents to solve some weird build issue through project settings, and one year later noone remembers what some obscure setting was needed for (e.g. we have a DLL with optimizations disabled in release build).

I filed the comments request in MS connect and after several weeks of serious thinking the item was closed with the response "You can enter XML comments in the VCPROJ file".

Man! What a breakthrough! I can enter a comment where noone can see it! And what was I supposed to be doing afterwards? Every time I want to change a setting open up the VCPROJ in a text editor to see if I have entered any comments???

"The UI then only shows the values that are the same for all the selected configurations."

Actually, it displays the values that are different the same way it does the ones are are all empty: as an empty string. You can’t tell the difference between multiple non-default values, multiple default values, all empty by default, and all overridden empty.

I’ll let the owner of the property pages dialogs speak to the feedback about them directly.

However, as the MSBuild owner, I can say that moving to MSBuild means that the file format is fully documented and supported, that Visual Studio is expected to handle whatever structure you create and whatever content you put in there, and that there will be a comprehensive, rich new object model over it.

(This will replace the object model MSBuild currently has, which has many deficiencies.)

So regardless of what the dialog supports in VS10, there will be plenty of opportunities to write powerful custom tools over the project files and property sheets to display in any format and allow any kind of editing: perhaps 3rd parties will create some.

> I lost count of the number of times I have found inconsistent settings between builds as a result of this GUI and whenever I have to make changes or create a new project I end up swearing at it.

I have found that Property Sheets (.vsprops files) are a great help when the number of projects, platforms and configurations increase. Instead of specifying lots of settings on the project level, I try to refactor the settings into a few .vsprops files (e.g. Debug.vsprops, Release.vsprops, X86.vsprops, X64.vsprops) and leave the .vcproj files to all defaults, inheriting everything from the property sheets. That’s it, not a single entry in bold in the project properties (or at least very few). It takes some time initially to find the optimal structure, but once you have organized all settings into a few .vsprops files, you are less likely to end up with the inconsistencies that you describe.

I hope that VS2010 keeps improving on this feature, because I find it invaluable for big multi-project solutions. For example, source control integration is not great for .vsprops files in VS2008.

Since we found this feature in VS2005, project-setttings-hell has been a bad memory from the old days. Comes in handy if you have a multi-million C++ code base with hundreds of .vcproj files. So in our opinion, MSBuild should support the .vsprops.