I have a 64-bit project(which has to be 64-bit as it is an Outlook 2010/64 bit addin) that needs to interface with another Dll of mine, whose job it is to scrape file metadata out of files using the windows Shell32 dll. Now, as you may of guessed, this is posing compatibility problems as I am crossing that 64/32 bit boundary.
I read an article (ok skimmed it, whatever) and from what I understand, it suggested that I use COM as an intermediary and to bridge this gap. So, My question is, can I build a shim DLL in say VB6 (i know, i know) that would act as my com reference and pass the calls on to my 32-bit dll from my 64-bit addin? Can I do this? Has anyone done this? and most importantly, can someone SHOW me how to do this.
Do I create a VB6 COM Dll, reference my .NET assembly and pass all Public functions out via a similar interface, then reference the VB6 dll in my 64-bit addin? is it just that easy?
Thanks for the sanity check..
Andrew
Related
so my question is relatively simple, can I create VB6 application that references a class in a dll, and then substitute that dll for another at runtime?
Now my intial guess is... no chance in VB6.
So my thoughts turned to a VB.net interop dll. Could I do it in here, and then call the interop dll from the VB?
Again, my guess would be no.... but I'd be happy if someone knew differently.
The only thing that I think would actually work would be DI in .Net, but I'm limited to .net 2, or 3.5 at a big push, so I dont know if that is possible.
So for the background....
I have a dll that a specific site uses, but we dont want to ship that out to everyone. Instead, we want to build a clone dll which just has the interfaces setup so that the VB6 build will complete.
When it gets to the site that needs it, they want to replace the dummy dll, and drop in their version instead.
Note: We do use RegFreeCOM when its gets installed, so I do have the manifest files that I could play around with if needed.
Any ideas would be much appreciated.
Nick
Its a COM dll so its not statically linked to the VB6 exe, so long as the clsids and interface ids are the same in the type library for both DLLs, you can swap them around as you see fit. (If its a VB6 dll this is trivial to do with the 'binary compatibility' build option)
You could also use late binding instead and instead of making a reference directly in your VB6 code, you would create an object and then set that object to an instance.
Examples and information:
MVPS
Microsoft
I'm facing problem while reference vb6 dll in .net project. When ever i refer a vb6 dll in .net project the interop dll is created with same version(1.2.0.0). Its creating problem for me as the setup used to deploy the application at client side does not replace the dll if the version is same as before. I want to change the version of the interop dll (created using vb6 dll). I read it cam done using tlbIMP but how to create tlb file for vb6 dll. Or is there is any other way to achieve this.
Thanks
Saurabh
Here's a small batch file we use to create our interop dll so it's strongly named:
sn.exe -i MichiganLTAP.pfx MagicContainerName
tlbimp.exe ourVb6.dll /out:Our.Strongnamed.Interop.dll /asmversion:7.1.0.0 /keycontainer:MagicContainerName /machine:X86 /namespace:Our.Strongnamed /verbose /sysarray
sn.exe -d MagicContainerName
The important switch from your perspective is: /asmversion:7.1.0.0
You should be able to set that to whatever you want. Check out the MSDN Library page for more info on the switches available.
It makes very little sense to make the version number of the interop library different from the version number of the type library that was created by VB6. There is a one-to-one mapping between what's in the interop library vs the code you wrote in VB6. The interop library simply contains IL declarations for the VB6 COM interfaces, there is no actual code. The CLR uses it to quickly generate the RCW for the interface.
Change the type library version number in VB6 with Project + Properties, Make tab, Version number. Major and minor is what counts. Do this only when you make a change in the publicly visible VB6 classes. Doing so is required btw, it avoids DLL Hell.
I need to write a stub module which, when given a PE (DLL/EXE) as input, will determine whether it is a normal Win32 DLL/EXE or COM DLL/EXE. I need to determine this programatically.
Are there any Windows APIs for this purpose?
I suspect that this is something that would be very hard to do with near 100% accuracy. Some thoughts though:
A COM DLL will export functions like DllRegisterServer and DllUnregisterServer. You could use LoadLibrary() to load the Dll, and then GetProcAddress() to check for the presence of these functions. If they're there then its highly likely that its a COM dll.
A plain win32 Dll will export DllMain. You could use the same technique to check for that. If you find it then its very likely that its win32.
I'm not aware of a way to discover if an exe is a COM server. Servers written using ATL often have a registration script embedded in their resource table, but they don't have to. And you don't need to use ATL to write a COM server. Services using "registry-less com" will similarly have an embedded manifest. You could scan the registry (below HKLM/Classes/Software/) to see if the exe is registered, but it may be that the exe is using registry-less com or just hasn't been regisered yet.
Hope that helps.
For traditional COM DLL, you can look for the wellknown exported methods (search on msdn for these methods)
DllGetClassObject
DllRegisterServer
DllUnregisterServer
DllCanUnloadNow
I am not sure about EXE COM servers though because they generally use command line parameters for registration/unregistration and for class object usually calls CoRegisterClassObject when the EXE starts.
Most of the COM servers traditionally also registered in the Registry but you can create registration free servers now.
Are you also looking for a .NET assembly with some COM visible classes?
I am very new to VB.net. I have written these objects in VB6 before. I'm just lost in VB.net, but (kicking and screaming) I have to learn how to do this. I've been googling for hours with only minor steps forward. Can anyone post a link that explains start to finish how to do this?
I have managed to write the class object, What I can not tell is how to register it and where the name1 and name2 in the CreateObject("Name1.Name2") come from.
Regsrv32 will not work. It says "Entry Point not found" and will not register it. Also, I can not drop it into the Assemblies directory. I read something about a regasm command one uses, but I can't seem to make this work either.
Thanks in advance for any assistance.
I am going to assume you are not trying to write a COM DLL but rather a complete project that call various sub assemblies like a VB6 EXE call a ActiveX DLL. If you can be more specific about what you are trying to do it would help me better.
Several points about VB.NET versus VB6.
1) For .NET only projects there is no registration. If a EXE or DLL references another .NET DLL the only requirement is that the DLLs be present in the parent's directory.
2) You can do a COM style registration for .NET apps only by registering the .NET assembly in the GAC. However there are several requirements for doing this. Do a search on the .NET GAC and it will give you the scoop on how to do this.
3) You can setup the .NET assembly to use COM in which case it will operate by the rules of COM including registration with regsvr.
You will find for .NET only project that #2, or #3 only come in rare instances. #1 will apply for 90% of your DLL assemblies. Of This is dependent on your project.
A common use for CreateObject is allow for plug-ins or installable libraries. .NET handles this through the Reflection API. With the reflection API you can look in a directory, go through each .NET DLL and see what them and create objects from what you find. Search for .NET Reflection to read up on this.
If your project is .NET only then I recommend that you create a Assembly that is reference by both the master assembly and the individual sub assembly that define the interfaces of the objects you are creating. This when you use the reflection API and determine the Object type you can assign it to a variable of that interface and code it noramlly with intellisense and other aids.
if you have old COM ActiveX Controls or DLLs .NET will generate a wrapper class that exposes the ActiveX Objects to .NET. I would spend some time learning how .NET does this. What I do create a dummy project and have .NET reference the ActiveX stuff I need. I then find the wrapper projects and DLL it made and move them into a central area. That why when I work on subsquent projects using the same ActiveX stuff I know where all the wrappers are.
You have to go to your class library properties and select the option "Register for COM interop". This will make your assembly available to COM.
You want to create what's called a COM Callable Wrapper (aka CCW) for your .NET component. This basically entails setting up some COM interfaces with some GUIDs and either enabling "Register for COM Interop" in the project properties (as mentioned) or using regasm.exe.
I put "better" in quotes because it's a qualitative question. I've been writing COM DLLs for a couple of years now and have only recently come upon, and successfully used, the standard DLL with Typelib concept.
Are there any compelling reasons to use COM DLLs instead of DLL+Typelib? Granted, you can't do DCOM with a DLL+Typelib, but is that the only reason?
EDIT I've written COM DLLs in Visual C/C++ 6, Compaq Visual Fortran, Delphi, Visual BASIC 6, ActiveState Perl and a few others. I've written standard DLLs in Visual C/C++ 6, Delphi, Ada and a few others. I've written typelibs for some of my own standard DLLs and also for third party DLLs. The question was originally written in the context of a Delphi DLL+Typelib reimplementation of a VB6 original.
TypeLib's are also important if you ever wish to migrate COM components to managed code in the future. Or have managed code interact with the COM components.
With a typelib there are lots of tools which will automagically translate your COM signatures into .Net interfaces and types. This can be done by hand but with a large project it's certainly a huge time saver.
It really depends on the clients of the component I would think.