Unity problems when my class is called from COM

Jan 4, 2012 at 3:20 PM
Edited Jan 4, 2012 at 4:00 PM


Currently, I'm working in a solution that use Unity as a container for DI. This project contains a class that is visible to COM and expose one method.

When I Instance and use this class directly from a VS project all works fine, and If I use the class from a VS project using COM (CreateObject) it works well too.

Now, I've create a vbs file and I'm triying to create the class and call the method. The first problem was that Unity could not found the assembly Microsoft.Practices.Unity.Configuration that was specified in the type attrib from the Section Tag of the XML coonfiguration file. I've resolved it putting Unity in the CAG and using the full qualified name of the assemby in the type attribute of the tag.

Now, Unity load fine, but It can resolve my dependencies. Looks like It can't find the assemblies specified in the <assembly> tag (but I'm not sure).

I can't see what's happening, and I don't know why my code is working from a .net program and not from a vbs file.

Could someone please help me with this issue?

EDIT:I've confirmed that UNITY is looking for the libraries in the wscript.exe folder, But I don't know how to change this behaviour.


Jan 5, 2012 at 2:35 AM

When you invoke the COM object from vbscript the AppDomain.CurrentDomain.BaseDirectory is going to be the system32 directory since that is where the program is executing (wscript.exe as you mention).  Your .NET assemblies must be resolvable from that directory.  The easiest way to do this would be to add all of the required assemblies to the GAC.  Another approach would be to manually load all assemblies.  You can use Assembly.GetExecutingAssembly().Location to determine where your assembly is located and then enumerate and load all assemblies in that directory (assuming that all dependencies are located in that directory).

Also, Fuslogvw can help troubleshoot these types of binding issues.

Randy Levy
Enterprise Library support engineer

Jan 5, 2012 at 9:46 AM

Thank you very much Randy.