0

I have a legacy VB6 COM DLL that's included as a reference in a .NET project. My manual build process looks like this:

  1. Build VB6 DLL
  2. Copy VB6 DLL to reference directory
  3. Register VB6 DLL with regsvr32
  4. In the .NET project, remove the old reference
  5. Add reference to new VB6 DLL (browse)
  6. Set the Isolated property of the reference to True
  7. Build .NET solution

I'm in the process of automating this procedure. Steps 4 through 6 are giving me troubles. When I register the new VB6 COM DLL, the old reference in the .NET project is invalid. By looking in the project file, I see this:

<ItemGroup>
  <COMReference Include="DllName">
    <Guid>{65CDCC83-E707-4AA3-8940-FE79F265D570}</Guid>
    <VersionMajor>50</VersionMajor>
    <VersionMinor>0</VersionMinor>
    <Lcid>0</Lcid>
    <WrapperTool>tlbimp</WrapperTool>
    <Isolated>True</Isolated>
    <EmbedInteropTypes>True</EmbedInteropTypes>
  </COMReference>
</ItemGroup>

I believe I need to automatically overwrite the Guid property with the COM's new clsid, and I may need to change the VersionMajor and VersionMinor properties.

Unfortunately these don't seem to be properties of the VB6 COM DLL file. Where can I get this information and/or am I even going down the right path? Is there some tool or option that will automatically do this for me?

Edit

The build error I get if I don't update the reference is error MSB3179.

The actual text of the error message is:

c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(2580,9): error MSB3179: Problem isolating COM reference 'DllName': No registered classes were detected for this component. [path/to/projfile.vbproj]

... where "DllName" is my DLL name and "path/to/projfile.vbproj" is the fully qualified path to the project file with the COM reference.

Scott Whitlock
  • 13,739
  • 7
  • 65
  • 114
  • I don't think you can solve this without using the vb6 binary compatibility option so the guid stays stable. – Hans Passant May 23 '12 at 18:21
  • @HansPassant - Yes, I'm now setting the DLL to binary compatibility and I'm seeing that the Guid and version are staying constant. However, I still get the MSB3179 error when I build the solution. – Scott Whitlock May 23 '12 at 19:26
  • What is the actual text of the error message? – Hans Passant May 23 '12 at 19:40
  • @HansPassant - I added the full text of the error message to the end of my question. Thanks. – Scott Whitlock May 23 '12 at 20:11
  • Sounds like regsvr32.exe didn't do the job. Did you run it from an elevated command prompt so it has access to the registry? – Hans Passant May 23 '12 at 23:22
  • @HansPassant - Yes, I'm running the batch file "as administrator". – Scott Whitlock May 24 '12 at 11:49
  • Well, if all else fails then use SysInternals' ProcMon utility. You can see regsvr32.exe writing the keys and msbuild reading them. Some kind of mismatch or api failure will pop out, assuming you won't drown in the data. – Hans Passant May 24 '12 at 11:53

1 Answers1

0

I've not tried this, but you may be able to achieve this by generating an interop assembly explicitly using tlbimp, rather than letting Visual Studio do it for you by adding a reference to the COM DLL.

Something like:

  1. Build VB6 DLL
  2. Copy VB6 DLL to reference directory
  3. Run tlbimp (e.g. from a batch file) to generate an interop assembly in the reference directory.
  4. The .NET project should have a reference to the interop assembly output at step 3.
  5. Build .NET solution

Using your method, I'm no longer using Registration-Free COM

I don't have much experience with Reg-free COM, but maybe you can manually generate the manifest with a command-line tool instead of setting the Isolated property - e.g. using the MT.EXE tool described in this answer.

Community
  • 1
  • 1
Joe
  • 122,218
  • 32
  • 205
  • 338
  • I've been trying that. It works on the dev machine, but not after publishing (I'm using ClickOnce). Using your method, I'm no longer using Registration-Free COM in my deployment (that's what the Isolated property does). The Isolated property is not available if I generate the interop myself without the COM dll being registered. – Scott Whitlock May 23 '12 at 21:06
  • I think that's the answer, but I can't seem to get it to work. Part of it is a lack of understanding of reg-free COM. I was cheating by letting Visual Studio do all the work for me. :) – Scott Whitlock May 24 '12 at 11:51