Fix: Visual Studio opens class diagram in XML editor with double click

Recently, to save myself sometime after having renamed some interfaces/classes in the ClipFlair project sourcecode, I right-clicked one of the class diagrams (.cd files) in it at Visual Studio’s “Solution Navigator” (this is an enhanced Solution Explorer addon) and using “Open With…” I opened up the diagrams with the XML editor to do a rename-all operation for the respective class names.

However, after saving the project I found out that from then on, that specific .cd file was opening up as XML file when double-clicked instead of opening up as a Class Diagram in the respective designer pane. Using Open With dialog would open it as a Class Diagram when asked to specifically, but using the checkbox to always open up as Class Diagram wouldn’t help fix the double-click problem for that specific .cd file (others would open up fine as class diagrams, not as XML files, when double-clicked).

I just managed to fix that issue by right clicking the file node in solution navigator’s tree and and excluding that file from the project (not deleting!), then saving the project, closing the solution containg the project and adding the file (via “Add existing file”) again after having reopened the solution. I could also possibly have right clicked selected “Unload project” after saving it and then select to reload it again, think that would have worked too.

Using VisualHG addon for Visual Studio I commited the changes to the Mercurial repository used by ClipFlair on Codeplex, which showed me that the file difference that did the fix was the following in the .csproj project file:

   <ItemGroup>
     <None Include="Diagrams\Windows.cd" />
-    <None Include="Diagrams\Windows.Views.Interfaces.cd">
-      <SubType>Designer</SubType>
-    </None>
+    <None Include="Diagrams\Windows.Views.Interfaces.cd" />
     <None Include="Diagrams\Windows.Views.ViewModels.cd" />
   </ItemGroup>

 

That is instead of that marked-as-bold entry above (marked by the diff tool with – prefix), the line marked with + prefix should be used instead. This is obviously some bug in Visual Studio 2010, it’s nice to know though that you can easily take the project offline and edit the .csproj to fix it (or remove the .cd file, save the project, reload it and add the file again).

HowTo: Make Project Linker extension’s VSIX install at Visual Studio 2012

Project Linker is a Visual Studio Extension that “helps to automatically create and maintain links from a source project to a target project to share code that is common to Silverlight and WPF”.

In ClipFlair, where I have shared code between a Silverlight and a WPF project (I guess same would be for XNA projects for Xbox360 and for PC), a practice I use is to put shared files in a “Source” project and add them to both projects as links (using “Open as link” action available from Add file dialog if you press the dropdown arrow next to the “Open” button).

An alternative is to put such files in say the WPF project and use the Project Linker tool from Microsoft Patterns & Practices group to link to those files from the Silverlight project easily.

However, that tool seems to be only available for Visual Studio 2010, not for the newer 2012 version. Luckily, some users have posted a workarround at the discussion there (Reviews and Q&A tabs):

1. Download the .vsix
2. Extract contents with 7-Zip (since .vsix is a .zip file which you can see by renaming to .zip or .vsix.zip)
3. Modify file with extension .vsixmanifest to add <visualstudio version="11.0"> to the <supportedproducts> node
4. Change MaxVersion to <supportedframeworkruntimeedition minversion="3.5" maxversion="4.5" /> (this may not be necessary)
5. Zip up contents again
6. Rename extension back to .vsix
7. Install extension

According to comments there, this works but not for all project types. It works if one links the Silverlight project to the WPF one, but not the other way around. It throws a NullReferenceException somewhere in the extension.

HowTo: Type in double-quote in Windows Live Writer

A big nuissance in Windows Live Writer is that when you try to type in a double-quote character you get some special Unicode character (“ or ”, at the start and end of a string respectively), other than the classic ASCII character used in programming.

That way people copy-pasting snippets from your blog can get lots of errors. I remember having that issue sometime ago with people copy-pasting (into a .reg text file) a registry script to add Google search engine into Copernic Agent from my blog and not understanding why it wasn’t working as expected.

However, I found a keyboard shortcut to work-arround this issue. You just press BACKSPACE key right after typing in a double-quote character in Windows Live Writer to restore it a real ASCII double-quote.

Collection of useful links for .NET, Silverlight, WPF etc. development

During the development of ClipFlair (currently at Alpha1-internal version), I’ve been doing lots of research, hunting for information (documentation, related discussion threads, useful download links) needed when writing and refactoring source code etc.

I have tried to organize these links as (Windows) Internet shortcut files into folders. They do need some further restructuring, but they can still be a useful reference. You can download the latest version of those developer links at (will add new separate releases with enhanced/refined developer links in the future):

http://clipflair.codeplex.com/releases/view/90654

Also, you can find blog posts related to issues I’ve come across up to now while developing ClipFlair at (will be updating that page):

http://clipflair.codeplex.com/documentation

VB gotcha: when If function isn’t equivalent to an If-Then-Else block

Just got bitten by the following:

Dim takeN As Integer = If(Integer.TryParse(EdTake.Text, takeN), takeN, itemsCount)

I had used that instead of writing in 2 lines:

Dim takeN As Integer

If not Integer.TryParse(EdTake.Text, takeN) then takeN = itemsCount

However, there’s an important difference:

“If” is a function, so its arguments are evaluated at call-time. The “If” signature is:

I guess the default is to pass arguments ByVal (by value) and not ByRef (by reference), although I’d expect the signature to specify it explicitly to avoid confusion. When one passes a literal value (say 15) to TruePart or FalsePart it just gets “boxed” into an Object, whereas if one passes an expression (e.g. “takeN+1” or even just “takeN”) it gets evaluated first, then result is boxed and passed as an Object.

So, whereas one might think (esp. if coming from the ALGOL “Call-By-Name” era) the 1st line to be equivalent to:

Dim takeN As Integer

If Integer.TryParse(EdTake.Text, takeN) then takeN = [RESULT OF TRYPARSE] else takeN = itemsCount

in fact it’s equivalent to:

Dim takeN As Integer

If Integer.TryParse(EdTake.Text, takeN) then takeN = [ANY] else takeN = itemsCount

where ANY is whatever the takeN variable one had defined contains.

I thought the VB compiler was warning when using a variable before having assigned a value to it, but it seems in this case it misses to issue a warning. In fact I just tried:

Public ReadOnly Property Take As Integer
   Get
     Dim takeN As Integer
     Return takeN
   End Get

End Property

and it still doesn’t complain. Strange, probably it sets new local variables to 0 by default, but it shouldn’t encourage a programming style that relies on implicit default values – such syntax usually means there’s a mistake in the source code that can lead to a nasty bug.

The moral of the story? Avoid such shorthand expressions and stick to classic keyword-based syntactical structures – after all structured programming had been introduced as an alternative to the many times incomprehensible programs written in functional programming languages (e.g. due to overuse of nested function calls).