To be short and to the point, I've built a C# class library that is both COM-Visible and Registered for COM Interop. I've compiled the library, which resulted in the generation of .dll and .tlb files.
I have another machine that's running a VB6 application. So, I copied the .dll and .tlb files over to C:/Windows/system32 folder on the machine. I then registered those files using the following:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm C:\Windows\system32\TestClass.dll /tlb:TestClass.tlb
After the files were registered successfully, I added a project reference to the Test.tlb file from inside my VB6 app, then I tried to invoke a method in my new referenced class like so:
Dim myObject As TestNamespace.TestClass
Set myObject = New TestNamespace.TestClass
MsgBox (myObject.TestMethod())
It doesn't work, and I receive a -2147024894 Automation Error.
I've read that I shouldn't install the dll into a private folder like system32. I should either be registering in the GAC or I should be registering in another location using the "/codebase" option:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm C:\TestClass.dll /tlb:TestClass.tlb /codebase
Is there any reason I shouldn't be using system32? Past devs that have worked on this project have placed assembly files used by this VB6 project into system32 and there haven't seemed to be any issues.
When I register my dll in the system32 location, I get the Automation Error. When I register my dll in another location (i.e. C:/), the method call into my class library from VB6 works as expected. What gives?
I should mention that we will NOT be using the GAC to register any DLL's. That's just the way it is.
Any help is appreciated.
Mike
I haven't had any problems with using regasm for a dll in system32. I always use the /Codebase switch, which puts the location of the tlb in the registry so VB6 won't get confused.
See the MSDN page for more info.
Related
I am working on a project for a Windows library in Ada that must be compiled in a DLL, starting from a .gpr project via GPRBuild. I was able to produce a working DLL for Windows, but now I want to specify the base address for the location of the DLL. At the moment I was able to set the DLL location through the editbin utility but I would like to integrate this step directly in the .gpr file. I have tried to use the Library_Options attribute:
for Library_Options use ("-Wl,--disable-auto-image-base", "-Wl,--image-base=0x20000000");
But it does not seem to help. Is it somehow possible to do what I want directly after compilation or is it really necessary to use an external script?
If any dummy system DLL is placed in my application folder my application loads the dummy DLL and causes an error.
For example: create version.dll in application folder and run the application will display this error:
Testscapi: TESTSCAPI.exe - Bad Image
D:\TESTApplications\TestSCAPI\VERSION.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. Error status 0xc0000020.
OK
Actually version.dll is a system DLL that is overridden by the dummy DLL placed in the application folder.
How to avoid the Delphi application from using the dummy DLL in the application path? Mentioned version.dll is for example, it could be any system DLL...
Thanks in advance.
I have several Visual Studio solutions/projects (some VB, some C#) that all reference a common DLL at design time. This DLL does not have to be copied to the output folder as it is only needed while writing code. Every few months this DLL will be updated to a newer version and all of my projects need to reference the updated version.
What is the best way to handle this?
You have to use a Shared Assembly, shared in GAC (Global Assembly Cache).
Say, you have programmed a class, a piece of software, whatever you have, and you want to make it a shared assembly.
First you make it an assembly by creating a new Class Library Project in VS and transporting all of the code to that project. Don’t build/run it yet! Note that we just transport the code but the assembly (the .DLL file) is not actually made yet, because we have not built the project yet.
Before building the assembly, we have to create/share a key by which the assembly is known, in 2 steps:
a) create the key by executing the cmd below in VS cmd:
sn -k "C:[DirectoryToPlaceKey][KeyName].key" b) share it by adding the attribute below to the AsseblyInfo.vb/cs file in the properties folder of your Class Library project:
In VB.Net:
In C#:
[Assembly: AssemblyKeyFile("C:[directory containing the key file][KeyName].key")] (just copy and paste this into the AssemblyInfo.vb/cs file, but write your directory and file name instead).
Now, you MAKE the assembly by building the project. Just build the project (just press F5 once, at least!). By doing so, the .dll file we need (the assembly) is created in the “bin” folder in the same folder of the project.
Now we share it by Copying the .dll file into the GAC (Global Assembly Cache: it’s where all the assemblies are gathered together. The directory is: “C:\windows\Microsoft.Net\assembly\GAC_MSIL” but you don’t need to know that since the tool below does that for you~) by executing the command below in the VS cmd:
gacutil -I "C:[PathToBinDirectoryInVSProject]\myGAC.dll"
YOU'RE DONE! You may now reference and use the shared assembly from all your applications, and whenever you want to update, just update the shared assembly.
Hope that helps!
You can create nuget resources, and use Nuget Server (Lastest version of teamcity support it) - and all updates w'll be handled by nuget.
Other approach is to create common folder and all project point's to dll in this folder (relativly) in this case you need to udate dll in one folder (after rebuild solution dll'll be updated automaticly)
Ofcourse you can allways install dll in GAC (Global Assembly Cache) this is handled by tool called gacutil.exe (in net is lot of example how to handle it).
I'm using Visual Studio to create C# application which uses SQLite database.
What I want to do is save DLL file in subfolder named 'config'. I've created config folder inside bin/debug folder and copied System.Data.SQLite.dll file into it.
Then I added Reference to my solution using bin/debug/config/Systtem.Data.SQLite.dll file.
The problem is that every time I build solution VS creates new System.Data.SQLite.dll file directly inside bin/debug and when I try to use my application (after deleting bin/debug/System.Data.SQLite.dll) it throws an exception = it cannot load dll from inside config folder...
How can I solve it?
You ought to use the default behavior of loading from the EXE's directory.
If you really don't want to, set Copy Local to false on the reference and load the DLL yourself by calling Assembly.Load.
Note that you'll need to load the DLL before calling any methods that use its types so that the DLL is already loaded when the runtime JITs the methods.
Here's some more info on the topic: http://msdn.microsoft.com/en-us/library/4191fzwb.aspx
Probably a question that has been asked before. Please guide me to any questions that might answer my question...
I have a VB6 .exe that calls a VB6 .dll. I would like to debug the .dll from the .exe code.
Any ideas on how to achieve that? It has been a very long time since I have played with vb6.
Thanks
Open both VB6 projects in one VB6 IDE (a VB Project Group ... creates and uses a file extension of .vbg if I remember correctly). Also, set debugging to Break in Class Module.
You need access to the DLL symbols (usually a PDB file). Make sure that the dll symbols are being generated.
If you open the dll as raw text and go to the end of the file, you can find the path where the pdb file is expected to be located.
I think you have to add the dll project to the to the exe project (File->Add project) to step into the dll code.
Update:
Yes, I think you'll also need to remove the reference to compiled dll.
I'm facing a similar issue and I have been following all the steps you have provided. Nothing is moving. I'm not winning.
I think you have to add the dll project to the to the exe project (File->Add project) to step into the dll code. You'll also need to remove the reference to compiled dll.