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.