Dependency Visualizer 1.2.0

Just released at http://koti.mbnet.fi/tunedude

Whats new:

• Optionally hide .NET 2.0 references
• Optionally hide .NET 3.0 references
• Generate svg and/or png
• Configurable (the above mentioned items)
• Support for vcproj:s

utmanad..

Jag har tydligen också lyckats bli utmanad (av trion)

Här är några lagom intressanta påståenden i ingen speciell ordningsföljd:

1. Jag hatar allt som liknar kedjebrev (därmed tänker jag inte heller utmana någon fler..)

2. Har nästan lyckats kapa benet av mej medelst motorsåg..

3. Har deltagit i skönhetstävling.

4. Har blivit halvt korsfäst (ja eller i alla fall blivit spikad i ena handen...)

5. Har diplom i komjölkning

6. Kanin är gott...

const (in C++/CLI) considered harmful

Today I found the following "gotcha" in combining C++/CLI and C#.
Create a C++/CLI dll containing something along the lines of:

public ref class Foo
{
public:
  static const int BAR = 42;
};

Use that from C#, maybe like so:

int temp = Foo.BAR;
Foo.BAR = -1;
MessageBox.Show(string.Format("The answer is: {0} ...or {1}",
  temp, Foo.BAR), "WTF!?!");

Wait, that should not be possible! We just said that BAR was const in the C++/CLI code didn't we?

The problem is that it is possible (and gives the following screenshot):

Digging deeper reveals that C++/CLI const turns into an ordinary field with an optional modifier IsConst that languages are free to ignore, (which e.g. C# does).

If you in fact want a "constant" constant (which is probably why you wrote const in the first place?), then you will need to use literal in C++/CLI to get the same result as a C# const.

DependencyVisualizer

The second version of Dependency Visualizer was just uploaded. This time it might actually work :) And in the case it does not, the possibilities to get traces for me should be infinitely better than the first version.

Dependency Visualizer released

I just put up the first public version of the Dependency Visualizer. You might want to try it out..

Extend right-click menu in Explorer in WiX installer

I just had the need to make an installer that created a right-click menu item for Visual Studio solution files (.sln)

The easiest way to accomplish this would have been to use the WiX built in support for registering extensions:

<Extension ContentType="text\plain" Id="sln">
 <Verb Id="Visualize" Command="Visualize dependencies"
           TargetFile="DependencyVisualizerExe"
           Argument='"%1"'/>
</Extension>

However, I soon found out that this was a Bad Idea, in the sense that then my software took over as the default handler for .sln files. Not exactly what I wanted...

Turns out that I needed to manually install the registry keys/values in the appropriate place to get it to work:

<Component Id="DependencyVisualizerComponent" Guid="PUT-GUID-HERE">
 <File Name="DependencyVisualizer.exe" Id="DependencyVisualizerExe"
         Source="!(wix.SourceDir)DependencyVisualizer.exe"/>
 <RegistryKey Action="createAndRemoveOnUninstall" Root="HKCR"
                      Key="VisualStudio.Launcher.sln\Shell\Visualize">
   <RegistryValue Action="write" Value="Visualize Dependencies" Type="string" />
   <RegistryKey Action="createAndRemoveOnUninstall" Key="Command">
     <RegistryValue Action="write" Type="string"
       Value="&quot;[#DependencyVisualizerExe]&quot; "%1""/>
    </RegistryKey>
  </RegistryKey>
</Component>

Oh, and the tool I'm working on is a tool for visualizing inter-project dependencies...

BackgroundWorker and exceptions

Got a bit confused at work today when a piece of software seemingly halted in a place where it should not have been possible.

After looking at the code for a while I found something like the following:

            BackgroundWorker bgw = new BackgroundWorker();
           bgw.DoWork += new DoWorkEventHandler(bgw_DoWork);
           bgw.RunWorkerAsync();           

where bgw_DoWork was (basically) implemented thusly:

        void bgw_DoWork(object sender, DoWorkEventArgs e)
       {
           // ...
            throw new Exception("things went bad");
       }

If you try it out (outside the debugger) you'll notice that the exception is silently swallowed !?!

The moral of the story:

If you use Background worker, either implement a catch all handler within the DoWork method or, hook the RunWorkerCompleted event and check RunWorkerCompletedEventArgs.Error for non-null value.