Team,
The following code returns empty/null to myobj, in my classic ASP page while trying to invoke a dll component.
Set myobj = Server.CreateObject("MODULENAME.cCLASSNAME")
This is related to a DLL which is placed alongside this asp page under \Bin. The DLL is an Interop COM dll custom developed by a former colleague and currently there's no access to the code.
The DLL components are appearing in the regEdit under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ which makes me assume it is registered. However when I try to re-register using regsvr32, it shows that it was loaded but couldn't find DLLRegisterServer method. I use regAsm to register the component.
Any alternate approach that can be done here? Am I missing something?
If the file name starts with "Interop" or "AxInterop", it is likely a wrapper to a COM DLL, not the DLL it's self. The COM DLL must be registered on the system and then a dotNet application will use/create that wrapper so you can make calls to it.
What you need to do is find the DLL, not the Interop because you are not using dotNet in Classic ASP. Make sure it is registered on that computer (using regsvr32 without error) and then this should work.
Last note/hint, that dll created by ex-coworker was done in C or VB (not dotNet) right? If done in dotNet, it is not COM and you need to research "How to call a managed DLL from unmanaged code".
Related
I have created a project in VB.NET, and I set "Make assembly COM visible". I have added 1 function to the project and then compiled it with admin rights.
I was under the impression that this is sufficient to make the project a COM exe, to register it and that I could consume it from within VB6.
However, when I try to add the .exe as a reference in VB6, VB6 says that it can't add a reference to the VB.NET .exe file.
What am I missing?
I have noticed that there is another checkbox named "Register for COM interop", but I'm not sure if I really need that.
I had to change the application style from Windows-Forms-App to Class Library.
Afterwards, I could check "Register for COM interop".
After compilation, a TLB would be created.
I could then reference this TLB.
That solved my problem.
I'm trying to get a vbScript to work in an hta.
The vbs works fine when I run it independently, but when I try to use it in the hta, it is unable to load the dll file.
I have tried using regasm / codebase to register the dll but that didn't help either. Using regsvr32 is not an option as it cannot be run as an Administrator on the computers.
I'm using ExecuteGlobal to get the vbs file into the hta but I have also tried making a command that just runs the vbs from hta, but it still failed.
Have I overlooked something trivial?
You can register COM dlls with Regsvr32 (usually, but there are exceptions, like RTF 5 and later control). You can register .NET dlls pretending to be COM dlls with RegAsm. Both require admin access.
*.NET dlls register the core .NET dll as the COM handler, which dispatches the COM call to the .NET component DLL, unlike COM where nothing usually gets in the way.
To register a .NET dll without being admin requiresyou to export as a reg file from RegAsm (non admins can do). Search and replace HKCR with HKCU\Software\Classes. The reg file can then be merged by non admins.
when telling windows to run an hta it will automatically assume 32bit. to get it to work on 64bit systems use %WinDir%\System32\mshta.exe c:\page.hta
some sort of wrapper or launcher is needed to make sure you are running the correct mshta version
I've a COM callable exe file which is referred in .net applications and VB6 applications. This exe can't run directly by double cliking on it. It'll be referred in projects like a dll, it has public methods and properties and can run this exe from a referred application by calling a public method.
Since this is used in multiple applications I need to add this into GAC, when I add it into GAC it goes to a folder like below,
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MY-ASSEMBLY-NAME\v4.0_1.0.0.0__8676d6af9e2465de
is it right? expected behavior? Are you seeing any problem in add-in this exe to GAC and using it from multiple applications?
I have one problem in vb6. I created a .tlb file in VB.net 2005 by adding Com class to project. I built the project, I got .tlb file and .dll files while building project, i selected "Register for Com interop" from project properties and built. It registered autometically and I can use created .tlb file in that PC in Vb6 working fine. if I deploy application to another PC and run I am getting "Error 429 ActiveX Component Can't create object" run time error. What I need to do? Please help me as soon as possible. I can't deploy the application to client due to above error.
one possible solution is to install .net frame work on client pc i never want to install .net framework any other solution will be most appreciatable.
If you've created a DLL in a .NET language (such as VB.NET), the target computer must have the .NET Framework installed in order to use the DLL.
This a hard and fast requirement, irrelevant of how you're utilizing the DLL, whether from a VB 6 application through COM interop or otherwise. It is also a hurdle you'll have to jump over first, before you worry about things like registering COM components, as Uday's answer suggests.
If you don't want a dependency on .NET, you need to use another environment to create the ActiveX DLL; either C++ or VB 6 are possible choices.
One option may be that, while deployment, you need to register that .tlb file in System Registry using regsvr32 command in command-prompt. Generally static libraries does not work until they are registered with System Registry.
You might have seen many programs register components during installation like 'Registering Type Components' or 'Registering COM Components' (for those who do networking especially). Those components are nothing but native COM dlls and tlbs.
so when creating deployment project, add some scripting login to register thode dlls and tlb to System registry using:
regsvr32 <path to tlb/dll>
you have to recursivey call this command for every dll/tlb you want to register with system. For example, if you have 4 dlls and 2 tlbs then you have to call it 6 times providing the path of dll and tlb one at a time.
I'm trying to reference a COM dll in visual studio by using the Browse tab and selecting the DLL. I noticed that if the DLL is registered on the system with regsvr32 I can reference it, but if it's not registered I receive an error selecting the dll file "A reference to 'file.DLL' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
We would like to keep the DLL not registered, so that we have less configuration needed on other development machines and on the development environments.
Is it too much to ask?
Thanks!
you need to register dll. you can set registration in your setup project or create a batch file for all these type of processes.
Note: Don't forget to unregister dll on uninstallation.
You'll need to register the dll because otherwise it would not be able to find the type library.
Adding the dll afterwards as a reference to you project will create the interop.XXXXmethod.dll assembly.
You need to have the COM server registered, period. You could take some measures to automate the process though and to unregister the COM server when it is not needed.
The same applies to daily builds. If you build a COM server and a .NET based client during the build you have to register the server prior to building the client. And you better unregister it as soon as the client is built. Adding these steps to the build sequence is not a problem at all.
You might be able to use Registration Free Com