In last week’s blog, Plugins: To Register or Not to Register, I discussed differences between COM registered plugins and registry free plugins.
Registered plugins are referenced by the class ID in the xml configuration file. If STK cannot load the plugin, STK will display error in the Message Viewer window. Usually error simply says: “Class not found,” which is not very descriptive. Over the years, I compiled list of the possible issues and solutions.
Here are my top reasons why a COM registered UI Plugin does not work:
- XML file missing/incorrect:
- If you open STK Desktop Application, check the Message Viewer window, and do not see a message that STK tried to load your plugin it means there is an issue with the plugin manifest file. The manifest file needs to be valid XML file and point to your plugin. Check the STK programming interface help for more information.
- The plugin is not COM visible:
- Under the project properties, on the “Application” tab, click on the “Assembly Information…” button and make sure the “Make assembly COM-Visible” check box is checked.
- Under the project properties, on the “Build” tab make sure the “Register for COM interop” check box is checked. Note: according to the Visual Studio documentation, this option is not necessary to run the project outside Visual Studio, but I have empirical evidence to the contrary.
- The plugin was not built with the right permissions:
- My regular account does not have the administrator privileges on my computer. In order to build the plugin I need to open Visual Studio under the administrator account. Even when I built the plugin without administrator rights and registered the DLL under the administrator account, the plugin would not run in STK.
- The plugin was not registered (on the user computer):
- There are several ways to deploy the UI plugin:
- Visual studio installer project
- In order to install the plugin, you need to the add primary output from your UI Plugin project to the installer project. The default setting for registering the output is vsdrpCOM (which is the correct setting and should not be modified).
- Manually by coping content of the Bin directory to the user computer and manually registering the plugin using command prompt.
- Make sure command prompt is open under user account with administrator privileges.
- For C#/VB.net plugins, run regasm command located in C:\WINDOWS\Microsoft.NET\Framework\ directory with following syntax: regasm /codebase YOUR_UIPLUGINNAME.dll
- Platform mismatch:
- The STK Desktop application 11 is available in both 32-bit and 64-bit versions. The registered plugins have to match the platform version of the STK desktop application. This means that the user needs to build a 32-bit version of the plugin for the 32-bit version of STK, and a 64-bit version for the 64-bit version of STK. The “reg free” plugins do not have this limitation. STK 10 and earlier versions accept only 32-bit version.
- It looks like building a plugin with "AnyCPU" setting can cause issues. In theory, building the project on the 64-bit operating system for 64-bit STK with "AnyCPU" setting should work. But, I had a cases were users had to change setting to 64-bit before plugin worked.
- .net Runtime mismatch (STK 10.1.3 and lower):
- Before STK 11, STK ran under .net runtime 2.0, so it accepted only the plugins built using .net Framework 3.5 or lower. Starting with STK 11 and Visual Studio 2010, the default framework was set to .net Framework 4.0 or higher.
Hope these help unshroud the "Class Not Found" mystery!