• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)


Date: Wednesday, 09 Jun 2004 06:18

You may notice that when you build a solution containing many projects in Visual Studio 2005 on a multi-processor machine, some projects build in parallel (by default, the number of projects to build concurrently is the number of processors reported by the operating system). Projects that do not depend on one another, either directly or indirectly, can build in parallel. Developers on the Visual C++ IDE team take advantage of this feature every day (our solution builds much faster in parallel because we have some central projects that every project depends on, but the majority of the projects can build in parallel after the basis projects are built). When you start a build, the default output window pane used for the build output (called “Build”) will show the interleaved (by line) output of each concurrently built project. This shows what is going on “live”. Here is what it looks like when building two simple projects that do not depend on one another (I’m running this on a dual processor machine):

The 1> and 2> shown above are the “build number” prefixes. As each project builds, this number will increment. It is unrelated to the number of processors and it will go as high as N where N is the number of loaded projects in the solution (it will be less than N if one or more projects are up-to-date or skipped). Note that the build summary line contains the number of up-to-date projects, so no longer will you get dozens of lines in the output window declaring each project up-to-date (this also is much faster as the solution now correctly checks which projects are up-to-date prior to invoking a build). To make it easier to understand the build output, there will be an additional pane called the “Build Order” pane. This pane shows the output as if the projects built one after the other. Here is what this looks like:

So in Visual Studio 2005, solutions that have a low number of inter-project dependencies will see a reduction in build times on multi-processor machines. I’m trying to cover each of the features I outlined in my “What’s New in Whidbey for VC++ IDE” post in some detail. I think I will talk about PGO (profile guide optimization) support in the IDE for my next post.

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VC++ Project System"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Jun 2004 22:57

As I touched upon in my “What’s New in Whidbey for VC++ IDE” post, you will find a new tool window in Visual Studio 2005 called the “Property Manager”. This tool window will be available from the View.PropertyManager (View | Property Manager) command. If you’re using the Visual C++ user profile, it should be visible near where Solution Explorer is docked. This tool window is a graphical representation of associated property sheets in use by the projects in your solution. A property sheet is a XML file that stores properties that can be applied to any configuration in any VC++ project. Property sheets can also inherit from one another, so you can store properties that affect all configurations in one location and properties that affect a subset of configurations in another. The XML stored in the property sheet file is basically the same as the XML stored for a particular configuration in a project file. While a configuration has a collection of tools that it uses to build (which can differ based on the type of the configuration: DLL, static library, executable, etc), a property sheet has a tool collection that contains all possible tools. So a property sheet can be used to store properties for both the librarian and the linker and can be inherited from both a static library configuration and a DLL configuration (the former contains the librarian tool in the tools collection while the later has the linker tool in the tools collection).

In addition to storing tool properties, property sheets can contain a collection of user macros. User macros allow you to use the $() syntax in your property values to evaluate to a user defined value without resorting to using environment variables. User macros can also be inherited from property sheet to property sheet, so, for example, you can define a variable that stores a list of paths in one property sheet and the inheriting property sheet can append a value onto that user macro’s value. User macros can also be set in the build environment without having to be set in the environment of Visual Studio itself (useful if you have build tools that need environment variables set up). Unfortunately, you will still need to resort to using environment variables if you want user specific macros (something that will hopefully be addressed in the future).

So that covers the gist of property sheets. Let’s now take a look at what the Property Manager might look like:

Property Manager

We see that there are two VC++ projects (the Property Manager is specific to VC++) in the solution: SampleWin32Project and SampleWinformProject. The former is simply a Win32 GUI application and the later is a .NET WinForms application project. We see that each project contains the standard “Debug” and “Release” configurations. If you had additional configurations they would appear as folders under the project nodes. This is where the view can get slightly confusing (we toyed with several different representations early on in Whidbey). Where as the configuration nodes are “contained” by their parent project nodes, the configuration nodes inherit from their child nodes (likewise for each property sheet node). Projects have no relation, property-wise, to configurations in our build system, so the project nodes simply act as a method of grouping configurations together. Getting past this, we see that each “Debug” configuration inherits from a user property sheet called “Debug Properties” and each “Release” configuration inherits from a user property sheet called “Release Properties”. Both “Debug Properties” and “Release Properties” inherit from a user property sheet called “Base Properties”. The rest of the nodes (those without the little user glyph next to them) I will discuss later. So what does this all mean? If you change the properties in the “Base Properties” property sheet, the new default seen for all configurations (assuming that the property isn’t being overridden from a property sheet or configuration that inherits from it) will be that value. Likewise, if a property is changed in the “Debug Properties” property sheet, all “Debug” configurations will see the change.

Let us take a look at user macro support by imagining we double clicked on the “Base Properties” node (any of them will do, they all reference the same property sheet). The familiar project properties dialog will come up, but there will be two key differences: property sheets contain a property page called “User Macros” and property sheets contain the property pages from all tools. Here is what the “User Macros” page might look like:

User Macros

We see that there are three user macros being defined: $(Foo), $(Bar), and $(Jam). These define three paths ($(Jam) will evaluate to whatever $(IntDir) evaluates to). If we clicked on the C/C++ “General” property page, we could add these three macros to the “Additional Include Directories” property, like this:

Now the default for every configuration in these two projects for the “Additional Include Directories” property will be “$(Foo);$(Bar);$(Jam)” which should evaluate to (assuming no other inheritance level is overriding the property or the macros): “C:\SomePath;C:\SomeOtherPath;Debug” or “C:\SomePath;C:\SomeOtherPath;Release”. This can be further seen if we invoke the editor on the “Additional Include Directories” property for the C/C++ compiler on the “Debug Properties” or “Release Properties” user property sheet:

Notice that the inherited value is indeed “$(Foo);$(Bar);$(Jam)“. You can uncheck the “Inherit from parent or project defaults” checkbox to insert a $(NoInherit) macro into the value at the current level. This prevents the parent value from being automatically concatenated onto the end of the current value (likewise, you can use the $(Inherit) macro to insert the parent value where specified and you can use the $(StopEvaluating) macro, which is new to Whidbey, to completely stop property evaluation when encountered).

Let us get back to those other property sheets (“Core Windows Libraries”, “Multi-byte Character Support”, etc) being shown in the Property Manager. These property sheets are called “intrinsic” property sheets and differ from the user property sheets by virtue of being built into the project system. When you modify properties such as “Configuration Type” and “Use of MFC” on the “General” page of a configuration, the project system automatically inherits the configuration from the related property sheet. In the upcoming beta, these files will be editable like the user property sheets; although, this will change so that they become read-only before 2005 ships (the files themselves exist in Visual Studio’s installation hive and should not be modified). If you’ve ever wondered where some of the project defaults come from (like the default libraries to link defined in “Core Windows Libraries”), some of these defaults are actually found in the intrinsic property sheets.

If you’re going to try out the Property Manager in the upcoming beta, I want you to be aware of some of the known issues before you do. The first is that if you change a user macro’s value, the IDE needs to be restarted before the change takes full effect (the old value can remained cached). The second is that if you create a new property sheet, modify it, and remove it from the property manager, it will not prompt you to save the property sheet. Both issues have been addressed for future releases of the product.

I welcome any feedback you may have as to how we could model this structure differently in the tool window. The upcoming beta will be the first chance you will have at seeing the Property Manager in action (the community previews available on MSDN had some issues and the Property Manager did not exist at the technical preview at PDC).

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VC++ Project System"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 11 May 2004 00:57

Let me start where I left off in my last post. As shown in the XML in my previous post, there are attributes such as DisplayName, Description, and HelpURL. What do these attributes control? As I stated earlier, the look and feel of the integration of the custom build rule into the project property pages is completely customizable. So what would the custom build rule below look like when viewed in the project property pages? Like the built-in tools, the properties of the custom build rule can be spread out across multiple property pages that group the properties into logical collections. The three properties specified below create two different property pages: the “General” property page and the “Warnings” property page. These property pages would look something like this in the project properties dialog (these images are mocked up and may not reflect what is actually in Whidbey - it's for demonstration purposes only):

Property Pages

The IncludePaths property does not specify which property page it belongs to and is therefore on the “General” property page because it is the default. In addition to these two property pages, a third property page called “Command Line” is also shown. This behaves identically to the property page for the built-in tools like the C/C++ Compiler and the Linker that you are familiar with. It allows the user to view the current command line and specify additional options (through the use of the [AdditionalOptions] tag mentioned in my last post). If the “General” property page was viewed, the properties in the property grid would look something like this:

Include Paths

Notice the name of the property and the description shown below it. These match what was specified in the tool file. Also note that the current value is “..\foobar;..\llama”, which will translate to “/I ..\foobar /I ..\llama” on the command line when the tool is run (because the property is a delimited string property). Now let us take a look at what the “Warnings” property page might look like:

Warnings Property Page

Note that, like in the “General” page, the properties are bolded. This is because they are not inheriting the default value. If the user hit F1 while either property was selected, the help system would bring up the HelpURL specified (in this case, a bogus URL of http://mysite/foobartool.htm). This allows tool file authors to point users at tool documentation if they have any questions not covered in the description of the property. If the user were to click on the dropdown for the “WarningLevel” property, it might look like this:

The text specified for each value directly correlates to the EnumValue DisplayName attributes given in my last post. And just like the built-in tools, the “Command Line” property page might look something like this:

Additional Options Page

Note that /OtherSwitch has been specified in “Additional Options”. The [AdditionalOptions] tag has been replaced in the command line with this value. As well, the other tags have been replaced with their corresponding Switch representations derived from their current values. The command line shown is what would be used to compile a .foo file (at the configuration level; like built-in tools, it is possible to override settings on a per-file basis).

Hopefully this demonstrates how in Whidbey you can extend the Visual C++ project system to support other tools by simply authoring an XML file. There will be complete UI support for creating these tool files, so you won’t be limited to notepad to create your tool files. There will also be automation support, so you can create and manipulate tool files through a VSA script, for instance. In fact, let me demonstrate how cool it is to be manipulating these properties through a VSA script. Assume that the tool file defined below is associated with a VC++ project. You can actually manipulate the custom build rule properties like any other property in the project system when using a VSA script (assuming reference and import of Microsoft.VisualStudio.VCProjectEngine):

<code>
' Get the first VC++ project in the solution
' Assumption: there is at least one project in the solution and the first one is a VC++ project

Dim project As VCProject = DTE.Solution.Projects.Item(1).Object

' Get the first configuration in the project (typically the Debug|Win32 configuration)
Dim configuration As VCConfiguration = project.Configurations.Item(1)

' Get the built-in C/C++ compiler tool
' Assumption: this configuration is not a Makefile or Utility configuration

Dim compilerTool As VCCLCompilerTool = configuration.Tools("VCCLCompilerTool")

' Display the additional include directories for the C/C++ compiler tool on the first configuration
MsgBox("C/C++ additional include directories: " & compilerTool.AdditionalIncludeDirectories)

' Get the Foobar custom build rule
' Assumption: the Foobar tool file has been associated with this project

Dim foobarRule As VCCustomBuildRule = configuration.Tools("Foobar")

' Display the include paths for the Foobar tool
MsgBox("Foobar include paths: " & foobarRule.IncludePaths)
</code>

Note that you can get and set the properties defined in the XML like you do the built-in tools. It really is as if Foobar was a built-in tool. That’s it for now. My next post will either cover property sheets or more samples of interacting with the object model from VSA (a follow up to my post back in Feburary).

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VC++ Project System"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 07 May 2004 23:01

As I touched upon in my last post, custom build rules can be used to build files with tools that are not known to the Visual C++ project system. Unlike custom build steps (just to be clear, we still support those in Whidbey), custom build rules operate on a set of files based on the file extension (you can also configure non-matching files to use the rule like you would any other built-in tool). Custom build rules are defined in external files called “tool files” (the name has a history behind it; although you can consider them to be “rule files”). These files define what the command line syntax is for the command line tool to be integrated into the IDE. In addition, custom build rules can contain “rule properties” which make custom build rules appear like any other tool in the project system. There are four different supported property types: boolean, string, integer, and enumeration. These properties, like the properties of the built-in tools, appear in the property grid in the project property pages; so custom build rules can appear and act just like normal built-in tools. This integration into the property pages is completely customizable: from the number of property pages to display to the look and feel of each property in the grid. Custom build rules utilize a special syntax to describe how these properties translate to switches on the command line when the tool is executed. Imagine that we have a “foobar.exe” command line tool that compiles a list of .foo files into a single .bar file (this is called a “target” custom build rule, meaning it produces a single output; alternatively, the Outputs property could use a file related macro like $(InputFileName) to be considered a “file” custom build rule). The tool file defining the custom build rule to handle .foo files might look something like this:

<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
     Name="Foobar Tools"
     Version="8.0"
     >
     <Rules>
          <CustomBuildRule
               Name="Foobar"
               DisplayName="Foobar Rule"
               CommandLine="foobar.exe [WarnAsError] [WarningLevel] [IncludePaths] [AdditionalOptions] [Inputs]"
               Outputs="$(IntDir)\output.bar"
               FileExtensions="*.foo"
               ExecutionDescription="Compiling foo files..."
               ShowOnlyRuleProperties="true"
               >
               <Properties>
                    <BooleanProperty
                         Name="WarnAsError"
                         DisplayName="Treat Warnings As Errors"
                         PropertyPageName="Warnings"
                         Description="When set, treats warnings as errors so that whenever a warning is emitted, an error is also emitted."
                         HelpURL="http://mysite/foobartool.htm"
                         Switch="/WX"
                    />
                    <EnumProperty
                         Name="WarningLevel"
                         DisplayName="Warning Level"
                         PropertyPageName="Warnings"
                         Description="The warning level for the foobar tool.  The higher the warning level, the more likely a warning will be emitted."
                         HelpURL="http://mysite/foobartool.htm"
                         DefaultValue="1"
                         >
                         <Values>
                              <EnumValue
                                   Value="0"
                                   Switch="/W0"
                                   DisplayName="Warning Level 0 (/W0)"
                              />
                              <EnumValue
                                   Value="1"
                                   Switch="/W1"
                                   DisplayName="Warning Level 1 (/W1)"
                              />
                              <EnumValue
                                   Value="2"
                                   Switch="/W2"
                                   DisplayName="Warning Level 2 (/W2)"
                              />
                              <EnumValue
                                   Value="3"
                                   Switch="/W3"
                                   DisplayName="Warning Level 3 (/W3)"
                              />
                              <EnumValue
                                   Value="4"
                                   Switch="/W4"
                                   DisplayName="Warning Level 4 (/W4)"
                              />
                         </Values>
                    </EnumProperty>
                    <StringProperty
                         Name="IncludePaths"
                         DisplayName="Include Paths"
                         Description="Specifies the directories to search when resolving include directives."
                         HelpURL="http://mysite/foobartool.htm"
                         Switch="/I [Value]"
                         Delimited="true"
                         Inheritable="true"
                    />
               </Properties>
          </CustomBuildRule>
     </Rules>
</VisualStudioToolFile>

Here, we see a tool file with name “Foobar Tools”. Tool files can contain any number of custom build rules, but only a single custom build rule is defined in this tool file. When a tool file is applied to a Visual C++ project, the custom build rules are added as tools to each configuration’s Tools collection and the rule becomes associated with matching files automatically (as long as those files have an empty custom build step as the current tool). This custom build rule takes all *.foo inputs and compiles a single output.bar into the intermediate directory.

Note that special tags are used in the CommandLine attribute. These tags map to switch representations of the custom build rule’s properties. This particular custom build rule has one boolean property, one enumeration property, and one delimited string property defined. The boolean property named WarnAsError has a Switch value of “/WX”. When the property is set to true, the tag [WarnAsError] is replaced with “/WX”. When it is set to false, [WarnAsError] is replaced with the empty string. The enumeration property operates similarly to the boolean property, except the enumeration property has a range of possible values. If the value of the WarningLevel enumeration property is 2, then [WarningLevel] is replaced by “/W2” which is the switch representation specified in the matching EnumValue. If no matching EnumValue is found for the current value of an enumeration property, the tag is replaced with the empty string. The third property defined is a delimited string property called IncludePaths. Unlike the boolean and enumeration properties, string properties (as well as integer properties) use another special tag called the [Value] tag. When this tag is encountered in the Switch of a string or integer property, it is replaced with the current value of the property. For non-delimited strings, [Value] is replaced with the complete string. For delimited strings, [Value] is replaced with one of the values of the entire string. Take for example a string with value “foo;bar”. For a delimited string with Switch “/I [Value]” this becomes “/I foo /I bar” on the command line when executed. For a non-delimited string this switch becomes “/I foo;bar”. This string property is also inherited, which means that if the property is set on the file configuration level, the value set at the configuration level can be inherited (just like the Additional Include Directories property on the C++ compiler). Integer properties behave just like non-delimited non-inherited strings, except their type is, of course, an integer rather than a string.

Properties can also make use of other properties in their Switch value using the same tag syntax (basically, wherever [] is encountered, it will be replaced with the corresponding evaluated Switch). Also shown in the CommandLine property in the tool file above is the [AdditionalOptions] tag. This tag is replaced with the text the user types into the “Additional Options” field in the “Command Line” property page for the rule in the property pages. Another tag not shown here is the [AllOptions] tag. When this tag is encountered, all the properties will be evaluated and their switch representations put on the command line. So instead of “foobar.exe [WarnAsError] [WarningLevel] [IncludePaths] [AdditionalOptions] [Inputs]”, I could have specified “foobar.exe [AllOptions] [AdditionalOptions] [Inputs]”. The [Inputs] tag is the last reserved tag. This tag allows you to specify where the inputs go on the command line. For tools that support input batching (target custom build rules inherently support batching), this will become a delimited (the default delimiter is a space) list of inputs that can be batched together (as long as they all have the same settings). For tools that do not support input batching, the [Inputs] tag is replaced with a single input.

So what do all of these other attributes in the XML control? I will cover this in my next post.

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VC++ Project System"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 05 May 2004 21:12

So it appears that it is time for me to do my once-a-month blog entry (I'm going to get in the habit of doing this every other night, at least). I want to talk about some of the new features the VC++ project team has been working on in Whidbey. Over the next few posts I'll go into some of these in depth (especially custom build rules and property sheets). So here's a quick list and overview:

  • Multi-proc builds: if you have multiple processors in your machine, you can build your projects in parallel. This works through utilizing project dependencies. So projects that don’t depend on one another (directly or indirectly) can build on different processors at the same time. This greatly reduces build times for large solutions that don’t have a lot of linear dependencies.

  • Multi-platform support: in Whidbey, the target platform can actually be more than just Win32. We’ll support native targeting of Itanium and x64 using the x86 cross compilers (build on x86, deploy to Itanium/x64 machines).

  • Property sheets and the new Property Manager: in previous versions, maintaining properties between multiple VC++ projects has been difficult (for the most part, you were limited to using environment variables that are evaluated using the $(EnvVar) syntax). In Whidbey, we are introducing a new file called the property sheet. A property sheet, like a configuration section in the project file, contains a collection of tools and their properties. This property sheet can then be associated with any number of project configurations. When the property sheet is changed, the configurations that inherit the properties from the property sheet immediately see the change. In addition to this, we have introduced a new tool window called the Property Manager that enables you to create and manage these property sheets. Property sheets and the property manager make it much easier to keep consistent settings between multiple projects.

  • Custom build rules: unlike custom build steps, which operate on a per-file basis, custom build rules allow you to specify how to build files of a particular type. So when you add a file of a matching extension to the project, the project system automatically associates the build rule with the file. Custom build rules are defined in XML files external to the project, so they can be applied to multiple projects easily. The best part of custom build rules is their ability to integrate into the project property pages like any of the other “built-in” tools (like the C/C++ compiler, the linker, etc). This means you can have friendly properties like “Include Directories” or “Warning Level” that gets translated into switches that appear on the command line. The look and feel of the integration into the property pages is completely configurable (from what appears in the property grid to what help the user gets when they hit F1 on each property in the property grid). I’ll go into this in more depth in my next post.

  • Support for XML doc comments: we now support XML doc comments in compiled files. The compiler outputs an .xdc file which contains the documentation information fragments. There’s a new tool called xdcmake which takes these fragments and produces the final .xml comments file. This tool is integrated into the IDE, so producing doc comments is as simple as enabling the /doc switch in the compiler’s property pages (the xdcmake tool automatically runs when the compiler outputs .xdc files). In addition, IntelliSense will support these xml comment files.

  • Profile guided optimization support: you can now easily take advantage of profile guided optimization which is a new tools feature for C++ that enables optimizing your application based on real customer runtime scenarios. This is done in a three step process. The first step is to instrument the application so that it can be profiled. This step is performed through a single command called “Instrument”. Once the application has been instrumented, the application is run using the “Run Instrumented Application” command (or simply Ctrl+F5). While the application is running through the actual customer scenarios you want profiled, profiling data is collected and stored. Then, when it comes time to optimize the executable, another command called “Optimize” takes the data that was collected and relinks the executable so that the code becomes specifically optimized for the executed code paths. It is definitely cool stuff.

  • Show all files in solution explorer: there’s a new view in solution explorer that shows what is on disk rather than what is in your project. Along with this comes the ability to rename files (without having to remove, rename, and re-add), delete files off disk, and create and delete physical folders on disk.

  • The Create New Project from Existing Code wizard: a new wizard which allows you to create new projects in directories already containing source code. The wizard configures both projects that use Visual Studio to build and projects that are “externally built” (a.k.a. Makefile projects, although I consider it a misnomer). The wizard will search for files and automatically add them to the project.

  • Better IntelliSense support in “Makefile” projects: we’ve added some new properties that are exposed both in the Makefile project wizard and in the Create New Project from Existing Code wizard which control IntelliSense parsing, such as include directories, preprocessor defines, etc. There are many new IntelliSense features for VC++ which “Makefile” projects take advantage of too. However, I won’t go into that here (I’ll try to convince some of our IntelliSense guys to start a blog discussing these new features because some of those features I absolutely love).

And finally, some changes that are long over due (IMO):

  • Up-to-date madness: No longer does the solution build go to each project and ask it to build. Instead, each project is checked for being up-to-date prior to performing a build (which is more expensive even if the project is up-to-date because a lot of extra work is done). In addition, if every project is up-to-date in the solution, a single line of text informing the number of built, failed, up-to-date, and skipped projects appears instead of the plethora of up-to-date messages that appear in the output window (at least a few lines per project) in 2002/2003. I think those of us that remember how fast doing a build of a large workspace in 6.0 was when everything was up-to-date will be pleased with this change.

  • IDL/RC dependency scanning: the dependency scanning of idl files is one of the most frequently reported reasons for projects always building in VC++. The reason is that the dependency scanner isn’t very knowledgeable about the preprocessor state, so conditionally included files that do not exist on disk are thought to be missing scanned dependencies, even though these files are not needed to successfully compile the file. If you’re seeing something like this (an .idl or .rc file always building), check the HTML build log generated at the end of the build. It should contain a list of files that are causing the files to be constantly recompiled (discoverable, isn’t it?). Adding these files to the include path should resolve the problem. This is luckily a thing of the past in Whidbey.

Well, that’s just a short list of all the new IDE features for Visual C++ (some of the best aren’t even listed here – I was just focusing on stuff the project team has been working on and even this list is not complete). Not to even mention the new C++ syntax to target the CLR! I think there’s definitely a lot going into Whidbey for C++ users to get excited about. In my next few posts I will go into these a little more in-depth and give some examples.

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VC++ Project System"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 25 Mar 2004 16:48

The change to VCBuild has now been posted to www.gotdotnet.com.  Thanks to Thomas and Victor for reporting issues they were having so we could get them fixed.  Here are the changes:

  • Added missing version information in the resource section (version is now 7.1.3088.1)

  • Added /showenv switch which controls the display of the build environment in the HTML build log

  • Added /nologo switch to suppress the display of the version and copyright message (like the other tools do)

  • Fixed incorrect platform directories (those specified in Tools | Options) when /useenv is not specified

  • VCBuild now reports the number of projects that failed to build in the exit code.  The convetion is: -1 for general failures before the build starts, 0 for a successful build, and > 0 for the number of projects that failed to build.

Breaking change: as reported by Victor, the short form of the /useenv switch is not /u as shown in help, but it was in fact /e.  The short form of the /useenv switch is now /u to match what is displayed in help.  Please update any usage of the old short form of this switch.  The reason for doing this rather than fixing the resource string is to maintain forwards compatiblity with any future version of VCBuild.

Feel free to send me e-mail or respond to this post on my blog if you have any issues, and I will try to address them as soon as possible.

Thanks!

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VCBuild"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 16 Mar 2004 05:01

It has been a little while since my last post (that “tomorrow” has turned into a few weeks).  I have been quite busy making sure Whidbey is a great product for users of the Visual C++ project system.  Unfortunately, my blog has taken a back seat to my work and personal life.  I hope to start posting more content very soon (I would like to continue discussion of the Visual C++ project system object model).  As well, I am still in the process of getting VCBuild updated on gotdotnet.com to fix some of the issues reported to me from users (see my last post and the comments - thanks to everyone that is using the tool as well as to those who provide feedback; it is very much appreciated!).  I also have many topics that I want to cover explaining Whidbey features in depth, once I am able to do so.  Some very cool stuff to come, so stay tuned.

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 11 Feb 2004 03:44

Let me take a quick break from talking about the object model (I'll continue on the subject tomorrow) so that I can talk about VCBuild.

VCBuild allows you to build Visual C++ 2003 project and solution files containing Visual C++ 2003 project files from the command line.  It is a very light weight tool (~55K) that utilizes an existing install of Visual Studio to build from the command line.  Although it only builds Visual C++ project files, unlike using “devenv /build” it uses very little memory.  So if sounds useful to you at all, please take a look at the tool.

I'd also like to talk about two bugs that were skillfully reported to me by vawjr on Undernet's #C++ channel.  Both relate to the use of the /useenv switch for vcbuild.  The first bug is that help for the tool specifies /u as the short switch for /useenv.  This is incorrect.  It is actually /e.  Secondly, if you do not use the /useenv switch, vcbuild is supposed to rely on the same environment variables that are specified via Tools | Options | Projects | VC++ Directories (for PATH, LIB, INCLUDE, and LIBPATH).  Instead, vcbuild incorrectly looks at the initialization information stored in the registry (what shows up in the directory options the first time you view them).  When you modify what is in Tools | Options | Projects | VC++ Directories, this information is not persisted in the registry but instead to your user's application data directory. 

So if you're using vcbuild, I would recommend using vcvars32.bat to setup the environment and modify those four environment variables to match your path requirements before running vcbuild with the /useenv switch (remember, /useenv or /e, not /u).

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VCBuild"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 10 Feb 2004 00:35

For my first product-related post, I want to talk a little about the VC++ project system and properties (relative to versions 2002 and 2003). By "properties" I mean the project settings you specify in the project properties dialog. So how does what you set in the project properties dialog relate to the Visual C++ Project System Object Model?

First, let's talk about the VCProject object. This object represents a Visual C++ project. For the most part, this object is a collection of: platforms (not very interesting in 2003, as the only platform is Win32), configurations (project-level settings), files (the files that appear in Solution Explorer), file configurations (file-level settings), and filters (groups of files that create a logical association between files in the project; represented by a folder icon in Solution Explorer). The VCProject object has some properties that allow you to control where the project file should be saved. The methods of the VCProject object allow you to add and remove files, filters, and configurations. With respect to project system properties, the VCProject object is the starting point for accessing the properties that appear in the project properties dialog.

The VCProject object has a Configurations property which is a collection of VCConfiguration objects. The VCConfiguration object represents a project configuration for a Visual C++ project. A project configuration is a collection of settings that map to a solution configuration. The concept of a solution was introduced in Visual Studio .NET 2002. In its most basic sense, it is a collection of projects and solution configurations. A solution configuration, like "Debug" or "Release" (these appear in the dropdown on the toolbar), is a one-to-many mapping between a solution configuration and a project configuration from each project in the solution. For instance, the "Debug" solution configuration may map to each project's "Debug" configuration, but it could also map to any configuration in each project. To get a better understanding of this relationship, you can access the Configuration Manager from the Build menu. The VCConfiguration object's properties relate to what you see on the General page in the project properties (containing such properties as IntermediateDirectory, OutputDirectory, etc). The VCConfiguration object's methods can be used to start a build, or evaluate a string containing project system macros (see Josh's related post about macros). For the scope of this post, however, the VCConfiguration object stores debugger settings, accessible through the DebugSettings property (which I won't go into with this post), and a collection of tool objects, accessible through the Tools property.

The Tools property of the VCConfiguration object returns a collection of tools. These tools represent the individual command line tools recognized by the project system (for example, the compiler, cl.exe, or the linker, link.exe). This collection is indexed using the tool object's name. For instance, if I wanted to access the C/C++ Compiler settings, I would index into the Tools collection using "VCCLCompilerTool", which would get me the compiler tool object. Each tool's property directly relates to what is shown in the project properties dialog. For example, modifying the VCCLCompilerTool.AdditionalIncludeDirectories at the configuration level would be reflected in the project properties dialog under the C/C++ Compiler | General page. For a list of tool objects and their properties (as well as the other objects in the object model), click here.

Now, this explains how to manipulate the project configuration’s settings, but how do you modify settings on a per-file basis? To start, you must get the object that represents the file in the project. To do this, the Files collection on the VCProject object is used. This collection can be indexed based on the file’s full path or the file’s relative path to the project. Each file in the project is represented by a VCFile object. The VCFile object has file properties that describe the physical file (like type, extension, name, etc) as well as one particular property that relates to this topic: the FileConfigurations property. This property returns a collection of VCFileConfiguration objects that represent a collection of file-level settings.

For every project configuration in a Visual C++ project, there exists a corresponding file configuration accessible through the FileConfigurations property on the VCFile object. So if the project has two project configurations, "Foo" and "Bar", then every file in the project has two file configurations with names "Foo" and "Bar". The VCFileConfiguration has two important properties that appear in the file properties dialog: the ExcludedFromBuild property which controls whether or not the file gets built when the associated project configuration does, and the Tool property which controls the associated file tool that builds this file. By casting the Tool property to the appropriate tool object (for instance, VCMidlTool for midl), you can manipulate file-level properties that only affect this one file.

I’m going to stop here, as this is a pretty long post. My next post will show how this relates to the Visual Studio Automation Object Model so you can write macros that take advantage of this knowledge (I’ll give examples too). I think either Josh Shepard or I will also talk about the evaluation chain for project properties (I think Josh has already touched on how macros evaluate in his latest entry).

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "VC++ Project System"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 05 Feb 2004 01:10

Let me introduce myself.  My name is Peter, and I am a Software Design Engineer working on the Visual C++ Project System.  What is the Visual C++ Project System, you ask?  Well, it is the part of Visual C++ that is responsible for the project file (.vcproj), the project properties, the build system (tracking dependencies, generating command lines, etc), and the UI (Solution Explorer, menus, etc).  I hail from Georgia (the state), and attended Virginia Tech (go hokies!) where I received my bachelor's degree in Computer Science.  Last year I got married to my wife, Heather (who also graduated from VT).  I usually idle on the Undernet IRC network in the #C++, #VC++, and the #C# channels (although, I often get some spare time to chat, answer questions, and receive bug reports and suggestions).  And if you're a gamer, you will probably find me on Seattle-area Counter-Strike servers with other Microsoft regulars on the weekends.

In the coming days, I plan to talk about the project system's object model, how properties are evaluated, and tips and tricks for successful project management.  And as time progresses, I hope to provide information on the new features in Whidbey to get you as excited about it as I am.  In the meantime, check out Josh's Blog (another project system developer) for other information about the project system.

[This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.]

Author: "peterhu" Tags: "Off Topic"
Comments Send by mail Print  Save  Delicious 
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader