Problematic CodeBase key used

[Guest]

I'm having a problem with DLL that I'm using through COM interop from VB6.
The DLL has some custom structs that are defined as follows.

<StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Unicode)> _
Public Structure ToolEventStruct
Public ToolEvent_ID As Integer
<MarshalAs(UnmanagedType.BStr)> _
Public EventName As String
Public EventCode As Integer
<MarshalAs(UnmanagedType.BStr)> _
Public EventDescription As String
Public EventType_ID As Integer
Public CreateDate As Date
End Structure

When I create a msi file to install this DLL the following entry is put in
the msi registry table which then gets installed on the target computer. The
problem is that this codeBase value is hard coded to the path of my dev
computer instead of using the install directoy entered by the user when the
msi is run. The COM registry entries (inprocServer,...) for this DLL are
getting the correct codeBase value. Why is this "record" registry keys being
generated and why is the codeBase hosed. This causes my DLL to throw an
expection when the CLR cannot find the DLL and the dev location.

[HKEY_CLASSES_ROOT\Record\{0F94C157-4F0C-3A32-A1F5-1ACC74171A27}\1.0.0.1]
"CodeBase"="file:///C:/Documents and Settings/Gil/My
Documents/LEI/2XX-SparTool/Visual Studio
Projects/290b-LaSHDataAccess-Jerry/112305/LaSHDataAccess/obj/Release/LaSHDataAccess.DLL"
"Class"="LaSHDataAccess.DataAccess+ToolEventStruct"
"Assembly"="LaSHDataAccess, Version=1.0.0.1, Culture=neutral,
PublicKeyToken=475da81253b912e1"

 

[Walter Wang [MSFT]]

Hi Gil,

Thank you for your post!

Based on my understanding, this is an issue of current version of Visual
Studio Setup Project. When you set the register action to "vsdraCOM" for
your .NET assembly, the setup project internally calls "regasm /regfile"
and imports the registry file which incorrectly points to the location on
your dev machine.

To workaround this problem, we have two options:

1) Create a custom action in setup project to manually run "regasm /tlb
/codebase <path_to_your_assembly>" which will correctly write the codebase
in registry.

2) When editing the setup project, we can manually export the registry and
replace the path with a Windows Installer variable (normally TARGETDIR if
you are installing the assembly into your root folder of the installation
directory):

a) regasm /regfile:1.reg /codebase <your_assembly>
b) edit 1.reg, replace all the location to the assembly with
"[TARGETDIR]assembly.dll"
c) in setup project, change to registry view, import 1.reg


Hope this helps. If anything is unclear, please feel free to post here.


Regards,
Walter Wang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks for the response Walter. I will try option #2 since I do not want the
path hard coded into the setup. If I do need to hard code the path how would
I modify the setup program not to prompt the user for the installation
directory?

Does this problem get resolved in VS 2005?

I'll let you know if I cannot get it to work.

 

[Guest]

I tried to rebuild the setup file after performing workaround #2 and I got a
fatal error

AppName: regcap.exe AppVer: 7.10.3077.0 ModName: Iregdll.dll
ModVer: 7.10.3077.0 Offset: 00001593

The build error says
SetupNew.vdproj Unable to create registration information for file named
'LaSHDataAccess.tlb'

I've seen this error before so it might not be from this edit to the setup
file. Can you help me troubleshoot?

--
Gil

Thanks for the response Walter. I will try option #2 since I do not want the
path hard coded into the setup. If I do need to hard code the path how would
I modify the setup program not to prompt the user for the installation
directory?

Does this problem get resolved in VS 2005?

I'll let you know if I cannot get it to work.

--
Gil

Hi Gil,

Thank you for your post!

Based on my understanding, this is an issue of current version of Visual
Studio Setup Project. When you set the register action to "vsdraCOM" for
your .NET assembly, the setup project internally calls "regasm /regfile"
and imports the registry file which incorrectly points to the location on
your dev machine.

To workaround this problem, we have two options:

1) Create a custom action in setup project to manually run "regasm /tlb
/codebase <path_to_your_assembly>" which will correctly write the codebase
in registry.

2) When editing the setup project, we can manually export the registry and
replace the path with a Windows Installer variable (normally TARGETDIR if
you are installing the assembly into your root folder of the installation
directory):

a) regasm /regfile:1.reg /codebase <your_assembly>
b) edit 1.reg, replace all the location to the assembly with
"[TARGETDIR]assembly.dll"
c) in setup project, change to registry view, import 1.reg


Hope this helps. If anything is unclear, please feel free to post here.


Regards,
Walter Wang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Walter Wang [MSFT]]

Hi Gil,

Thank you for your update.

No, this issue still exists in Visual Studio 2005. Sorry for the
inconvenience.

As for the builder error, are you including the type library file and set
its register action to "vsdraCOM" or "vsdraCOMRelativePath"? If this is the
case, please set it to "vsdraDoNotRegister".

Regards,
Walter Wang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Walter, my .tlb files were set to vsdrfCOM so I set them to
vsdraDoNotRegister. Now I created the msi file without an error. When I
view the registry table of the msi with Orca i see that there are two
"record" keys for the same struct. One points to the codeBase from the .reg
file I created. The other points to the dev codeBase like my original
problem. I think this might be happening because I have the setup output as
"Primary output from myDLL" set to vsdrpCOM. Do I want to send this to
vsdrpDoNotRegister along with the type library dependencies? Will this cause
the output to not get registered at all or will the manual registry import
that we did with regasm over ride this setting.

Thx,

 

[Walter Wang [MSFT]]

Hi Gil,

Thank you for your update.

I think you can set its register type to vsdrpDoNotRegister. Setting to
vsdrpCOM will cause the builder internally calls regasm to generate the
registry and import. Based on my test, the manually imported registry will
overwrite the values generated by the setup builder. So, leaving it as
vsdrpCOM will do no harm too.


Regards,
Walter Wang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Walter i have imported the reg files and made all the outputs specified to
vsdrpDoNotRegister and these seems to work. The final test is on a system in
Japan that I will test in two weeks. If you don't hear anything then all is
well.

It would be nice if this bug in VS is fixed soon because this issue has cost
me many hours of grief.

 

[Walter Wang [MSFT]]

Hi Gil,

Thank you for your update.

Please feel free to post here if there's anything I can help.

Regards,
Walter Wang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.