|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Problematic CodeBase key usedThe 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" -- 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. 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. -- Show quoteGil "Walter Wang [MSFT]" wrote: > > 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. > > 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? -- Show quoteGil "Gil Lund" wrote: > 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 > > > "Walter Wang [MSFT]" wrote: > > > > > 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. > > > > 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. 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, -- Show quoteGil "Walter Wang [MSFT]" wrote: > 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. > > 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. 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. -- Show quoteGil "Walter Wang [MSFT]" wrote: > 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. > > 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.  |
|||||||||||||||||||||||
Other interesting topics