printf(“Hello MSBuild!\n”);

printf(“Hello MSBuild!\n”);

  • Comments 26

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 Files\Microsoft Visual Studio 10.0\Common7\IDE\NewVcProjectSystem.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

 

  • "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.

    Bogus.  Extremely bogus.

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

    Dan

  • @Leo:

    > 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 it supports native multi-targeting can you add support for the Visual C++ 1.52 compiler so we can compile our 16-bit applications without having to be on a Windows NT machine?

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

    I'm not noticing a whole lot of feedback from this person as yet :)

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

  • I'm wondering why the filters are in a separate *.vcxproj.filters file.

    Wouldn't it be easier to keep this information in the *.vcxproj itself under the <ProjectExtension> node?

  • Hello again! My name is Li Shao. I am a Software Design Engineer in Test in the Visual C++ group. As

  • Hello, my name is Felix Huang and I am a developer on the Visual C++ team. Over the last year, I worked

  • As part of my role in working with partners in the Visual Studio Industry Partner (VSIP) Program I have

  • Bogdan Mihalcea is a developer on the VC++ build and project system team. He and team have been very

Page 2 of 2 (26 items) 12