Visual Studio Build Process, VC++ Libraries and Check-in Process

Hi again. My name is Ale Contenti and I’m the dev lead of the VC++ Libraries team. You might have see me previously in my channel9 interviews. I’m now in Italy for a short vacation and I’ll be in Barcelona for TechEd starting from Nov 5. I’m really excited to go there and mingle with a lot of VC++ and Visual Studio users! After TechEd, Steve Teixeira (Group Program Manager for Visual C++) and I will be in Munich, Germany to meet with customers.

Today I want to talk about how we check-in changes to the VC++ Libraries, and how the libraries are used by the rest of VC++ and Visual Studio.

You maybe know that the entire Visual Studio is built in our lab every night starting at 9pm (Fri & Sat night excluded, usually). The VC++ Libraries are among the first things that are built. Why? Because these libraries are immediately used by the rest of the Visual Studio components!

One of the first libraries built is the C-RunTime (or CRT). The CRT consists of three main parts:

·         The header files (like stdio.h)

·         The import libraries (like msvcrt.lib)

·         The DLLs (like msvcr90.dll)

We build these three parts and publish them to a binaries output folder, more or less like it happens for a normal VC++ project.

Additionally, the header files and the import libraries are “published” to another folder. The rest of Visual Studio components (e.g. the VC++ compiler cl.exe or the C# compiler csc.exe) are built using these newly published include files and import libraries.

This has a few interesting implications:

·         The entire Visual Studio is always built with the latest VC++ Libraries (CRT, STL, ATL and MFC)

·         The entire Visual Studio will load the latest VC++ DLLs at runtime

·         If there is a regression in the VC++ Libraries (for example an issue in a widely used functionality), the effects will be seen in the rest of Visual Studio as well

·         Each change to the VC++ Libraries headers and libs need to be carefully tested to make sure the build is not broken and the Visual Studio components work correctly

To make sure each VC++ Library check-in will not break the rest of Visual Studio we rely on:

·         An extensive set of regression tests

·         An automatic check-in system which ensures there are no build breaks and no test failures

The regression tests are usually updated with the unit tests which accompany the code changes.

The automatic check-in system uses more than 20 machines to build different parts of Visual Studio and then run a lot of tests targeting the newly built binaries. When everything looks ok (build and tests) the automatic system (we call it “the gauntlet” J) will take care of checking-in the changes and send mail with the check-in details.

I hope this was interesting and insightful. Let me know if you have any question/comment.

Ale Contenti

VC++ Libraries Dev Lead