views:

939

answers:

5

I've been trying to solve this issue for a long time, and nothing seems to work.

I have a COM DLL written in vb6. I add a reference to this DLL in .net, with the 'isolated' and 'copy local' properties set to true on the reference. Apparently this is supposed to enable reg-free com.

But it doesn't work. If I try on another computer, or unregister the DLL with regsvr32, trying to access the DLL throws an exception (essentially saying the desired com class does not exist). The DLL and manifest files are in the same folder as the EXE, but it apparently just totally ignores them.

What am I doing wrong? I've read a ton of scattered articles about this but none of them give me a working solution. I've tinkered with visual studio to no avail. I've tinkered a small amount with make-my-manifest, but it didn't work (even on a test project).

A: 

You should add a reference to your dll through a COM reference (second tab if I am not mistaken) after registering it with regsvr32.

Otherwise, if you want to access the functions in your dll straight (no COM) then you need to export them and reference them using the [DllImport] attribute.

Here is a good reference on how to create a DEF file and export your VB6 functions so they can be used with DllImport.

Otávio Décio
I already have a reference to the COM DLL. The problem is that it's not reg-free. If I install on another machine I have to register the com dll instead of just requiring it to be in the same directory.
Strilanc
Take a look at the link I provided in the answer.
Otávio Décio
MarkJ
+2  A: 

Here's a link that describes using registration free com interop. If you've already done this please post your manifest file. You might have a typo your missing.

Edit

Just a thought might be simpler to just register the dll the first time the app runs on a new machine. Registration free com interopt is only available on Windows XP and newer so if your targeting any dinosaurs out there it won't work.

JoshBerke
+3  A: 

I'm pretty sure that when you reference COM components in this way, the COM component import happens every time you build. That means that the COM component must be registered the traditional way on every machine the project will be built on.

Daniel Pratt
+2  A: 

Here's an excerpt from the Troubleshooting section of an MSDN article on reg-free COM. Apologies if you've already seen it. The good news is you are already part of the way through the steps. It suggests reproducing the problem in Windows Server 2003 (maybe with Virtual PC?) and then the event log should help.

First get ... your client working with a registered server; then unregister the server and verify that your error message is what you expected; and finally... craft and deploy manifest files. This way your troubleshooting efforts ... will be confined to the structure of your manifest files (and the correct embedding of the assembly manifest if you choose to do so).

When troubleshooting registration-free COM issues, the Event Viewer on Windows Server 2003 is your friend... look in the System Event Log for events from the COM server. I don't suggest that you look at the Windows XP Event Log... it will invariably contain a message... which doesn't help identify the problem.

MarkJ
+2  A: 

I was creating and using the com class on a non-ui thread. Apparently Reg-Free com on vb6 DLLs doesn't work in that situation. This test code shows it:

Private Sub RunTest() Handles Button1.Click
    Try
        Dim x As New RegTestProject.RegTestCall
        MsgBox(x.RegTestFunction())
    Catch ex As Exception
        MsgBox(ex.ToString)
    End Try
End Sub

Private Sub RunThreadedTest() Handles Button2.Click
    'fails if reg-free COM is used'
    Dim t As New Threading.Thread(AddressOf RunTest)
    t.Start()
End Sub

When I run this with the DLL registered normally, both tests succeed. If I use reg-free com, the threaded test fails even though the normal test still succeeds. Looks like this is going to be a huge pain to work-around.

Strilanc
Did you ever find out if this was related to the fact that non-ui threads are created as MTA vs. STA threads by default?
Wil P
No, I just worked around the problem by ensuring all the COM calls came from the UI thread. I reported the issue to Microsoft and someone there gave an example manifest fixing the issue for the test dll, but said the issue wasn't high-priority enough to fix.
Strilanc