locked
Visual C++ Project System

    General discussion

  • Hi, my name is Chuck England and I a Program Manager for Visual Studio’s Project & Build team here at Microsoft. This includes the Project System inside Visual Studio, MSBuild (shipped as part of the framework), and SCCI integration in Visual Studio.

     

    The Project System is the integral part of Visual Studio that manages your project(s) and solutions. You probably recognize it most as the system you interact with to setup, add files to, and manage your projects and solutions.

     

    MSBuild is a complete build environment. Through its XML file format, you define the build as a set of properties and items that build targets. These targets may be built from our predefined set of tasks, or from those you define yourself.

    With this new release of Visual Studio, we have made significant additions and improvements to the Project System and MSBuild.

    • Walkthrough: How to Create a Custom Platform
      • In this walkthrough, "How to Create a Custom Platform", we are highlighting building your own Cusom Platform. Visual Studio 2010 provides a new project system for Visual C++ projects that is based on MSBuild. The new project system allows you to create custom platforms that appear in the Solution Platforms dropdown box. Custom platforms let you create a project that has a custom build process. This build process can interact with a collection of specialized tools tailored to the platform.

    • Walkthrough: How to Use the C++ MSBuild Project System
      • In this walkthrough, "How to Use the C++ MSBuild Project System" we are highlighting our new feature C++ Project System. The new Project System is now based on the MSBuild file format and includes many great new features.

     

    • Walkthrough: How to Create Custom Property Pages
      • In this walkthrough, "How to Create Custom Property Pages", we are highlighting our new feature "Custom Property Pages" that allow you to create your own property pages that display in the Visual Studio UI. You can then edit your new properties, and the values are saved in your project file in the new C++ project system. You can then use these properties to define custom build rules or create conditional builds.

     

  • We are really looking forward to hear your feedback. Please let us know what you think about the our scenarios in these walkthroughs, as well as other feedback you may have. We are interested in hearing about your overall experience and your thoughts about these new features into Visual Studio!

    If you have not downloaded or would like more information about the CTP, please visit http://go.microsoft.com/fwlink/?LinkId=129231.  

    Thanks,

    Chuck England
    Visual Studio Platform
    Program Manager – Project and Build

Monday, October 27, 2008 6:05 PM
Moderator

All replies

  • I haven't fully exercised the new project system yet, and I understand it's still a bit unfinished and raw, but I do have a couple of comments so far.

    First, I'd like to see the output cleaned up a bit. Having experienced MSBuild a bit due to C#, I find that it tends to spew a bit more by default than I think a build system should, and it seems that the new project system does the same. The command line shouldn't be displayed by default, because you generally only need to see that for diagnostic purposes, and because it makes it more annoying to scan automated build logs -- ask anyone who's tried doing so and gotten fouled up by the /warnaserror switch passed to csc.exe. I can check the project settings to see the cl.exe command line parameters. Also, I'd prefer that output be omitted for projects that are (a) just doing dependency checks, and (b) not selected to build in the current solution configuration.

    Second, I noticed that the property for selecting the compiler just says "v100" and has you type in an identifier manually. I'd suggest that this have a drop-down history if it doesn't already, and be pre-populated with the default tags -- I'd rather see "v100 (Visual Studio 2010)" and "v90 (Visual Studio 2008)" appear as choices.

    Sunday, November 16, 2008 8:36 PM
  • Avery,

    Thank you for your feedback.

    As a general rule for building files, it is up to the tasks within MSBuild to determine what they output, and how they output it. There are varying levels of output that you can use when you write to the logger (Error, Warning, Message; BuildEventImportance). The task writer determines what they think is appropriate, and then the verbosity used during the build determines how much gets written out.

    You can set the level of verbosity you want to see on the command line when you run MSBuild. From inside of Visual Studio, under Tool | Options | Project and Solutions | Build and Run, there is an option at the bottom of that option page name "MSBuild project build output verbosity" which can be set to various levels, which reflect the command line verbosity.

    So, while you can adjust the verbosity you get on the command line and in the IDE, what you get depends on how users (those that write tasks) log within their code. I think that the built-in tasks all use reasonable logging.

    For the property setting of the compiler, this is part of our new extensibility model. That is, this property is filled in dynamically based on the toolsets that are found on the machine. The determination of whether a toolset exists is based on the folder names found in a particular directory. Platforms go in the "%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\Platforms" folder. Toolsets for a given platform go in that folder under the name of the platform in a folder named after the platform. So, for example, for the Win32 platform, you might have the Orcas (v90) toolset, and the Visual Studio 2010 (v100) toolset. In this case you would see the following hierarchy:
       %ProgramFiles%
            MSBuild
                Microsoft.Cpp
                    v4.0
                        Platforms
                            Win32
                                PlatformToolsets
                                    v90
                                    v100

    The property is data driven, and is filled with the names of the folders in the PlatformToolsets folder for the platform.

    Chuck England
    Visual Studio Platform
    Program Manager - Project and Build
    Monday, November 17, 2008 11:07 PM
    Moderator
  • So, while you can adjust the verbosity you get on the command line and in the IDE, what you get depends on how users (those that write tasks) log within their code. I think that the built-in tasks all use reasonable logging.

    I'm talking about the default settings that the VS2010 CTP installs with and the first time experience. As I see it, the new logging is significantly more verbose by default than the existing C++ project system in VS2008. What is the justification for this? The command line, at least, has always been available in the project settings dialog.

    Keep in mind, most of the time users are going to be building and debugging their code, and hopefully not spending all of their time debugging the build system itself. Their interests are what files are being compiled and what warnings and errors are coming from each file. I would think that the default settings should be optimized for the most common workflow. The build system spewing nearly identical command lines over and over into the log is not ordinarily useful output.

    The property is data driven, and is filled with the names of the folders in the PlatformToolsets folder for the platform.

    OK, but I see two problems with this. One is that, as I said, it provides a poor experience for the most common use of this field, which is to select between different toolsets that are already installed. The names "v90" and "v100" are not very intuitive for those not familiar with the internal Visual Studio versions, and to have to type them in seems unnecessarily manual, thus why I suggested descriptive names and UI history. Second, how would you handle localization? I presume the intent is to keep the platform tag in the MSBuild file locale invariant, because having it vary based on the installed Visual Studio language would be a project management nightmare, and having everyone use undescriptive generic tags would seem like using DOS 8.3 filenames for your platforms.

    Sunday, November 23, 2008 9:24 AM
  • Avery,

    The default verbosity in the IDE is set to "Normal". This is the same as for Visual Studio 2008. Visual Studio 2010 does produce a little more whitespace, which seems to make the build log more readable, but the other than that, the messages are very close to the same. However, please note that these are completely two different systems. The project system, and the use of MSBuild for C++ projects is brand new. So, you should expect to see some varience.

    The amount of detail that you get back from the IDE can be turned down. If you are building you application and simply want to know success or failure of the build, you can change the amount of detail by selecting "Minimal", or "Quiet" for the MSBuild project build output verbosity. To set this, go to the "Tools" menu and select "Options". In the list on the left side, expand the "Projects and Solutions" item, and click on "Build and Run". The second to last option from the bottom is "MSBuild project build output verbosity". In "Minimal" the output produced will be similar to:

       1>------ Rebuild All started: Project: TestApp, Configuration: Debug Win32 ------
       ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

    In "Quiet" you would see something like:

       ========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

    If you are compiling and you have errors, you can use the Error List window to go straight to errors. Make sure you have selected what you want to see (ie Errors, Warnings, Messages) by clicking on them in the "Error List" window. For example, when you have "Errors" selected in the "Error List" and you receive a compile error, the "Error List" window is brought to top and you can double-click on it go straight to the code for the error.

    Build errors can be a little bit harder to find, and there you may need a detailed log to help you figure out what is going on. If you don't need this, just disable it as shown above by setting the appropriate level of verbosity. But, as you mentioned, this is really for when you are looking for a different type of error than the scenario you are describing. For compiling and lint'ing out syntax and semantic errors, use the "Error List" window.

    The name of the platform can be anything you want. On an NTFS, you can use fully localized strings to name the plaform if you like.

    Chuck England
    Visual Studio Platform
    Program Manager - Project and Build
    Sunday, December 07, 2008 1:13 AM
    Moderator
  • Visual Studio 2010 does produce a little more whitespace, which seems to make the build log more readable, but the other than that, the messages are very close to the same.

    You might want to take a look at your own team's response to bug 101154 then, which reads:

    "thanks for your feedback. this is actually intentional. we have done this since 6.0 at least; the idea is that we always try to conserve space in the output window. we have consistently received tons of negative user feedback any time we take extra space in said window."

    I take it this is now being ignored?

    However, please note that these are completely two different systems. The project system, and the use of MSBuild for C++ projects is brand new. So, you should expect to see some varience.
    Yes, I understand why the system acts as it does, based on your implementation. I have done C# programming and am familiar with the MSBuild integration in the IDE. You are switching C++ projects to MSBuild and now your default level of logging has changed as a result. What I'm saying is that I don't believe this justifies the current design and that the design should be changed as it will negatively impact people who are used to the existing level of output from C++ builds.

    Some of us don't use the Error List, and for those of us who just invoke devenv.exe to build an existing solution and receive the output log, we cannot use the Error List to filter. The Error List is also a pain to use for C++ because it does not convey multi-line error messages well and it does not work if custom build tools are involved which do not conform to the IDE's undocumented rules for identifying errors, which we often do. Dealing with IDE settings for automated builds is also a hassle that I'd personally rather avoid, after having to resort to patching the registry before each build in order to manipulate the multi-CPU project build setting.

    I'll happily accept that others may have a different opinion, of course, but so far, I don't see any other customers replying to the contrary yet.

    Is this not a valid place for suggesting changes? Should I submit a bug instead?

    The name of the platform can be anything you want. On an NTFS, you can use fully localized strings to name the plaform if you like.

    Are you actually planning on supporting the localization scenario? If so, this is an astoundingly bad idea. Let's say I have a toolkit which uses a localized name by installing to the platform directory with a localized name as you suggest. That means that if I create a project in a Spanish locale, I will have to encode the Spanish name into my project file, and therefore it will not build on a system that has the toolkit installed in French locale.
    Sunday, December 07, 2008 5:15 AM
  • Avery - first let me apologize for letting this sit for a week. We've had a major milestone that we just finished, so it's been a little crazy here. But we're back now! As far as the platform toolset version question is concerned...

    I think there was a little miscommunication regarding the localization issue. No - we don't expect - nor want - people to start doing localized platform toolset names for the exact reason you specified. The basis of the design is to support xcopy-style installation/uninstall of both platforms and platform toolsets.

    So for both the available platforms and platform toolsets, we simply look at the set of directories that are there and populate the drop downs accordingly. This does mean that we don't provide any more human-readable values - we only provide what we find.

    Now - that isn't the end goal. If you look at how we use the XAML files for defining property pages and content type definitions, they are all localizable XML and we seperate display name from ID name. We have talked about having description files for platforms and platform toolsets so that the user has a much richer experience. Unfortunately, that was something that didn't make the bar for this release - but I fully expect to see it in the future, because as you point out, it is important for users not to have to understand the underlying architecture to use the product.

    As to the verbosity question - let us get back to you on that one. There are actually several people running around with thoughts and comments on that here in Redmond and I'd like to be able to respond with the summary of the internal discussion. Personally, I think it's going to be like the UI issue - everyone has an opinion and no one is wrong - because it is opinion based. However, quoting MS responses back to us is an effective way of forcing the issue :)

    Tuesday, December 16, 2008 2:51 AM
  • Chuck,
         I am a bit confused; are these walkthroughs available anywhere yet? I am particularly interested in the "How to Create a Custom Platform" walkthrough. This is a great and much needed feature.

    Thanks,
    Jonathan
    Wednesday, December 17, 2008 9:50 PM