Steps for implementing a reg-free .Nett dll in a VB6 program

Hello,

I am desperately trying to get my vb .NET .dll to work registration-free with my vb6 progam. I tried to create a manifest by several different methods (Make my Manifest, UMMM, Side by Side Manifest Creator, mt.exe and by hand), but none worked. If all of these methods fail, I must obviously be doing something wrong, but I can't for the life of me figure out what is going wrong.

I tried asking in other forums and specifically asked if the steps I was taking were even right, as there were some parts I was unsure about and couldn't find any source with a definite answer. Sadly it seems that everybody ignores these questions and skips right to the error message or when you don't quote an error message they just tell you they can't help until you provide an error message.

Because I am so uncertain about many steps, I wanted to make an extra thread specifically about whether the steps I have taken are correct. So for the love of God please don't lock this thread because I am not posting the error messages (has already happened on another forum). I know it is a lot, but as I am trying to single out unexpected errors from me simply misunderstanding the concept, any answer to any of those questions would already be a great step forward. Right now there are just too many variables to consider for me to go on. I assume my problem is with the manifest creation, so if I have done everything right until then, please let me know.

Those are the steps I took in .NET:

- Create new project: New Class Library

- Make it com visible and register for interop services

- Write a simple hello world class (It works when I used it on my own PC, so no errors here)

- Compile

Is this everything I need to do one the VB .NET side YES/NO?????


In vb6

- Create new project and add reference to the .dll

The .dll/.tbl is already listed when I click on add reference in vb6. Should I add the .dll/.tbl listed there while it is still in the VB .NET project directory or copy it to the vb6 project directory and add the .dll manually from there????? Or should I copy the .tbl to the vb6 project folder and then add it?????

- Compile

Then there is the manifest creation. There are a lot of things unclear here:

- Do I need to create a manifest for the vb6 .exe and that is it? I saw some people create manifests for individual .dlls. So is one manifest for the .exe enough YES/NO?????

- I only use one .dll, but I saw some posts while googleing that suggested you might need to add other .dlls for the .NET .dll to work, like mscorelib or mscoree. Also, when I start vb6 in compatibility mode I generates stdole2.tlb in the project folder. Do I need mscorelib, mscoree or any other addition .dlls YES/NO?????. Do I need to include stdole2.tlb in the manifest YES/NO??????

- I tried using Make My Manifest on my vb6 project, but it just created an almost empty manifest with no reference to the .dll. Does that mean I made a mistake? Or is this maybe a known issue YES/NO?????

- Is there any easy step by step guide for creating a manifest??? I have seen some help online with info on the parameters for a manifest, but since I want to excluded an error on my part, I would like to compare it to a guide that is as fool-proof as possible.


Thanks in advance for your help.

So does the vb6 project run as intended in the IDE and from its complied exe with the dll traditionally registered; i.e. before you start trying the make the dll reg-free?
When you do go reg-free you should only require one manifest file for the compiled vb6 exe.

Quote:

---

Originally Posted by Magic Ink

So does the vb6 project run as intended in the IDE and from its complied exe with the dll traditionally registered; i.e. before you start trying the make the dll reg-free?

---

Yes. It runs perfectly fine doing it the traditional way. Compile, copy registered dlls, execute.

Quote:

---

When you do go reg-free you should only require one manifest file for the compiled vb6 exe.

---

OK, so what about the stdole2.tlb vb6 automatically generates when I compile. Does it have to be included in the manifest?
Do I create the manifest for the .tlb or the .dll?
Theoretically when I create a manifest for the stdole2.tlb/.dll an my .tlb/.dll everything should be said an it should work on other PCs as long as the files are all in the same folder?

stdole2.tlb does not need to be referenced in the manifest; like most type libs I expect it is only used at compile time and not at run time.

Your manifest for the vb6 exe could/ should end up looking something like this, which was generated using MMM for inclusion of the vbprndlg.dll when it is placed in the DEPS folder within the App folder;

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity name="My.Name.Computer.Software.MyAppName" processorArchitecture="X86" type="win32" version="6.74.0.39" />
   
  <file name="DEPS\vbprndlg.dll">
    <typelib tlbid="{8620B873-D801-11D2-AC47-00600832A1F6}" version="2.1" flags="" helpdir="" />
    <comClass clsid="{2E2E2172-D819-11D2-AC47-00600832A1F6}" tlbid="{8620B873-D801-11D2-AC47-00600832A1F6}" threadingModel="Apartment" progid="VBPrnDlg.PrinterDlg.1" description="PrinterDlg Class" />
  </file>
 
</assembly>

---

The typelib tlbid string corresponds to that reported in the app's vbp file for the dll, the comClass clsid for the dll was supplied by MMM but I guess it may be tracked down in the Windows registry.

MMM was not designed to support .Net "inter-clop" but instead supports only pure VB6 programming. You can safely rule it out as a solution for your scenario. UMMM is a sort of ripoff of an old version of MMM, and more likely than not is even more limited in the scenarios it handles properly.

I have not use Side By Side Manifest maker myself, but I suspect it is more full-featured than the other two. Still, it may not handle this either.

In "normal use" isolated assemblies involve multiple manifests. Your VB6 program would have an application manifest and your .Net DLL would have its own assembly manifest. MMM (and I assume UMMM) exploit a quirk in the SxS mechansim that allows a single extended application manifest to cover COM and ActiveX dependencies though this is unlikely to work when .Net enters the picture since the gigantic footprint .Net runtime will never "see" that application manifest.


Truth is, when working with .Net this is all meant to be magically handled by that man behind the curtain, i.e. Visual Studio .Net in its myriad versions and editions. The heavy lifting is indeed done by mt.exe, but for all I know VS.Net uses private command line switches.

I will try the same thing soon, so while "googling" for a solution I found a link that may help to understand all the process:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/373e1d1f-e79f-45eb-85f4-115b09e43ec6/regfree-com-with-vb6-exenet-dll?forum=clr

Please let us know if it helped

Quote:

---

Originally Posted by Carlos Rocha

I will try the same thing soon, so while "googling" for a solution I found a link that may help to understand all the process:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/373e1d1f-e79f-45eb-85f4-115b09e43ec6/regfree-com-with-vb6-exenet-dll?forum=clr

Please let us know if it helped

---

After some extremely stressful two weeks I finally have time to dive back into my personal .dll hell. I tried the steps in your link, but I only get "Automation Error". Let's revisit the steps I took:

I generated the most simple .NET dll I could come up with in VS2010:

Imports System.Runtime.InteropServices
<Guid("cfd59ebf-f9c3-4b8a-8c8a-02f8170856f3")> _
Public Class Test
Public Function hello()
Return "hello"
End Function
End Class

I added the GUID just to make sure. I don't know if it is necessary.

Anyway, I made the whole assembly COM visible and checked "register for COM-Interop"

I then compiled.

I created a vb6 Project the creates a new instance of my class and calls the method hello. I included the TestDLL.tlb from the references and then compiled as Test.exe. Then I copied TestDLL.dll and TestDLL.tlb in my app folder.
I tested it and it worked on my PC.

According to the tutorial you provided I typed in

#1b. Generate a manifest for .Net dll:
mt.exe -managedassemblyname:TestDLL.dll -nodependency -out:TestDLL.manifest

and embedded:
mt.exe -manifest TestDLL.manifest -outputresource:TestDLL.dll;#1

The generate manifest looks like this
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="TestDLL"
version="1.0.0.0"
processorArchitecture="msil">
</assemblyIdentity>
<clrClass clsid="{cfd59ebf-f9c3-4b8a-8c8a-02f8170856f3}"
progid="TestDLL.Test"
threadingModel="Both"
name="TestDLL.Test" runtimeVersion="">
</clrClass>
<file name="TestDLL.dll" hashalg="SHA1"></file>
</assembly>

I then created my own .exe.manifest named Test.exe.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">


<assemblyIdentity type="win32"
name="Test.exe"
version="1.0.0.0"
processorArchitecture="msil"
publicKeyToken="0000000000000000"
/>
<dependency>
<dependentAssembly>
<assemblyIdentity name="TestDLL.dll"
version="1.0.0.0"
processorArchitecture="msil"
/>
</dependentAssembly>
</dependency>
</assembly>

Any ideas? Or at least any way I can debug this properly? Sxstrace doesn't help because the manifest is resolved properly. So I'm stuck with a generic "Automation Error" now.

I need this to work. The project I am working on can't continue without it and nobody in my company has any experience with it. So I am desperately experimenting with every single detail to find out what I could be missing, but time is running and it is getting more frustrating by the minute. Please help! :cry:

Success!

Someone else had the same problem and the solution was something I never would have guessed.

Quote:

---

Originally Posted by Hans Passant

Your problem doesn't have anything to do with a manifest, you'll need to fix this one first. The error code is COR_E_NEWER_RUNTIME. In other words, your [ComVisible] class cannot be loaded because it depends on CLR version 4. And the program has already loaded the CLR, version 2 most likely, because another [ComVisible] class asked first. And it asked for version 2.

You'll need an app.exe.config file that forces CLR version 4 to get loaded, even when somebody asks for version 2. It should look like this:

<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>

Give it the same name as the vb6 exe (like "foo.exe.config" to match "foo.exe") and put it in the same directory as the .exe. If you want to use the VB6 IDE to debug your vb6 code that uses this library then you also need vb6.exe.config in c:\program files\microsoft visual studio\vb98

---

http://stackoverflow.com/questions/1...-free-scenario

I thought the runtimeVersion field in TestDLL.manifest was mandatory, but it's good to know you found a way.
Thanks for the feedback