I’ve recently upgraded development of a 32bit C++ plugin from Visual Studio 2003 to 2008. It all works fine on the XP32 development box.  However, when I try and install the plugin on a Vista64 box (32bit XSI installed), the plugin dll shows red in the PluginManager and I get an “Unspecified failure” error when I double-click on it.  This used to work just fine with VS2003…

Same problem if I upgrade one of the sample projects (SimpleCommand from the SDK example) to VS2008, compile on XP32, then install it (as a 32bit plugin) on a 32bit version of XSI running on 64bit Vista.

Anybody else encountered this?  Is it a simple VS2008 settings?

micah

Fixed.  I re-created the solution projects from scratch (in VS2008) and they run fine.  I don’t know what the difference is, but it must be something to do with the VS2003->VS2008 upgrade process.

In case others stumble on the same problem…

I ran into similar issues changing a 32bit plugin to 64bit.  Changing the ‘Runtime Library’ option in the project’s ‘C/C++ -> Code Generation’ settings from Multithreaded DLL (MD/MDd) to Multithreaded (MT/MTd) fixed the problem (apparently using MD requires MFC dlls which confuses XSI).

Well, using MT means that you’re statically linking to the VS2008 runtime libraries on your development machine. If you use MD then you are dynamically linking and so the dll’s for the VS2008 runtime libraries have to be present on your target machine. You can install them on your target machine using the redistributable which you can download from microsoft or find in your VS2008 installation directory on your development machine. The redistributable has to be the correct version of Visual Studio and the correct 32 or 64 version but you can install as many of them as you want on a machine.

In general static linking of runtimes is OK and will make it easier to distribute your result to other machines. It will make the dll or exe larger though. Also occasionally if you produce a dll which is statically linked to one version of the runtimes and your dll is called by a program which is linked to a different version of the runtimes it can cause problems.

By the way ianyone gets this kind of error, a great (free) tool to use is Dependency Walker.

It was Dependency Walker that helped track down the problem (missing msvcr80.dll). 

Thanks - I didn’t know the diff between MD/MT was dynamic/static linking - just went with what worked :) It’s strange because this time around I was using VS2008 to compile on the same Vista64 machine that was having trouble loading the plugin.  I’d have thought that with dynamic linking if it compiled on one machine it would run on that same machine.  But like you said, must have something to do with the dll versions expected by XSI.

Well that does sound kind of odd. Maybe it’s still possible that the 64 bit version of the runtime was still not installed on your Vista64 machine even though you had VS2008 there. I believe that Visual Studio still comes only as a 32 bit application so when you compile for 64 bits you’re still “cross-compiling” even though you’re working on a 64 bit machine. Anyway I think you could still try installing the 64 bit VS2008 redistributable on your VS2008 machine and see if that allows the MD version to run, if you’re interested.