If you’re testing the installer for your Visual Studio Add-In and you get the following error when launching Visual Studio:

"Switch from current encoding to specified encoding not supported"

and your .AddIn file looks completely normal when you open it in a text editor, then you're most likely not writing your .AddIn file in Unicode. Since the .AddIn usually specifies:

<?xml version="1.0" encoding="UTF-16" standalone="no"?>

Visual Studio expects the file type to be Unicode, so if you wrote your .AddIn file to disk using something like:

File.WriteAllText(addinFile, addInConfig);

You'll need to adapt your code to something like:

File.WriteAllText(addinFile, addInConfig, System.Text.Encoding.Unicode);

To make sure that the file is Unicode.

Hope that helps!

One of the big changes in Visual Studio 2010 is the introduction of the WPF based UI which means that (amongst other things) you can now host WPF windows directly within the IDE without having to wrap them inside WinForm controls.

Unfortunately you may notice that if you create a simple WPF UserControl and then try to create a ToolWindow from it using CreateToolWindow2, you’ll run into the following Managed Debugging Assistant:

Managed Debugging Assistant 'NonComVisibleBaseClass' has detected a problem in 'c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe'.

Additional Information: A QueryInterface call was made requesting the default IDispatch interface of COM visible managed class 'WPFUserControlAddIn.WPFToolWindow'. 

However since this class does not have an explicit default interface and derives from non COM visible class 'System.Windows.Controls.UserControl', the QueryInterface call will fail. 

This is done to prevent the non COM visible base class from being constrained by the COM versioning rules.

If you follow through this error message it will lead you to the MSDN page for this error (here) and from there to the page that holds the solution.

The Solution

Add the following to your [yourfile].xaml.cs around your class declaration:

    using System.Runtime.InteropServices;
    using stdole;

    [ComVisible(true)]
    [ClassInterface(ClassInterfaceType.None)]
    class [yourclass] : UserControl, IDispatch

Note! Don’t forget the addition of the IDispatch implementation (there’s nothing to implement, don’t worry). Without it you’ll get "InvalidCastException" from mscordb.lib and a null in your ref object (the last parameter to CreateToolWindow2.

Got a Sample For Us?

You bet – grab the sample solution. All you need to do is extract, add the .addin file to you AddIns directory (under Documents\Visual Studio 2010\Addins) and away you go.

Here’s an awesome gotcha when moving from a desktop Silverlight application to a Windows Phone 7 application – make sure that your media (wmv) files are set to “Build Action” = “Content” and not “Resource”.

You’ll notice that if you do something like:

<MediaElement Source="somevideo.wmv"/>

Where “somevideo.wmv” is set to “Content”, then the Windows Phone Developer Tools (ie. Visual Studio) will underline the "Source" attribute and recommend that you set it to “Resource”. This is a hangover from the desktop and is something that I hope will go away – you can safely ignore this warning (it won’t appear in your build windows).

What’s Wrong With “Resource”?

For those that want more, here are the potential problems you can run into when setting your media to “Resource”:

1. When a video file is compiled as a Resource it incurs an extra space and performance hit every time you play it, since Silverlight does extra processing to extract the video from your assembly (DLL). In the case of “Content” the file can be read directly from disk (or memory) and you’ll get instant start playback.
2. Anything that makes your DLL larger is evil (from my point of view) – you want your assemblies to be small (think “quick and nimble”). Although the size doesn’t always directly affect load and memory time (there are a couple of other factors at play here) this helps eliminate one more possible bottleneck.

An often overlooked performance tuning feature of Silverlight are the “Frame Rate Counters” and “Redraw Regions” options – Profiling, step aside! In this post I’ll explore the general options and how to enable them, I’ll follow up with a further post on how to use them to help identify performance bottlenecks.

This post is based off the awesome talk that Seema Ramchandani gave at Mix ’10.

Note: To test these out either open an existing Silverlight application, or start a new one. The screenshots in this post are mostly from the Windows Phone 7 Emulator (XDE) so will vary slightly to the desktop version.

Frame Rate Counters

• Enabling
  Open up App.xaml.cs and add the following bolded line to your App() constructor:
  

  public App()
  {
      UnhandledException += new EventHandler(Application_UnhandledException);
      InitializeComponent();
  
      App.Current.Host.Settings.EnableFrameRateCounter = true;
  }
  

• What you’ll see
  In the top left corner of the screen you should see the following counters:
  

  Silverlight Framerate Counters

  
  Note: On the desktop counter A & B are merged into one counter.

• I don’t see the counters! (mobile)
  This means that you are running without hardware acceleration. Either the machine running the emulator does not support hardware acceleration (DirectX 10 for the early refreshes) or you’ve run into a bug (there are a number of them which are currently being zapped) which has caused your device / emulator to run out of video memory. Restart the device / emulator and you should be right.

  Note: To tell if your emulator supports hardware acceleration (or if your device has run out of video memory) look at your screen as you launch a XAP – if it does the page flip animation then you’re ok, otherwise if the app just appears then you are in software.

• What do they mean?
  I’ve added letters to indicate the different fields as so:

  

  1. Render Thread Framerate (fps) (mobile only)
  2. UI Thread Rate Framerate (fps)
  3. Amount of VRAM used by App (kb)
  4. Total number of textures on GPU
  5. Number of intermediate textures

Redraw Regions

• Enabling
  Open up App.xaml.cs and add the following bolded line to your App() constructor:
  

  public App()
  {
      UnhandledException += new EventHandler(Application_UnhandledException);
      InitializeComponent();
  
      App.Current.Host.Settings.EnableRedrawRegions = true;
  }
  

• What you’ll see
  In this example I’m using the default Windows Phone list application and clicking through the list options and then back with the hardware back button.
  

  Redraw Regions highlighting redrawn areas as we transition between pages

• What am I looking at?
  Redraw regions highlights (tints) every part of the screen as it is redrawn, either due to a user initiated action (say, scrolling a non-cached list box) or some code (animation). Cached Objects that are being animated / moved / scrolled etc (BitmapCache) will not be redrawn, but as soon as the object is modified (say, you change its colour as it moves), it will be redrawn – and you will see this highlighted by EnabledRedrawRegions.

  As regions are redrawn the colours will cycle through Blue, Yellow, Pink (Purple) so that you can see the transition – there is no significance to the specific colours.