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

·         Taming Massive Codebases using the Visual C++ IDE – discussing the architectural changes in the IDE Design Time experience (C++ editor, Intellisense and Browsing).

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 adding support 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).

MSBuild has seen great adoption both internally [http://blogs.msdn.com/vcblog/archive/2006/12/07/converting-to-msbuild.aspx] and externally and we (as in the C++ team) have received a lot of feedback [http://blogs.msdn.com/msbuild/archive/2007/11/30/response-to-the-feature-poll.aspx] to align to this move. We are in Visual Studio 2010 – and with this change we are also retiring VCBuild and providing a migration tool (VCUpgrade.exe) that will convert your .vcproj files to MSBuild.

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 editors: in case you’re not happy with the pre-canned editors we provide for specific property types (string, string list, directory list), you can write your own.

·         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.

Some notes:

·         The CTP release only supports converting native C++ projects.

·         You can report any issues you run into during conversion or build via http://connect.microsoft.com/VisualStudio or http://social.msdn.microsoft.com/Forums/en/vs2010ctpcpp/threads/

Thanks and we look forward to your feedback,

Marian