WPF project building inside of Visual Studio but not with MSBuild/TFSBuild

At work, I recently run into a strange build error when building from MSBuild and TFSBuild while the same solution built inside of Visual Studio 2008 just fine.

The error message was:

error MC3015: The attached property '?' is not defined on '?' or one of its base classes.

(obviously with real names instead of the questionmarks)

Feeding the above into google provided the following solution to the issue:

One of the differences between building in VS and command line is that a WPF build in VS defaults to

<AlwaysCompileMarkupFilesInSeparateDomain>true</AlwaysCompileMarkupFilesInSeparateDomain>.
Outside of VS, the default is false.

(Answer by Rob Relyea)

Adding that to the relevant .csproj made the project build successfully.

Generating GUIDs

This may seem trivial but here we go:

I recently created an installer with WIX and obviously had to create a number of GUIDs along the way. While there is a "Create GUID" option in the Tools menu it has a number of drawbacks:

• Clicking around a UI with a mouse is not the most efficient thing in the world
• There is not an immediately suitable format available, registry format is closest, but braces need to be removed and the rest uppercased

The obvious? solution to this problem is to create a macro like the following:

Public Sub CreateWixGuid()
    Dim g As Guid = Guid.NewGuid()
    Dim textSelection As EnvDTE.TextSelection

    textSelection = CType(DTE.ActiveDocument.Selection(), EnvDTE.TextSelection)
    textSelection.Text = g.ToString("D").ToUpper()
End Sub

and assign a keyboard shortcut to it (I chose Ctrl+G,Ctrl+G), and voilà a GUID in the correct format is generated and inserted.

 

 

Gotcha: Hidden [Flags] attribute on bitfield enumerations

 

Just got reminded of a still unfixed bug.

Consider an enumeration of the following kind:

    /// <summary>
    /// Modes enumeration
    /// </summary>
    [Flags]
    public enum Modes {
        /// <summary>
        /// Yes
        /// </summary>
        Foo = 1,
        /// <summary>
        /// No
        /// </summary>
        Bar = 2,
        /// <summary>
        /// Maybe
        /// </summary>
        Both = Foo|Bar
    }

For the user of this enumeration, it is essential to know that it in fact is a bitfield (as specified by the FlagsAttribute).

However, both Intellisense and object browser fails to give any hint about this fact!?! (Yes, this occurs in both VS 2005 and VS 2008)

So for now, remember to document (within in the summary, so it is visible) this fact for your fellow developers.

"Thank you for the lasting contribution you made to Microsoft Visual Studio"

..that's what is engraved into the glass cube I got in the mailbox today.

Visual Studio 2008 RTM released

Visual Studio 2008 just released (to MSDN subscribers) and the Express versions to the rest of you.

Get it now (or wait a few days to get better download speeds).

Stepping through properties in the debugger

Ever stepped through code in the debugger and ended up in N+1 trivial property getters before you got to the "real code" and felt frustrated?

Enter the DebuggerStepThroughAttribute. MSDN says the following: "For example, the Visual Studio 2005 debugger does not stop in a method marked with this attribute but does allow a breakpoint to be set in the method."

Basically, if you need a breakpoint in there, you'll get there, otherwise Visual Studio won't bother stepping there and just steps over it, which is exactly what we want.

So how do you apply the attribute to a property as its attribute usage states the following?

[AttributeUsageAttribute(AttributeTargets.Class|
AttributeTargets.Struct|
AttributeTargets.Constructor|
AttributeTargets.Method, Inherited=false)]

The point is to realize that while the property itself isn't a method, both the getter and the setter actually are.

So you can do the following:

        public int Foo
        {
            [DebuggerStepThrough]
            get { return m_foo; }
            set { m_foo = value; }
        }

..and now the getter has the attribute, while the setter does not.

Visual Studio 2008 release imminent

S. Somasegar (Corporate Vice President, Developer Division) just announced at Teched Barcelona that Visual Studio 2008 (and .NET 3.5 Framework) will be shipped before the end of November 2007.

Nice!

Integrating Help2 files into VS 2005 - part 2

The other workaround I hinted in the previous post involves a bit of manual labor the first time (or if you ask nicely, I might just provide the needed parts), if used more than once it is IMO less painful than the ORCA route.

This solution takes advantage of <CustomTable> feature of WiX. By "reverse engineering" the needed table schemas out of the relevant merge module MSHelp2_RegTables__RTL_---_---.msm we can author these tables as <CustomTable>:s and then just add <Row>:s as appropriate.

Next time just edit the row data and you're set.

For brevity, I just post one table here, but the rest can be made available upon request.

The tables I've used are HelpFile, HelpFileToNamespace, HelpNamespace and HelpPlugin.

      <CustomTable Id="HelpFileToNamespace">
        <!-- HelpFileToNamespace table definition -->
        <Column 
          Type="string" 
          PrimaryKey="yes" 
          Id="HelpFile_" 
          Nullable="no" 
          KeyTable="HelpFile" 
          KeyColumn="1" 
          Category="Identifier" 
          Description="Foreign key into HelpFile table (required)." />
        <Column 
          Type="string" 
          Width="72"
          PrimaryKey="yes" 
          Id="HelpNamespace_" 
          Nullable="no" 
          KeyTable="HelpNamespace" 
          KeyColumn="1" 
          Category="Identifier" 
          Description="Foreign key into HelpNamespace table (required)."/>

        <!-- data -->
        <Row>
          <Data Column="HelpFile_">YourHelpFileKey</Data>
          <Data Column="HelpNamespace_">YourHelpNamespaceKey</Data>
        </Row>
      </CustomTable>

Integrating Help2 files into VS 2005 - part 1

For various reasons (curiosity among others) I've been playing with integrating custom API documentation into Visual Studio, this turned out to be rather laborious.

For future reference I thought I'd document the process here.

- Create the code to be documented, use xml comments and turn on the generate xml comments switch in the project settings.

- Install Visual Studio SDK (yes, really ...)

- Install Sandcastle

- Install Sandcastle Help File Builder

- Open SHFB and create a Help2 project and customize appropriately.

- When the project builds successfully, open all the various .Hx? files (except .HxS) and remove the DTD reference, and from the .HxC file also the <CompilerOptions> element including contents. (For further info refer to the helpware site.)

- Now Microsoft wants you to use the Help Collection Integration Wizard, or manually edit merge files with Orca, neither of which is any fun.

- WiX has a WixVSExtension that among other thing has <HelpFile>, <HelpFileRef>, <HelpCollection> and <PlugCollectionInto> elements which sound promising.

- The problem: the WixVSExtension is currently broken, specifically bug 1588180 

- The bug comments include a suggested fix that involves recompiling WiX. Due to dependency issues this seems like a PITA.

- There is however also another workaround ... stay tuned!

Different signing options depending on configuration

There was a question in the MSBuild newsgroup about the possibility to have different signing settings depending on configuration.

Basically, let's pretend pretend that what we want is the following:

• Debug: Delay sign using PublicKey.pk


• Release: Sign using KeyPair.pfx

From within Visual Studio it seems impossible, due to the fact that the configuration boxes are grayed out. All is not lost though, by moving the code signing options into the appropriate configurations (by directly editing the project file).

Debug:

<PropertyGroupCondition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">

<snip/>

<SignAssembly>true</SignAssembly>

<DelaySign> true</DelaySign>

<AssemblyOriginatorKeyFile>PublicKey.pk</AssemblyOriginatorKeyFile>

</PropertyGroup>

Release:

<PropertyGroupCondition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

<snip/>

<SignAssembly>true</SignAssembly>

<AssemblyOriginatorKeyFile>PrivateKey.pfx</AssemblyOriginatorKeyFile>

</PropertyGroup>

And there you go!

(The obvious? drawback with this method is that the signing behavior isn't directly visible from within the Visual Studio project properties.)

Technorati : MSBuild, Visual Studio

Editing a Visual Studio 2005 project file

[This is not really news, just wanted to publish it somewhere so I can refer to it]

So how do you do it then?

It is simple actually:

• (If the project file is under a locking source control provider e.g. Microsoft SourceSafe, you probably want to check out the project file first, as Visual Studio isn't smart enough to do it for you when you edit the file directly.)


• Right-click a project in the solution explorer


• Choose "Unload project"


• Right-click the same project, that now is grayed out and suffixed with (unavailable)


• Choose "Edit <filename>"


• Edit away ...


• Right-click the project, still suffixed with (unavailable)


• Choose "Reload project"

There you go!

Caveat: This doesn't work under the Express versions of Visual Studio. That is, the "Unload Project" menu item is absent, you can still use the editor with schema support.

Technorati : MSBuild, Visual Studio

Visual Studio dependencies

I figured I'd walk through the details on how to find out dependencies of a Visual Studio solution/project. (For those who haven't figured it out yet, this is a description how Dependency Visualizer does it)

1) For MSBuild compatible project types, it's dead simple, just use the following XPaths, where msbuild stands for the MSBuild schema: http://schemas.microsoft.com/developer/msbuild/2003

Assembly references: /msbuild:Project/msbuild:ItemGroup/msbuild:Reference/@Include

Project references: /msbuild:Project/msbuild:ItemGroup/msbuild:ProjectReference/msbuild:Project/text() returns a relative path to the project file.

2) There are project types that aren't MSBuild compatible (most notably C++ ones), and due to popular demand, I had to add support for these also to Dependency Visualizer.

Assembly references are simple: /VisualStudioProject/References/AssemblyReference/@AssemblyName

Project references: Here is where it starts getting nasty..

/VisualStudioProject/References/ProjectReference/@ReferencedProjectIdentifier gives... you guessed it, a GUID identifying the referenced project. This means we have to parse the freeish text format of the solution file, to find out what project hides behind the GUID. But it gets uglier still, turns out that there's actually dependencies and dependencies. If you go to "Project Dependencies..." window (in VC++) and check a project, then you end up with a reference that's only existing in the solution file like so:

  Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ProjectName",
  "ProjectName\ProjectName.vcproj", "{769945FD-50DC-49E4-B93E-54250D7BF541}"
    ProjectSection(ProjectDependencies) = postProject
      {A4583937-88F4-4C1D-B5A9-E711C3951E3A} = {A4583937-88F4-4C1D-B5A9-E711C3951E3A}
    EndProjectSection
  EndProject

Where the GUID:s fit together like so: the first one is the type, the one on the second row is the project identifier, the thwo on the fourth row is the identifier of the referenced project.

Technorati : Dependency Visualizer, MSBuild, Visual Studio