The SampleDocViewEditor from the Visual Studio 2008 SDK is useful for figuring out how to create a designer view for an xml file. However, as noted by Nikita Frolov, there is some trickery involved that will cause it to not work for you if you use a different extension.

I found out that if I change the test extension, used in the sample, to something else (say, .testaddin), it would not receive "View Code | View Designer" options in following situation:

1. Create a new project
2. Add ".testaddin" file to the project
3. Exclude it from the project
4. Close the solution and remove ".suo" file (apparently it keeps some info there), or create a new solution
5. Select "Show All Files" and include it back.
Now, the file will be in project, but without "View Code | View Designer" options (no SubType Designer element in csproj).

Simpliest way to change the extension is to take SampleDocViewEditor sample, run Replace on entire solution, replace all entries of "addin" with "testaddin" and then rename "Templates/Sample.addin".

Sample documentation says: "The XML EditorFactory takes care of setting the VSHPROPID_SubItemType property for us. We just need to register that we are a designer view for a particular type of XML file with the XML Editor." Exploring that, I found out that ".addin" type is an existing type registered under Xml Editor in these keys:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0Exp\Configuration\ Editors\{FA3CD31E-987B-443A-9B81-186104E8DAC1}\Extensions]

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0Exp\Configuration\ Editors\{412B8852-4F21-413B-9B47-0C9751D3EBFB}\Extensions]

This registration is there after regular VS install and is not affected by this sample. If it is removed, the issue starts to happen for .addin files too. Rebuilding the sample in its original state does not restores these keys.

There's an easy way to add those keys. The ProvideEditorExtension attribute modifies its behavior based on the properties you assign. If you leave off ProjectGuid, it will only place the extension under the Editor's guid in the registry and add the requisite values to the key.

However, this didn't seem to solve the problem completely. I still had the same issue. I searched through the registry for relevant entries and discovered that ".addin" was also under Languages/Extensions. This can be placed in the registry by using ProvideLanguageExtensionAttribute.

While we're on the topic, I should mention the two RegistrationAttribute subclasses provided by the sample: EditorFactoryNotifyForProjectAttribute and XmlDesignerViewAttribute. These should be renamed to follow the convention found in Microsoft.VisualStudio.Shell. I recommend ProvideEditorFactoryNotifyAttribute and  ProvideXmlDesignerAttribute. ProvideEditorExtensionAttribute sets the same keys and values as ProvideEditorFactoryNotifyAttribute, but there's no way to prevent it from setting a few undesirable entries. The custom attribute is required surgically set the EditorFactoryNotify for the XmlEditor. ProvideXmlDesignerAttribute sets keys under XmlDesigners, and there doesn't appear to be a class built into Microsoft.VisualStudio.Shell to provide this functionality.

I attended the MVP Global Summit 2009 in Seattle/Redmond, Washington a couple of weeks ago. I had a pretty good time hanging out with other MVPs and the Managed Languages team. I learned a lot, and I had a blast every evening. One of those evenings was at the Experience Music Project, and I promise I will post Steve Andrews, "I love TFS" if I can find the video.

Here's the opening video for the event, followed by a behind the scenes look with Karen Young.

One of the things that confused me about the attributes used to decorate a Visual Studio were the hardcoded guids in the examples. I didn't know where they came from or what I could use. In fact, I had the impression I had to generate my own guid for each definition like how you need to assign one for an editor factory.

It turns out that these are defined guids that you must use for certain activities. They're defined in Microsoft.VisualStudio.VSConstants as static readonly. Like String.Empty, this means you can't use them in an attribute decoration and is why you see string literals instead. Since I couldn't find a list of the actual guids, and I needed them, I wrote a quick console app to retrieve them from the VSConstants class. I then placed them in constant, string form in my own class. Here they are in case you need them as well.

IE8 has been officially released and the download is available.

So why should you download IE8? Well, out of all the new features, accelerators are the best! No, it isn't some trick to load web pages faster. Instead, accelerators accelerate your own web browsing experience. For example, just yesterday, I had to find the meeting location where I was giving a presentation. I also need to pull up directions. After I found the address, here's what I would have to do in other browsers to get directions:

Click 1: highlight and select the address information
Click 2: copy that information (ctrl-c)
Click 3: open a new tab or window
Click 4: enter maps.live.com in the address bar
Click 5: paste the address information into that new site
Click 6: enter, and then view the results

Here's what I do in IE8:

Click 1: highlight and select the address information
Click 2: right-click and hover over "Map with LiveEarth" accelerator, click on directions.

This definitely accelerates my browsing experience.

The managed package framework for Visual Studio eats exceptions. I discovered this while building my own editor.

I started with the package that the wizard creates for you, but I needed different designer rather than the rich text box it gives you. I initially attempted to gut the designer and implement my own functionality. However, it kept throwing a strange exception on me that I could not correct.

I reverted back to the designer that was there, then created a DecisionTablePane class and implemented the interfaces that I thought I would need: IOleCommandTarget, IVsWindowPane, IVsTextLinesEvents. I left the NotImplementedExceptions in place thinking that I could then see what was being called. I changed the editor factory to instantiate the new editor. This worked, and I will refactor later to remove the classes I no longer need; I'm keeping them around to use as a guide.

I tried to open the file type I had registered with the editor, but nothing happened. I thought that maybe I missed an interface, but I couldn't find anything. I then stuck a breakpoint on the method I suspected was being called, and it got there. The exceptions were being consumed without any error reporting. This will make it difficult to debug my Visual Studio package. If something doesn't work, I may not even know it.

When developing plugins for Visual Studio 2008, your testing is done in what's known as an experimental hive. It's essentially Visual Studio running in a testing environment. This keeps your unfinished plugins from being added to your "real" Visual Studio environment.

Unfortunately, this experimental hive tends to become junky. After going through tutorials, you're bound to have all kinds of unnecessary elements added to the IDE. I spent some time trying to clean this out, and I discovered that the Visual Studio 2008 SDK includes a tool to do this. However, its parameters weren't exactly clear and cause me some grief until I got it right.

Here are the commands that work for me:

"%ProgramFiles%\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Tools\Bin\vsregex.exe" GetOrig 9.0 exp RANU
"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"  /setup /rootsuffix Exp /ranu

The first command clears out your experimental hive then copies your regular registry keys and user profile files over. After I did this, I found that all my templates were missing. The second command fixes that problem.

When I ran code analysis on my project, I predictably had some complaints concerning naming. Obviously, kodefu is not a dictionary term. The solution is to add a custom dictionary to the project.

I added this dictionary and reran code analysis. Complete fail; it still did not recognize kodefu.

Whoever wrote the msdn documentation forgot to mention an essential step for adding a custom dictionary to a project. Luckily, argt.home added community content to the article describing the steps necessary to get it working. You must change the item's build action to CodeAnalysisDictionary.

I hope this helps if you've experienced this fail yourself.

It appears that I missed an important method that belongs to Type when making the extension method IsType. Jason Olson pointed out that type.IsSubclassOf would provide the functionality necessary to fulfill my coworker's requirement. The functionality and implementation of IsType is a little different, however. IsType will check the current type then recursively checks each BaseType. IsSubclassOf will return false if the original check indicates that the types are identical. Also, it uses a while loop rather than recursively calling itself.

I find this interesting. Leave a comment on whether you prefer recursive methods or loops.

I also discovered that the compiler modifies my code to the following:

I prefer to keep the original style because I feel it is more readable. In addition to the if statement, I had the option to use the boolean trick or the ternary operator to perform the same function. I tend to think that if statements are easier to read, but I'm always looking to improve my coding style. Let me know what you prefer.

A coworker approached me earlier with a scenario that involved using reflection to find all of the properties in a class that were derived from a specific type. I walked through using reflection to do this, but then I was unable to find a way to interrogate the inheritance chain to determine if the type derived from the type we cared about. You can't use the "is" operator because the type is Type, not an instance of the type.

I ended up making an extension method to do the job. Of course, one could use it like a typical helper method.

This construct is pretty simple. We first make sure that we haven't reached the end of the inheritance chain. If so, we need to return that it isn't of the type specified. If the types are the same, we have a match. Otherwise, we need to interrogate the base type. I decided it was acceptable that this checked the original type as well, because one could call property.PropertyType.BaseType.IsType(someType) if the requirement was to check strictly for derived types.

Update:  Jason Olson pointed out that IsSubclassOf would provide the functionality necessary to fulfill my coworker's requirement.

I like Microsoft's vision of the future, but we seem to have given up on flying cars and robots that do all the work for us. Danger, KodefuGuru!