Deployment of a .NET COM-visible class targetted at VBScript - best build practices?

Herman

Well-known member
Joined
Oct 18, 2011
Messages
883
Location
Montreal, QC, CA
Programming Experience
10+
I am having a small problem I remember having when I first switched to .net from VB6. I had a lot of programs then that used some shared libraries I wrote in VB6 and VBScript, and eventually I had to upgrade these libraries to .net for new projects, all the while keeping them backward compatible with the original code. The problem arose with deploying those .net written COM libraries. It's always kind of hit and miss. Most times, if the target application is compiled, everything works just peachy with a regasm post-install. But VERY often instanciating the COM object from a VBScript (via wscript.createobject()) is impossible right up until I manually create a new COM+ server application in the Component Services panel, and add my component, then reboot. I seem to have narrowed my problem to a build profile issue. I am developing on a x64 machine and building for x86, but somehow the 32-bits libraries (while they register and work fine when referenced) won't load through a VBscript right after install without some hacking.

What are the best practice in terms of build targets (AnyCPU vs x86/64) and options, for best compatibility with legacy COM apps?
 
Back
Top