I am using pywin32 to register a COM object. The COM object get registered and it is avaialable in the registry editor at Computer\HKEY_CLASSES_ROOT\CLSID{B7B60366-B784-451F-BD6A-E7E733DB4E63}.
The problem is that the path in InProc32 includes only pythoncom37.dll. The only way can make the object work is to rename the inproc folder, so that it searches for LocalServer by default.
I believe several problems in the behavior of this object are connected to it not being ran as inproc, hence I really want to get it to run as inproc.
Any Ideas why this is the case? What can I do to change it?
I wrote a DLL in .NET and I want to access it in VBScript. I don't want to add it to the assembly directory.
Is there a way to point too the DLL and create an instance of it?
I just had to do this myself, my findings were:
Making types visible to COM:
Ensure your class is public, non-static and has a public default constructor i.e. not arguments.
Ensure your method is public, non-static.
Ensure you have the following set on your assembly - typically in AssemblyInfo.cs
[assembly: ComVisible(true)]
After building your DLL, from SDK command line run:
regasm yourdll.dll
This should respond:
Types registered successfully
If you get
RegAsm: warning RA0000: No types were registered
then you need to set ComVisible or have no public, non-static types.
From PowerShell
$a = New-Object -comobject Your.Utils.Logging
$a.WriteError2("Application", "hello",1,1)
From vbs
Set logger = CreateObject("Your.Utils.Logging")
logger.WriteError2 "Application", "hello from vbs",1,1
huseyint's answer was on the money, however, I wanted to add a little to it. Here is some sample code I used for this very issue, perhaps it can speed you along...
// bind a variabe to WScript.Shell
Set WshShell = CreateObject("WScript.Shell")
// define the path to the regasm.exe file
RegAsmPath = "c:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe"
// register the dll
WshShell.run "cmd /c " & RegAsmPath & " c:\temp\cbsecurity.dll /codebase /nologo /s", 0, True
// bind a variable to the dll
Set cbUtil = CreateObject("CBSecurity.Utilities")
I had included an IsAlive method in the dll...
Public Function IsAlive() As Boolean
Return True
End Function
...and could check that it registered correctly using the syntax:
//check if dll is available to your code
msgbox "cbUtil is alive: " & cbUtil.IsAlive
Hope this helps someone...
You can register that .NET dll with regasm utility by specifying /codebase parameter. This parameter is not encouraged to use with unsigned assemblies but it works when you can not put your assembly into GAC.
regasm your.dll /codebase
Please note that you should not change your .dll's path after this operation since it inserts this path into the Windows registry.
In case someone needs to debug/step-into the .Net dll that's called from VBScript only:
On the .Net dll project debug setup screen, set the "start external program" by browsing to the wscript.exe program (located in C:\WINDOWS\system32\wscript.exe).
On the "Command Line Arguments", set the file name and path location of the VBScript file (C:\Test\myTest.vbs). Make sure the vbs file and dll file are in the same location.
Finally, in the .Net project DLL source code just set the break point and hit the "start debug"
Not directly. You'll need a COM Callable Wrapper to any .NET library you'll calling from COM (and hence, VBScript). Therefore, you should either directly create a CCW to the DLL or you can create a CCW for a proxy DLL which provides generic methods to load a .NET DLL and provide methods for you that call the actual methods on the component and return the result. It's really not clean at all. So, in general, the answer is no.
I have inherited a classic ASP application and looking through the code I see a custom COM object reference
Server.CreateObject("DBaseManager.Recordset")
Now, unfortunately looking through to source code there are no .dlls provided so therefore the COM dll must still exist on the live server.
In order to get the code working on my Dev Server I need to get a copy of the dll so I can register it on my Dev server.
Does anyone have any recommendations about how I might be able to find the COM dll that makes the above call?
Thanks and best wishes
Mark
Registry search - under HKEY_CLASSES_ROOT, locate the DBaseManager.Recordset key. Under that key, there should be a CLSID key, with a default value containing a guid.
Now, search for that guid under HKEY_CLASSES_ROOT\CLSID. There should be a subkey under that key called InprocServer32 (if it's an in-process COM library), which in turn should have a default value giving the path to the DLL.
Of course, if the DLL in question is part of a larger product or SDK, merely installing the dll on your dev server may not be sufficient. You may have to locate and install the whole product/SDK in order for it to actually work on another machine.
I have a .NET COM DLL that I want to unregister. I do:
regasm.exe /u ConfigManager.dll
When I look with COM-ole viewer app I still see in type libraries section an entry for ConfigManager( specifies the path to ConfigManager.tlb there). How can I make sure I deregister for good any entries of ConfigManager.dll COM ?
I ask this because I have a nasty error where it seems that ConfigManager clients do not see some types from ConfigManager and want to make sure I deregister and register again ConfigManager
You just need a typelib registration utility. TypeLibs are not specific to .NET so you can find these kinds of ones anywhere.
Here's a simple one:
http://www.vbaccelerator.com/home/vb/utilities/Type_Library_Registration_Utility/VB6_Register_TypeLib_Utility.asp
I prefer to use TlbExp instead of the /tlb option of RegAsm to get a typlelib without automagically registering it. That way I can explicitly register (or unregesiter) the typelib.
I was using an application and it was working perfect. After some months of not using it, I tried to run it and it doesn't work. It shows a message box saying that it cannot instance a COM object.
Do any know how to track errors in COM objects?
You can use ProcessMonitor and try to find the registry key that may be incorrect.
The other option is to use http://www.moduleanalyzer.com, it intercepts CoCreateInstance showing all created COM objects and the return values.
Run Depends tool on COM object DLL to verify it has all the necessary dlls, re-register the COM dll/exe.
Any HRESULTS from debugging/logs? Any changes in apartment models?
You cannot change the apartment type once you've set one. So if the object cannot use one of the models and you try to CoCreate it, it will fail. That's why you never call CoInit from inside DLL main thread.