|
From: Sanin <sa...@ho...> - 2008-03-24 21:03:35
|
I have a C++ WiX custom action which happens to be a shim to a .NET assembly. I am now trying to produce a 64-bit version of the installation kit. Questions: 1. Do I have to recompile my shim (i.e. C++ custom action) to 64-bit? 2. If so, here is the problem: - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit. - i tried linking against them while doing the 64-bit compile but a number of symbols is not found. - trying to solve the problem i ventured down the path of recompiling these libs on to 64-bit platform, but hit a roadblock as i do not know how to pass the required compiler #define to the VisualCPP.ClTask in Nant. Questions: 1. How do i pass /D _X64_ via nant script? Based on the log output, the task that gets executed is VisualCpp.Tasks.ClTask.ExecuteTask. now the nant script only has a call to "makeNativeLib". I am quite puzzled about this target. Where is this coming from? And more importantly how do I pass ClTask.options values through it? Obviously a bunch of "standard" defines are already present (see the log) but i am not sure how i can add my defines to it... Hope this makes sense. Thanks. Sanin Here is the log output -- check the: NAnt 0.86 (Build 0.86.2962.0; nightly; 2/10/2008) Copyright (C) 2001-2008 Gerry Shaw http://nant.sourceforge.net Buildfile: file:///C:/Documents and Settings/Administrator/Desktop/wix3-sources/wix.build Target framework: Microsoft .NET Framework 2.0 Base Directory: C:\Documents and Settings\Administrator\Desktop\wix3-sources. Target(s) specified: wcautil [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\wix.include. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\global.include. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\directories.include. [property] Property "dir.root" already exists, and "overwrite" is set to false. [echo] dir.root = C:\Documents and Settings\Administrator\Desktop\wix3-sources\ [property] Property "flavor" already exists, and "overwrite" is set to false. [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0\. [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\VSIP\8.0.60912\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\VSIP\8.0.60912\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\VSIP\8.0.60912\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 [echo] Visual Studio 2005 SDK September 2006 not detected; VS 2005 versions of Sconce and Votive will not be built. [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\VSIP\9.0\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\VSIP\9.0\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\VSIP\9.0\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 [echo] Visual Studio 2008 SDK not detected; VS 2008 versions of Sconce and Votive will not be built. [echo] PlatformSDK directory (dir.platformsdk) = C:\Program Files\Microsoft SDKs\Windows\v6.0\ [echo] VC8 directory (dir.vc8) = c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC [echo] NAnt directory (dir.nant) = c:\SpareDisk\nant-0.86-beta1\bin\ [echo] hhc.exe (tool.hhc) found at C:\Program Files\HTML Help Workshop\hhc.exe [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ambient\appsynup\appsynup.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\dutil\dutil.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ext\ext.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ext\complusextension\complusextension.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ext\msmqextension\msmqextension.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ext\netfxextension\netfxextension.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ext\officeextension\officeextension.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ext\uiextension\uiextension.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ca\serverca\serverca.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ca\serverca\scaexec\scaexec.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ca\serverca\scasched\scasched.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\setup\setup.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\setupbld\setupbld.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\setupexe\setupexe.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\updateexe\updateexe.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\votive\votive2005.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\votive\votive2008.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ca\wcautil\wcautil.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\winterop\winterop.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\src\ca\wixca\wixca.build. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\bin\zip.build. [regex] Setting property 'wixver' to '3.0.3907.0'. [include] Including file C:\Documents and Settings\Administrator\Desktop\wix3-sources\test\wixtests.build. [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTS\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTS\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTS\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTD\. [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTT\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTT\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\VSTT\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTS\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTS\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTS\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTD\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTD\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTD\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 [readregistry] Opening LocalMachine:SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTT\. [readregistry] Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTT\';hive='Microsoft.Win32.RegistryHive[]';: [readregistry] NAnt.Core.BuildException: Registry Path Not Found! - key='SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS\VSTT\';hive='Microsoft.Win32.RegistryHive[]'; [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.LookupRegKey(String key, RegistryHive[] registries) in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 183 [readregistry] at NAnt.Win32.Tasks.ReadRegistryTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Win32\Tasks\ReadRegistryTask.cs:line 145 [readregistry] at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 178 prereqcheck: snskip: [exec] Starting 'c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\sn.exe (-Vl)' in 'C:\Documents and Settings\Administrator\Desktop\wix3-sources' [exec] [exec] Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42 [exec] Copyright (c) Microsoft Corporation. All rights reserved. [exec] [exec] Assembly/Strong Name Users [exec] =========================================== [exec] *,36e4ce08b8ecfb17 All users [delete] Deleting file C:\Documents and Settings\Administrator\Local Settings\Temp\tmpBE.tmp. global.makeDirs: makeDirs: dutil.inc: [copy] Copying 0 files to 'C:\Documents and Settings\Administrator\Desktop\wix3-sources\\Release\debug'. Adding a fileset reference with id 'compileCpp.fileset.sources'. makeNativeLib: checkRequiredArgs: compileCpp: checkRequiredArgs: [cl] 'C:\Documents and Settings\Administrator\Desktop\wix3-sources\Build\debug\precomp.pch' does not exist, recompiling. [cl] PCH out of date, recompiling all sources. [cl] Compiling 1 files to 'C:\Documents and Settings\Administrator\Desktop\wix3-sources\Build\debug'. [cl] Contents of C:\Documents and Settings\Administrator\Local Settings\Temp\tmpBF.tmp. [cl] /c [cl] -FC -GF -GS -Gy -Gz -W3 -Z7 -Zl -Zp8 -RTC1 -Od -DWINVER=0x0500 -DDEVL=1 -D_WINNT -DWINNT=1 -D_NT1X_=100 -DCONDITION_HANDLING=1 -D_MT=1 -DNT_UP=1 -DSTD_CALL -DWIN32 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0500 -D_X86_ -Di386=1 -D_X86_=1 -DDEBUG -D_DEBUG -DDBG=1 -DFPO=0 -YlprecompDefine /I "C:\Program Files\Microsoft SDKs\Windows\v6.0\Include" /I "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\include" /I "C:\Documents and Settings\Administrator\Desktop\wix3-sources\\src\dutil" /I "C:\Documents and Settings\Administrator\Desktop\wix3-sources\\inc" [cl] /Fd"C:\Documents and Settings\Administrator\Desktop\wix3-sources\Build\debug/" [cl] /Fo"C:\Documents and Settings\Administrator\Desktop\wix3-sources\Build\debug/" [cl] /Fp"C:\Documents and Settings\Administrator\Desktop\wix3-sources\Build\debug\precomp.pch" [cl] /Yc"C:\Documents and Settings\Administrator\Desktop\wix3-sources\\src\dutil\precomp.h" [cl] "C:\Documents and Settings\Administrator\Desktop\wix3-sources\Build\debug\precomp.cpp" [cl] [cl] Starting 'cl (@"C:\Documents and Settings\Administrator\Local Settings\Temp\tmpBF.tmp" /nologo)' in 'C:\Documents and Settings\Administrator\Desktop\wix3-sources' [cl] precomp.cpp [cl] c:\program files\microsoft sdks\windows\v6.0\include\winnt.h(81) : fatal error C1189: #error : "No Target Architecture" [cl] BUILD FAILED - 7 non-fatal error(s), 2 warning(s) C:\Documents and Settings\Administrator\Desktop\wix3-sources\global.include(210,8): External Program Failed: cl (return code was 2): NAnt.Core.BuildException: C:\Documents and Settings\Administrator\Desktop\wix3-sources\global.include(210,8): External Program Failed: cl (return code was 2) at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Tasks\ExternalProgramBase.cs:line 418 at NAnt.VisualCpp.Tasks.ClTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.VisualCpp\Tasks\ClTask.cs:line 426 at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 186 at NAnt.Core.TaskContainer.ExecuteChildTasks() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\TaskContainer.cs:line 120 at NAnt.Core.TaskContainer.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\TaskContainer.cs:line 86 at NAnt.Core.Tasks.IfTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Tasks\IfTask.cs:line 363 at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 186 at NAnt.Core.Target.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Target.cs:line 247 at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Project.cs:line 917 at NAnt.Core.Tasks.CallTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Tasks\CallTask.cs:line 211 at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 186 at NAnt.Core.Target.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Target.cs:line 247 at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Project.cs:line 917 at NAnt.Core.Tasks.CallTask.ExecuteTask() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Tasks\CallTask.cs:line 211 at NAnt.Core.Task.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Task.cs:line 186 at NAnt.Core.Target.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Target.cs:line 247 at NAnt.Core.Project.Execute(String targetName, Boolean forceDependencies) in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Project.cs:line 917 at NAnt.Core.Project.Execute() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Project.cs:line 869 at NAnt.Core.Project.Run() in d:\Source\nant-20080210T102007Z\src\NAnt.Core\Project.cs:line 954 Total time: 1.5 seconds. -- View this message in context: http://www.nabble.com/Recompiling-WiX-C%2B%2B-libs-for-64-bit-tp16261155p16261155.html Sent from the wix-users mailing list archive at Nabble.com. |
|
From: Bob A. <bo...@jo...> - 2008-03-25 15:22:56
|
Sanin wrote: > 1. Do I have to recompile my shim (i.e. C++ custom action) to 64-bit? > Probably not. The WiX custom actions are currently 32-bit because we were able to work on 64-bit portions of the file system by disabling file-system redirection when necessary. It's available in wcautil.lib; see the source code in src/ca/wcautil/wcawow64.cpp. > 2. If so, here is the problem: > - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit. > That will be changing soon. The file-system redirection API doesn't solve problems with the registry, so we're adding support for 64-bit custom action builds. That will probably appear in the next couple of weeks. -- sig://boB http://joyofsetup.com/ |
|
From: Sanin <sa...@ho...> - 2008-03-26 13:44:59
|
Bob, thanks for your reply. To make sure let me summarize: Although my CLR loader, which is actually a C++ custom action for WiX, is 32-bit IT WILL be able to load the 64-bit CLR into the installer process and kick off .NET custom actions, which in turn may write files and registry keys without redirection, right? Bob Arnson-6 wrote: > > Sanin wrote: >> 1. Do I have to recompile my shim (i.e. C++ custom action) to 64-bit? >> > > Probably not. The WiX custom actions are currently 32-bit because we > were able to work on 64-bit portions of the file system by disabling > file-system redirection when necessary. It's available in wcautil.lib; > see the source code in src/ca/wcautil/wcawow64.cpp. > >> 2. If so, here is the problem: >> - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit. >> > > That will be changing soon. The file-system redirection API doesn't > solve problems with the registry, so we're adding support for 64-bit > custom action builds. That will probably appear in the next couple of > weeks. > > -- > sig://boB > http://joyofsetup.com/ > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > WiX-users mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Recompiling-WiX-C%2B%2B-libs-for-64-bit-tp16261155p16301157.html Sent from the wix-users mailing list archive at Nabble.com. |
|
From: Sanin <sa...@ho...> - 2008-03-27 18:18:53
|
To answer my own question: NO -- the CLR loaded will be 32-bit and all "downstream" calls into .NET custom actions will run as 32-bit and be victims of registry redirection. Sanin wrote: > > Bob, thanks for your reply. > > To make sure let me summarize: > > Although my CLR loader, which is actually a C++ custom action for WiX, is > 32-bit IT WILL be able to load the 64-bit CLR into the installer process > and kick off .NET custom actions, which in turn may write files and > registry keys without redirection, right? > > > Bob Arnson-6 wrote: >> >> Sanin wrote: >>> 1. Do I have to recompile my shim (i.e. C++ custom action) to 64-bit? >>> >> >> Probably not. The WiX custom actions are currently 32-bit because we >> were able to work on 64-bit portions of the file system by disabling >> file-system redirection when necessary. It's available in wcautil.lib; >> see the source code in src/ca/wcautil/wcawow64.cpp. >> >>> 2. If so, here is the problem: >>> - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit. >>> >> >> That will be changing soon. The file-system redirection API doesn't >> solve problems with the registry, so we're adding support for 64-bit >> custom action builds. That will probably appear in the next couple of >> weeks. >> >> -- >> sig://boB >> http://joyofsetup.com/ >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> WiX-users mailing list >> WiX...@li... >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> > > -- View this message in context: http://www.nabble.com/Recompiling-WiX-C%2B%2B-libs-for-64-bit-tp16261155p16330134.html Sent from the wix-users mailing list archive at Nabble.com. |
|
From: Bob A. <bo...@jo...> - 2008-03-27 14:52:25
|
Sanin wrote: > Although my CLR loader, which is actually a C++ custom action for WiX, is > 32-bit IT WILL be able to load the 64-bit CLR into the installer process and > kick off .NET custom actions, which in turn may write files and registry > keys without redirection, right? > Sorry, I don't know the particulars of what you're trying to do. -- sig://boB http://joyofsetup.com/ |
|
From: Bob A. <bo...@jo...> - 2008-03-29 20:45:10
|
Sanin wrote: > 2. Explicitly pass appropriate flag when using registry classes from .NET so > that automatic redirection does not happen. > Why would you go through the hassle of writing a C++ custom action that loads a .NET assembly to write to the registry when MSI already supports 64-bit registry paths via the Registry table? -- sig://boB http://joyofsetup.com/ |
|
From: Mike D. <mi...@di...> - 2008-03-30 17:49:20
|
>>> Comments inline. -----Original Message----- From: wix...@li... [mailto:wix...@li...] On Behalf Of Bob Arnson Sent: 25 March 2008 15:21 To: Sanin Cc: wix...@li... Subject: Re: [WiX-users] Re compiling WiX C++ libs for 64-bit > 2. If so, here is the problem: > - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit. > That will be changing soon. The file-system redirection API doesn't solve problems with the registry, so we're adding support for 64-bit custom action builds. That will probably appear in the next couple of weeks. >>> You can access 64-bit registry keys from a 32-bit process by adding the KEY_WOW64_64KEY flag to the samDesired parameter of RegCreateKeyEx or RegOpenKeyEx. If required, you can delete a 64-bit key from 32-bit code by calling RegDeleteKeyEx. >>> I'm not sure if this is a better or worse option than having to recompile for 64-bit, but I think it's less work than adding support for picking either 32- or 64-bit versions of the WiX custom action DLLs. Would light simply select the 'correct' version depending on the Package/@Platform? That would probably give wrong results for 32-bit components manipulated by the 64-bit version. Could you write the custom action correctly to manipulate both 32- and 64-bit components from the same deferred action, or would you need two custom actions? Does light schedule two immediate actions if the same WiX scheduling action is required for two different components, one 32-bit and one 64-bit? Are they going to work correctly if they have a limited view of the overall process, with only information about 32-bit components going to the 32-bit deferred action and only 64-bit components to the 64-bit action? Do you even have an Itanium to test on? <g> >>> I think it's better to go with opening the right key for the component. -- Mike Dimmick |
|
From: Bob A. <bo...@jo...> - 2008-03-30 20:06:49
|
Mike Dimmick wrote: > KEY_WOW64_64KEY flag to the samDesired parameter of RegCreateKeyEx or > RegOpenKeyEx. If required, you can delete a 64-bit key from 32-bit code by > calling RegDeleteKeyEx. > The issue isn't Reg*Ex, it's GetNamedSecurityInfo in the SecureObject CA. SE_REGISTRY_WOW64_32KEY isn't sufficient. > recompile for 64-bit, but I think it's less work than adding support for > picking either 32- or 64-bit versions of the WiX custom action DLLs. Would > light simply select the 'correct' version depending on the > Package/@Platform? That would probably give wrong results for 32-bit > components manipulated by the 64-bit version. Could you write the custom > action correctly to manipulate both 32- and 64-bit components from the same > deferred action, or would you need two custom actions? Does light schedule > two immediate actions if the same WiX scheduling action is required for two > different components, one 32-bit and one 64-bit? Are they going to work > correctly if they have a limited view of the overall process, with only > information about 32-bit components going to the 32-bit deferred action and > only 64-bit components to the 64-bit action? Do you even have an Itanium to > test on? <g> > Per-component, one immediate CA can schedule different deferred/rollback CAs based on component bitness and the package platform (to differentiate between x64 and IA64). And no IA64 warming up my office but they're around.<g> -- sig://boB http://joyofsetup.com/ |
|
From: Sanin <sa...@ho...> - 2008-03-28 15:25:49
|
For the risk of beating a dead horse let me try to explain: Fundamentally, I want to be able to write custom actions for WiX in .NET. As we all know WiX at present time cannot call into .NET assemblies. So we set out to create a simple shim in C++ which has the job of loading a .NET CLR and invoking a method of our choosing. This C++ component is a standard WiX C++ custom action linked against wcautil.lib and dutil.lib. This works just fine on 32-bit. Trying to build the same WiX project presents a problem because this C++ custom action is 32-bit and I can't find the way to recompile it to 64-bit due to the fact that wcautil.lib and dutil.lib are only 32-bit. For most scenarios, however, leaving the C++ shim in 32-bit world is not a problem - a 32-bit .NET CLR gets loaded and our .NET code executes just fine. The ONLY problematic situation is if we try to manipulate registry from these .NET custom actions because, running on WOW64, we get redirected to a wrong hive. I see two solutions to this situation: 1. Make WiX .lib files 64-bit and recompile our shim. or 2. Explicitly pass appropriate flag when using registry classes from .NET so that automatic redirection does not happen. Hope this makes it clearer. Bob Arnson-6 wrote: > > Sanin wrote: >> Although my CLR loader, which is actually a C++ custom action for WiX, is >> 32-bit IT WILL be able to load the 64-bit CLR into the installer process >> and >> kick off .NET custom actions, which in turn may write files and registry >> keys without redirection, right? >> > > Sorry, I don't know the particulars of what you're trying to do. > > -- > sig://boB > http://joyofsetup.com/ > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > WiX-users mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Recompiling-WiX-C%2B%2B-libs-for-64-bit-tp16261155p16351027.html Sent from the wix-users mailing list archive at Nabble.com. |
|
From: Sanin <sa...@ho...> - 2008-03-30 00:11:59
|
LOL Just writing registry keys, of course, is not the only thing that happens inside .NET custom actions. Sometimes we have to read a registry key already written and perform a certain action, or write a new key whose value is not that easily derived to be handled by the Registry table. Bob Arnson-6 wrote: > > Sanin wrote: >> 2. Explicitly pass appropriate flag when using registry classes from .NET >> so >> that automatic redirection does not happen. >> > > Why would you go through the hassle of writing a C++ custom action that > loads a .NET assembly to write to the registry when MSI already supports > 64-bit registry paths via the Registry table? > > -- > sig://boB > http://joyofsetup.com/ > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > WiX-users mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Recompiling-WiX-C%2B%2B-libs-for-64-bit-tp16261155p16376741.html Sent from the wix-users mailing list archive at Nabble.com. |
|
From: Mike D. <mi...@di...> - 2008-03-30 16:30:57
|
I would recommend: - Using RegistrySearch to read the existing values of registry values; - Using the RegistryValue element to set new values, using property substitutions to construct the value (the Value attribute is a Formatted data type, so you can use [PropertyName] to substitute the PropertyName property's value); - Using property-type custom actions <CustomAction Property="Name" Value="expression"/> to set the property value to be written to the key; - If you need to manipulate the value read from the registry further, writing a C++ custom action that simply performs the manipulation. Doing it through MSI tables should ensure that Windows Installer correctly detects when a repair is needed. It also means that the registry changes are transactional, i.e. rolled back if there's a problem with the installer. I suspect you're just trying to reuse code that manipulates these registry entries, written for setting them up properly when debugging from the IDE. It's nice to have code reuse. Writing your installer properly should be a higher priority, however. If you must do it in the debugging environment, come up with a way that the debugged code can read the WiX source and make that the master source of the registry information. -- Mike Dimmick -----Original Message----- From: wix...@li... [mailto:wix...@li...] On Behalf Of Sanin Sent: 30 March 2008 00:12 To: wix...@li... Subject: Re: [WiX-users] Re compiling WiX C++ libs for 64-bit LOL Just writing registry keys, of course, is not the only thing that happens inside .NET custom actions. Sometimes we have to read a registry key already written and perform a certain action, or write a new key whose value is not that easily derived to be handled by the Registry table. Bob Arnson-6 wrote: > > Sanin wrote: >> 2. Explicitly pass appropriate flag when using registry classes from .NET >> so >> that automatic redirection does not happen. >> > > Why would you go through the hassle of writing a C++ custom action that > loads a .NET assembly to write to the registry when MSI already supports > 64-bit registry paths via the Registry table? > > -- > sig://boB > http://joyofsetup.com/ > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > WiX-users mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Recompiling-WiX-C%2B%2B-libs-for-64-bit-tp16261155p163 76741.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ WiX-users mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-users |