I've written a DLL that provides methods for extracting data from a MySQL DB and generating a report using the built-in report viewer in VS 2012. The idea is to use this in a VB6 program. I've gone through the following process:
1) Build the DLL in VS with "register for COM interop" selected
2) Placed the DLL and TLB file in the directory of the VB6 program on another machine
3) Used regasm: "regasm Report.dll /tlb: Report.tlb /codebase" (redundant step if I already have the TLB file generated by VS?)
4) Added the TLB file to project references in VB6
The VB6 program builds and executes okay, but when I got to run my report I just get "Automation error: the system cannot find the file specified".
I've gone through the above process for a trivial DLL according to the instructions given here. This worked fine. I suspect that the references used in my DLL (MySQL.Data and Microsoft.ReportViewer.WinForms) may also need to be registered on the VB6 machine. I've been able to do this with MySQL.Data but not the ReportViewer DLL.
If it makes a difference, the DLL was built on a Windows 7 64 bit machine whereas the VB6 machine runs XP 32-bit.
Thanks in advance.
Turned out the problem was that I needed to set the Copy Local property for Microsoft.ReportViewer.Common and copy the relevant DLL files along with my own DLL. Hope this helps anyone with a similar problem.
Related
I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.
An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.
I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.
Thanks,
Chris
I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.
The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.
Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.
Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
I have a VB.net project that builds and registers a COM library that I can open and use in Excel on my development machine. That machine happens to have 32-bit Excel. On my other machine Excel installed in 64-bit and will not open the library, 429.
Other threads have suggested that the code itself is likely fine, as long as I compile under "Any".
Is that correct? Is code compiled for "any" generally able to run on 32 and 64-bit?
The same threads suggest that the only real problem is the tlb/registration, and point to articles that suggest manually calling regasm to avoid this.
Is this correct?
If so, am I supposed to have two tlb files? Or two COM libs? Or just one?
Ok, it's working. I still don't understand why this solution works, but here it is:
compile the DLL using the "Any CPU" setting
turn OFF COM registration, it doesn't hurt but it will just confuse things later
add two lines to your VS project's post-build:
"%Windir%\Microsoft.NET\Framework\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery32.tlb
"%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery64.tlb
copy the DLL and TLB's to the target machine
determine the bit-ed-ness of the target machine's office:
http://www.howtogeek.com/howto/24259/
run the correct version (32 or 64) of regasm on that machine with the following switch:
FOR 32-BIT OFFICE
c:\windows\microsoft.net\frameworks[version number]\regasm [path to dll] /codebase
FOR 64-BIT OFFICE
c:\windows\microsoft.net\frameworks64[version number]\regasm [path to dll] /codebase
open Excel on the target platform and navigate to the VBA editor's References dialog. Browse… to the location of the files, and select the correct bit-edness version of the TLB for your platform.
And hopefully that works for all of you too!
This solution is far from ideal. For one, Microsoft keeps moving the location of regasm, so there's no simple way to script this. For another, I have no idea idea why I need to call /codebase, but it appears to have something to do with the naming of the files. Finally, this means that all such work will require at least a little manual work on each and every machine you want to run it on, or you'll need to go through the trouble of making an installer!
I have a VB6 app that utilizes a non-activeX DLL (non-registering).
It's declared via the classic Public Declare Function "Function Name" Lib "Library.DLL" syntax.
On my dev machine (XP) it works fine but when I deploy to Vista or Win7 I'm constantly greeted with a Run Time Error 48 - File Not Found for the DLL in question.
I have tried copying that DLL to every directory I can think of including every environment path on the test machine and the app path too.
These are all 32-bit test environments so it's not a SysWow64 issue.
Possibly throwing a wrench into the mix is the fact that the application in question is an Outlook COM Addin.
I managed to install VB6 on Win7 and was able to run a tiny sample app that utilizes this DLL (outside of the Outlook process) so I know it works PROVIDED the DLL is located in App path. If I call App.Path from my DLL when I run it on the test environment it shows, to no surprise, my installation directory however the DLL is there.
I tried turning off UAC. I tried making the App.Path directory permissions open to everyone, still no dice.
According to the details you give, it looks like placing the DLL in the path of standard Add-in locations would help.
I believe the first place a DLL search looks is the directory that the EXE loaded from, so your DLL's App.Path won't be used.
Are you sure that you tried installing this DLL into System32? Into Windows?
Aside from that you should be ble to create a PATH (messy) or an isolation manifest for the calling code (VB6 if I'm following you) that specifies DLL Redirection to a relative path (i.e. a subfolder under the folder with your VB6 code in it).
See Dynamic-Link Library Search Order
You may want to check the DLL's own dependancies. You will get the same error if it couldn't load the DLL in question or some DLL 20 levels deep in the dependancy chain.
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.