I created a wrapper class to load CLR4(.net) into CLR2(vb6). It works, sort of.
I compile my program in .net(4.0) and run a batch file to create a .tlb. I refrence the .tlb from my vb6 program and everything is awesome.
When I change the wrapper and redo the above process, vb6 will not see the new .tlb, it still uses the old one.
...Anything?
Try to un-register the old tlb before deploying the new one. Open a cmd shell and type "regsvr32 /u mytlb.tlb", then deploy the new, and run regsvr32 again without the /u switch.
see https://technet.microsoft.com/en-us/library/bb490985.aspx for additional information.
We have a similiar situation here at work ( a vb6 app hosting .net assemblies).
You want to run REGASM /unregister *.dll. The *.tlb is a product of running REGASM /TLB.
If you have your .net project is registered for COM interop, it should do this for you at ever build.
Related
I am writing a library add-in that uses COM Interop and I am having problems during the clean and rebuild tasks. Visual Studio 2019 is setup to run a external program to debug and runs the .dll registration after the build using regasm to write registry values for the external program. I am using the "Register for COM interop" option.
This is causing problems during the clean/rebuild tasks. If I run a clean/rebuild on the solution I receive Access to the <dllPath> path is denied but if I run a clean on each individual library or run a clean twice (first time gives errors, second time works) things seem to work but leaves the msbuild and VBCSCompiler services hung up after shutting down VS.
However if I unregister the library via the command line using C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm /unregister <dllPath> before building the project, VS throws an error saying that the registry key doesn't exist, VS thinks it needs to unregister the library but the clean works as expected and removes the files in bin/Debug.
To run the registration I have:
<PropertyGroup>
<FrameworkSDKPath>
$(registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework#InstallRoot)
</FrameworkSDKPath>
</PropertyGroup>
<PostBuildEvent>
"$(FrameworkSDKPath)v4.0.30319\regasm" /codebase "$(TargetPath)"
</PostBuildEvent>
If I don't have the post build event it only registers the .dll in the GC but doesn't call the methods decorated with [ComRegisterFunction] and the external program doesn't recognize it. There are a couple of problems besides not deleting the files, if the decorated [ComUnregisterFunction] is not called (VS doesn't call this when cleaning/rebuilding) it will leave artifacts within the external programs registry entries, but it clears the GC entry.
Is there a way to get all this to sync up or do I need to revert to a total manual build process to take care of the registration? Is there an option to tell VS to call the register/unregister functions during the build/clean? Am I missing a step or a configuration setup?
As Simon pointed out, I didn't need to have the "Register for COM interop" option enabled since I was calling RegAsm.exe in the build, disabling this option allowed the files to be updated without any problems.
I built a .net COM dll (debug x64) on one machine. I have it all setup and working there (I can see it in C:\Windows\Micorosft.NET\assembly and OLEVIEWER).
I took the dll to another machine (along with it's .h and .c file generated from MIDL). I register the dll into the GAC by following these steps http://codeingaddiction.blogspot.com/2011/06/how-to-add-strong-name-to-existing-dll_16.html - create key pair, generate MISL, rebuild assembly from MISL with the key, and then adding it to the GAC. It seems to be in the GAC, and I can try searching for it with gacutil /l MyDllName. However, in my client application, when I link against it, at run time when invoking CoCreateInstance I get REGDB_E_CLASSNOTREG (HRESULT). I can't see the dll in C:\Windows\Microsoft.NET/Assembly nor in OLEVIEW.
Have I missed out any steps, or done something wrong?
Thanks
The reason you are getting the error REGDB_E_CLASSNOTREG is because your .net COM DLL is not registered. Any .net assembly needs to be registered for it to be exposed as a com class to the clients. We need to use regasm.exe to register the .net assembly.
I'm using IMB WMQ library to connect to a queue manager.
This is a code I use for a long time, it was created by a friend in VS2005 and I updated to be used in VS2010. It works fine when I use integrated with LoadRunner tool to run some performance scripts. However when I try to debug it returns the following error:
{"Unable to load DLL '**amqxcs2.dll**': The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))"}
This is something related to debugging external DLL, but I didn't find out how to resolve.
I used the following command to register the dll into GAC:
gacutil /I "C:\Program Files\IBM\WebSphere MQ\bin\amqmdnet.dll"
When I tried to add amqxcs2.dll it returns an error:
gacutil /I "C:\Program Files\IBM\WebSphere MQ\bin\amqxcs2.dll"
Failure adding assembly to the cache: The module was expected
to contain an assembly manifest.
I have VS2010 Ultimate running on a Windows Server 2003.
When running the code inside Loadrunner I'm able to put and get messages from the queues, but I'm not able to debug.
There's a similar post here, but it doesn't have a solution.
Why do you think "make sure the library is either where the application needs it to be" is not a solution?
You need to either properly install whatever product your are using on the machine you plan to use it or cheat your way through by copying necessary files to correct places by hand (and figuring "correct places" by hand too. SysInternals tools may be helpful to track what files an application tries to use).
This may be a COM error. The IBM assembly is probably a native dll and so you cannot register it in the GAC, which is for .NET dlls only. Native COM dlls can be registered with Regsvr32. This error can also occur if a native dll has a dependency on another dll that is missing. Also see Understanding Dependencies of a Visual C++ Application which gives information about the Dependency Walker tool that can be used to figure out the depndencies for a native dll.
We have a plugin for IE based on spicIE, the purpose is to connect to some external devices.
To connect to those external devices, another company developed their token & DLLs. We need to have some ActiveX's and DLL's to do authentication by token.
The problem is that the plugin we developed for IE, in final part have a install.bat file, that runs a RegAsm and registers the DLL and after that plugin (or its changes) is viewable in IE.
When running the plugin from IE, our code can not find some DLL, required for authentication (name it x.dll).
Where is registered DLL copied? Is it really copied? I need to have x.dll in the folder where my plugin's DLL exists.
In a nutshell, RegAsm registers your .NET assembly to be COM-viewable. From MSDN: Once a class is registered, any COM client can use it as though the class were a COM class. The class is registered only once, when the assembly is installed. Instances of classes within the assembly cannot be created from COM until they are actually registered.
Without seeing your code in ActiveX, if I understand you correctly, your ActiveX is dependent on some COM DLLs, which is why you are running RegAsm against a .NET DLL.
Run RegDllView to find the details of what is registered and then check if you are indeed instantiating that object which was in fact registered.
Also, if you still have problems, try instantiating the object in VB6/Visual Studio 2010 etc. or equivalent in early binding to see if you have any problems. Examine the error on instantiation.
I'm getting a System.DllNotFoundException for a .dll which is in the same folder as the executable whenever my application attempts to use a function which exists in the DLL. The weird thing is that it is only occurring on one user's PC; it works fine on my dev PC and it works fine on one non-dev PC that I tried it on. Also, there are other DLLs in the folder which are being found and used correctly. The DLL in question is a native library which is referenced by my application via another DLL which is a c# wrapper for the native library.
My initial instinct is that there must be some other library being referenced by this DLL which doesn't exist on the problematic PC, but I cannot imagine what library this PC could be missing that the other non-dev PC has.
So my questions are this: is there a way to determine the dependencies of a given DLL file? Keep in mind that the DLL in question is a native library (i.e. not managed code), and I do not have access to it's source code. And if it turns out no dependency is missing, what else might cause such an issue?
For unmanaged dlls you can use Dependency Walker to find dependencies.
I would suggest using ILSpy to open the dll and view its dependencies first.