Windows Live Writer beta 2

Just noticed that WLW beta 2 is out, and I'm trying it out right now..

As far as I understand, it should support Blogger labels, and that has been one of the IMO biggest limitations with the previous beta.

Hopefully this works out properly, and this will be the blogging application of choice when I'll be blogging random stuff from TechEd. Yay!

Technorati Tags: WLW

Speech Recognition isn't really there yet..

It seems we cannot really throw away our keyboards just yet, and only use speech recognition, as the following video clearly shows:

(Perl, is perhaps not the most "speakable" language there is, but nevertheless...)

Technorati : humor, vista

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

Where's the QA when you need them?

Where is the QA when you need them? See the following image for clarification:

It listens to the name of ASUS ACPI Cneter (sic!) ... Product version 1.0.0.0, File version 0.1.0.24

It makes me wonder how something like this have slipped through?

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