Update to this post available here.
Visual Studio 2010 shipped earlier this week. Some of you have already tried to use STK Engine within the new IDE, and reported a problem to us. Basically, using the STK Engine ActiveX controls in the designer fails with the following error: "Failed to import ActiveX control. Please ensure it is properly registered.". We are working with Microsoft to resolve this issue (SR#110041547733980). In the meantime and until a better resolution is identified, this post provides workarounds that will allow you to use STK Engine with VS2010.
Before providing workarounds let me give you some background on the issue. This will also help to understand why the workarounds work...
The issue is due to a change in the .Net 4.0 version of AxImp. AxImp is used behind the scenes by the Visual Studio IDE to generate managed wrappers for our ActiveX controls. AxImp uses the registered Primary Interop Assemblies (PIAs) to resolve dependencies. In the previous .Net framework versions, AxImp used the codebase (i.e. the full path, for instance: [C:\Program Files\AGI\STK 9\bin\Primary Interop Assemblies\AGI.STKUtil.Interop.dll]) specified by the PIA registration to find the location of dependent assemblies. In the latest version, AxImp no longer looks at this information and instead tries to load the assembly using its full name (for instance: [AGI.STKUtil.Interop, Version=184.108.40.206, Culture=neutral, PublicKeyToken=46f7a65aaf1b26a0]). This fails as the CLR/fusion loader does not know where the assembly is. So the workarounds below help AxImp to find where the dependent assembly is located.
Note: The paths specified below assume a x86 machine. On a x64 machine change to [C:\Program Files (x86)] in all the paths.
First workaround - AxImp.exe.config (preferred workaround)
This is the preferred workaround, as it is localized to AxImp and does involve any system wide change. With notepad create a new file with the content below. Named it AxImp.exe.config and save it to [C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools].
<?xml version ="1.0"?>
href="C:\Program Files\AGI\STK 9\bin\Primary Interop Assemblies\AGI.STKUtil.Interop.dll"/>
You might need to update the version number and path appropriately for your STK installation. This config file basically tells AxImp where to find the AGI.STKUtil.Interop assembly. After adding this file the Visual Studio IDE Designer will work properly. Now to be able to run you also need to ensure that the [Embed Interop Type] option on the [AGI.STKUtil] assembly is set to False. To do this select AGI.STKUtil in Solution Explorer. Bring up its properties. Change the [Embed Interop Type] property to False. Here is a sceenshot showing the correct configuration:
Second workaround - GAC
Another option to help AxImp in finding the AGI.STKUtil interop assembly is to register that assembly in the GAC. However Microsoft does not recommend registering PIAs in the GAC, and this might have side effects on your system. However, if for some reasons the first workaround above is not suitable for you, this is another possibility. Basically run the following command as an administrator:
gacutil /i "c:\Program Files\AGI\STK 9\bin\Primary Interop Assemblies\AGI.STKUtil.Interop.dll"
This command should succeed with the following output: "Assembly successfully added to the cache".
(If you need to undo this use: gacutil /u AGI.STKUtil.Interop)
Third workaround - Generate managed wrappers by hand
The third workaround involves more manual labor, and I will not get into details here. You could also run AxImp from the command line outside of Visual Studio, specifying the /rcw option to point to the AGI.STKUtil.Interop assembly. Then use the wrappers that you generated in the Visual Studio toolbox instead of the ActiveX controls.
We will post updates as we hear back from Microsoft about this issue. In the mean time use the workarounds above and enjoy the new Visual Studio!