Re: [WiX-users] Features of XmlConfig - can be considered bugs?
Just FYI: the feature request has been filed, # 2544928 -- Yan -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Wednesday, January 28, 2009 7:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Features of XmlConfig - can be considered bugs? Those are all side-effects of using MSXML. It isn't the friendliest at maintaining all the previous whitespace and shaping. A Feature Request seems fine but as long as things work, I don't think a bug is appropriate. -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, January 28, 2009 08:36 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Features of XmlConfig - can be considered bugs? Hello WiX developers, I have been using XmlConfig elements in my installation for some time and I've noticed a number of things which I qualify as minor bugs: 1) When you modify an existent attribute of an existent XML element, it is moved to the end of the element: Before Person Name=John Lastname=Smith Age=35/ After Person Lastname=Smith Age=35 Name=Mary/ 2) When you modify a self-closing element, it removes the space between the last attribute and the closing structure: Before Person Name=John Lastname=Smith Age=35 / After Person Lastname=Smith Age=35 Name=Mary/ 3) When you delete an element, it leaves the empty line: Before Person Name=John Lastname=Smith Age=35 / Person Name=Tony Lastname=Black Age=40 / Person Name=Amy Lastname=White Age=20 / After Person Name=John Lastname=Smith Age=35 / Person Name=Amy Lastname=White Age=20 / Can this be registered as minor bugs? There's nothing vitally important here, just not convenient to diff afterwards... Thanks. -- Yan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where to store SQL Server login credentialsfor uninstall?
Thanks for a hint, Rob! I had something similar in my mind. -- Yan -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Wednesday, January 28, 2009 7:05 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where to store SQL Server login credentialsfor uninstall? DPAPI is your friend. I have bits and pieces of a CustomAction I should finish that encrypts Properties... -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, January 28, 2009 08:23 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Where to store SQL Server login credentials for uninstall? Hello WiX community, This is rather a 'best practice' question. My installation needs MS SQL server credentials to run attach scripts. This info is requested from user. Those values which are necessary during uninstall are usually kept in system registry. But in this case we are storing MS SQL password in plain text. Is there any other way to secure this info, but still have it available during uninstall? I can think only about storing hash at the moment... Thank you. -- Yan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] UNsubscribe
Unsubscribe -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where to store SQL Server login credentialsforuninstall?
Isn't it what the ContinueOnError attribute is there for? I have searched through this mail archive and I can see that people often put ContinueOnError=yes for uninstall SQL strings. This sounds quite logical: don't interrupt the uninstall, and let the admin to manually drop the broken references in SQL Management studio afterwards. -- Yan -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, January 29, 2009 5:34 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where to store SQL Server login credentialsforuninstall? gree...@cox.net wrote: The solution I posted is not without problems. The issue is that the network admin has no way to pass the credentials to the uninstall. Passing them through public properties on the command line is not the safest way to go. The uninstall should be designed in a way that it does not fail when it can't connect to SQL, offfering the administrator a manual way to drop the database or whatever. Right. My point is, though it's possible to disable obvious entry points, it's impossible to prevent them all. Be careful out there.g -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SetupBld and IIs Problem
Dear all,
attached you can find the verbose log and a screenshot of the message box. Full
string of drop down box Use source: is
C:\DOKUME~1\UWE~1.STU\LOKALE~1\Temp\\{CAF30021-1370-494F-B1AE-071885DADBEC}\.
The message box appears at: 09:17:44:437 (related to the log file).
I have clicked Cancel and uninstall goes on without errors (after
09:17:44:437).
I don't understand why this message box only appears in conjunction with
IIsExtensions. All my other installers build on the same way don't show the box
on uninstall.
Additional information:
Windows XP SP3
WiX: 3.0.4909.0
Wxs: see prev. email
Steps: WXS - MSI - setupbld (use setup.exe of WiX-bin-folder) - Exe
(If I install and uninstall by using the MSI (without the setupbld-step) no
problems occur.)
I do not know if attachements are allowed. So here is the critical section of
the log file:
...
MSI (s) (0C!4C) [09:17:43:187]: Resolving source.
MSI (s) (0C!4C) [09:17:43:218]: Using cached product context: User non-assigned
for product: 12003FAC0731F4941BEA708158ADBDCE
MSI (s) (0C!4C) [09:17:43:234]: Using cached product context: User non-assigned
for product: 12003FAC0731F4941BEA708158ADBDCE
MSI (s) (0C!4C) [09:17:43:265]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (0C!4C) [09:17:43:296]: User policy value 'DisableMedia' is 0
MSI (s) (0C!4C) [09:17:43:312]: Machine policy value 'AllowLockdownMedia' is 1
MSI (s) (0C!4C) [09:17:43:343]: SOURCEMGMT: Looking for sourcelist for product
{CAF30021-1370-494F-B1AE-071885DADBEC}
MSI (s) (0C!4C) [09:17:43:359]: Using cached product context: User non-assigned
for product: 12003FAC0731F4941BEA708158ADBDCE
MSI (s) (0C!4C) [09:17:43:421]: SOURCEMGMT: Adding
{CAF30021-1370-494F-B1AE-071885DADBEC}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (0C!4C) [09:17:43:452]: Using cached product context: User non-assigned
for product: 12003FAC0731F4941BEA708158ADBDCE
MSI (s) (0C!4C) [09:17:43:468]: SOURCEMGMT: Now checking product
{CAF30021-1370-494F-B1AE-071885DADBEC}
MSI (s) (0C!4C) [09:17:43:499]: SOURCEMGMT: Attempting to use LastUsedSource
from source list.
MSI (s) (0C!4C) [09:17:43:530]: SOURCEMGMT: Trying source
C:\DOKUME~1\UWE~1.STU\LOKALE~1\Temp\\{CAF30021-1370-494F-B1AE-071885DADBEC}\.
MSI (s) (0C!4C) [09:17:43:546]: Note: 1: 2203 2:
C:\DOKUME~1\UWE~1.STU\LOKALE~1\Temp\{CAF30021-1370-494F-B1AE-071885DADBEC}\IIsInstallProblem.msi
3: -2147287037
MSI (s) (0C!4C) [09:17:43:577]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (0C!4C) [09:17:43:593]: Note: 1: 1706 2: -2147483647 3:
IIsInstallProblem.msi
MSI (s) (0C!4C) [09:17:43:624]: SOURCEMGMT: Processing net source list.
MSI (s) (0C!4C) [09:17:43:655]: SOURCEMGMT: Trying source
C:\DOKUME~1\UWE~1.STU\LOKALE~1\Temp\\{CAF30021-1370-494F-B1AE-071885DADBEC}\.
MSI (s) (0C!4C) [09:17:43:671]: Note: 1: 2203 2:
C:\DOKUME~1\UWE~1.STU\LOKALE~1\Temp\{CAF30021-1370-494F-B1AE-071885DADBEC}\IIsInstallProblem.msi
3: -2147287037
MSI (s) (0C!4C) [09:17:43:702]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (0C!4C) [09:17:43:718]: Note: 1: 1706 2: -2147483647 3:
IIsInstallProblem.msi
MSI (s) (0C!4C) [09:17:43:749]: SOURCEMGMT: Processing media source list.
MSI (s) (0C!4C) [09:17:43:780]: Note: 1: 2203 2: 3: -2147287037
MSI (s) (0C!4C) [09:17:43:796]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (0C!4C) [09:17:43:843]: Note: 1: 1706 2: -2147483647 3:
IIsInstallProblem.msi
MSI (s) (0C!4C) [09:17:43:874]: SOURCEMGMT: Processing URL source list.
MSI (s) (0C!4C) [09:17:43:890]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (0C!4C) [09:17:43:905]: Note: 1: 1706 2: -2147483647 3:
IIsInstallProblem.msi
MSI (s) (0C!4C) [09:17:43:937]: Note: 1: 1706 2: 3: IIsInstallProblem.msi
MSI (c) (4C:B0) [09:17:43:952]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (4C:B0) [09:17:43:968]: User policy value 'DisableMedia' is 0
MSI (c) (4C:B0) [09:17:43:999]: Machine policy value 'AllowLockdownMedia' is 1
MSI (c) (4C:B0) [09:17:44:015]: SOURCEMGMT: Prompting user for a valid source.
MSI (c) (4C:B0) [09:17:44:046]: Machine policy value 'DisableBrowse' is 0
MSI (c) (4C:B0) [09:17:44:062]: Machine policy value 'AllowLockdownBrowse' is 1
MSI (c) (4C:B0) [09:17:44:077]: SOURCEMGMT: Browsing is enabled.
MSI (c) (4C:B0) [09:17:44:124]: Font created. Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (4C:B0) [09:17:44:140]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (4C:B0) [09:17:44:155]: SOURCEMGMT: Now checking product
{CAF30021-1370-494F-B1AE-071885DADBEC}
MSI (c) (4C:B0) [09:17:44:187]: SOURCEMGMT: Attempting to use LastUsedSource
from source list.
MSI (c) (4C:B0) [09:17:44:202]: Note: 1: 1706 2: 3: IIsInstallProblem.msi
MSI (c) (4C:B0) [09:17:44:234]: SOURCEMGMT: Processing net source list.
MSI (c) (4C:B0) [09:17:44:265]: Note: 1: 1706 2: 3: IIsInstallProblem.msi
MSI (c) (4C:B0) [09:17:44:280]: SOURCEMGMT: Processing media
[WiX-users] Language localization question
Hello all Right now I am using a language bootstrapper and applying localization transforms using msiexec /i msiname /qf TRANSFORMS=:de_DE.mst according to the language selection the user has made. I want to get rid of the language bootstrapper and want the MSI auto detect User locale on the target system and load the respective MSI that is available on the CD.Would building separate MSIs for different languages help me achieve that? - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/Language-localization-question-tp2237853p2237853.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] wix ui
hi i am new to WIX, i am reffering Wix Totorial meant for 2.0 colud you please tell me how go Wix ui step by step creating dialog and ui liberaray. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] installing Outlook Primary Interop Assemblies
cheers rob, got it sorted in the end FYI this is my custom protocol handler: RegistryKey Id=regCaseFlowKey Action=createAndRemoveOnUninstall Key=nameofmyprotocol Root=HKCR RegistryValue Id=DefaultValue Action=write Value=URL:my custom protocoll Type=string / RegistryValue Id=uriProtocol Action=write Name=URL Protocol Value= Type=string / RegistryKey Id=DefaultIcon Action=createAndRemoveOnUninstall Key=DefaultIcon RegistryValue Id=DefaultIconValue Action=write Value=myLauncher.exe Type=string / /RegistryKey RegistryKey Id=regShell Action=createAndRemoveOnUninstall Key=shell RegistryKey Id=regShellOpen Action=createAndRemoveOnUninstall Key=open RegistryKey Id=regShellOpenCommand Action=createAndRemoveOnUninstall Key=command RegistryValue Id=DefaultPathValue Action=write Value='[INSTALLLOCATION]myLauncher.exe %1' Type=string / /RegistryKey /RegistryKey /RegistryKey /RegistryKey Rob Mensching-2 wrote: RegistryKey is the parent of RegistryValue. Or you can just list a bunch of RegistryValue elements out flat. Both ways work. -Original Message- From: Barry Larkin [mailto:barrylar...@gmail.com] Sent: Tuesday, January 20, 2009 03:33 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] installing Outlook Primary Interop Assemblies hi guys, thanks for that, we will look into the setupbld options for bootstrapping yes the protocol handler is just registry keys, i couldnt find a clean example of creating registry keys within registry keys int the tutorial. cheers, barry Re: [WiX-users] installing Outlook Primary Interop Assemblies From: Rob Mensching rob.mensch...@mi... - 2009-01-15 15:57 1. That's exactly what setupbld was designed for. It doesn't support many more scenarios than that today. In WiX v3.5 burn will be much more powerful. 2. Isn't a protocol handler just a set of registry keys? You just use the RegistryKey/RegistryValue elements to write the keys based on MSDN, right? -Original Message- From: Rainer Stropek [mailto:rai...@so...] Sent: Wednesday, January 14, 2009 23:32 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] installing Outlook Primary Interop Assemblies Hi Barry! I had a similar problem with the Outlook PIA (in my case version 2007). I solved it by building a bootstrapper that firstly installs the PIA and then our application. It works fine! Here is how you can do it: 1. Get the Office PIA Redistributable (http://www.microsoft.com/downloads/details.aspx?familyid=59DAEBAA-BED4-4282 -A28C-B864D8BFA513displaylang=en) 2. Extract the o2007PIA.msi file 3. Create the msi file for you app 4. Create the bootstrapper (e.g. in a post-build event): c:\Program Files (x86)\Windows Installer XML v3\bin\setupbld.exe -out $(TargetDir)MyInstaller.exe -mcs $(ProjectDir)Chained_Msi\o2007pia.msi -mcs $(TargetPath) -setup c:\Program Files (x86)\Windows Installer XML v3\bin\setup.exe -title MyApp If Office PIA is not available on the computer on which you install the resulting exe, it will be installed. If it is already there the Office Redist will note that and do nothing. Unfortunately I cannot help with the custom protocol handler, sorry. Hope this helps. Kind regards, Rainer. On Wed, Jan 14, 2009 at 4:37 PM, Barry Larkin barrylar...@gmail.com wrote: Hi There, I am looking into using WIX instead of the standard windows setup and deployment project for the deployment of a solution to one of our clients in work. (The appication interacts with outlook using the outlook interop assemblies and is written in c# VS.NET 2005). I have read through the tutorial and I have installed WIX 3. the application i want to install will need to 1. check for the .net framework and install if version not present. 2. check for office 2003/xp PIA assemblies and install of not present 3. add a custom protol handler to the registry Can anyone point me in the right direction for information on creating some kind of bootstrap installer for .net and the PIA asssemblies. Also i am having some difficulties with creating nested registry entries. i cannot seem to get the correct syntax for creating registry keys within registry keys my application needs to define a custom protocol handler in the registry: http://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/aa767914%28VS.85%29.aspx if anyone could show me how to create these registry enties using wix i would be very grateful! Kind regards, Barry -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
[WiX-users] Checkbox in Window
HI, When I set a property to true or false and set it to a check Box it is taking true. If I retrieve the value for the property the value is 0 if false and 1 if true. I'm writing a Config file based on the property. If I'm setting the value in the Config it is stored as 0 or 1 and not false or true. Please help me in this ASAP. Thanks Thangaraj Natarajan Associate Consultant.GWMT (CAI) -- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to Merrill Lynch are references to any company in the Merrill Lynch Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DISABLEROLLBACK not working
I think this may be a bug in the Wix toolkit (not sure how). We have several installers that are based on the original beta-exit build of Wix 3.0. Most seem to be exhibiting this behavior. We haven't been able to identify a common thread between the different installers, except that this problem did not occur until we upgraded to the more recent Wix build. Can someone help confirm this is a known issue, or at least provide insight as to where to start looking for answers? Thanks! John Morris | Software Architect | SoftPro -Original Message- From: Morris, John - Raleigh [mailto:john.mor...@softprocorp.com] Sent: Tuesday, January 27, 2009 2:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] DISABLEROLLBACK not working Anyone? :-) John Morris | Software Architect | SoftPro -Original Message- From: Morris, John - Raleigh [mailto:john.mor...@softprocorp.com] Sent: Wednesday, January 21, 2009 8:13 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] DISABLEROLLBACK not working Has anyone seen this symtom before? Here is the scenario: I am trouble shooting a failing install. In the debug process, I run the install with DISABLEROLLBACK=1. When the failure happens, it is suppose to NOT rollback. That way, I can figure out what isn't right. This has worked before. For some reason, I am seeing this method not work on some machines. When I attempt this process, the install is always rolling back. And ideas? Thanks, John -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SetupBld and IIs Problem
Dear all, after some research I found a workaround: I do wrap my msi to an exe file with setupbld now by using the command line option -msuc (c added). c means enable msi caching. So the whole msi gets cached in Windows\Installer. On uninstall the msi file will be found by MSI and the message box: The feature you are trying to use is on a network resource that is unavailable. Click OK to try again, or enter an alternate path to a folder containing the installation package 'IIsInstallerProblem.msi' in the box below. doesn't appear. I don't know if this is ok. What's your opinion? I don't know why I need the switch in this case (reference to IIsExtensions) but in the other cases (without IIsExtensions) not. (Resolving source between -Action ended 09:17:40: CommitMetabaseTransaction and -Action start 09:18:35: ConfigureIIsExec.) Many thanks to Bob, he gave me a good starting point (Check a verbose log to see what resource MSI is looking for from the original database). Kind regards, Uwe -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to break up a large installer - transforms, etc?
On Wed, Jan 28, 2009 at 8:35 PM, Bob Arnson b...@joyofsetup.com wrote: Jon W wrote: Has anybody succeeded at creating a transform that adds files? That's a patch. So, a patch is an acceptable way to install add-on products? Sounds a bit unorthodox. Should I create 3 msi products and have them all install into the same directory? Much easier if you already have a bootstrapper. Ok, so creating 3 msis that depend upon each other and need to install in the same directory must also be ok. Anybody have another solution? Thanks, Jon -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to break up a large installer - transforms, etc?
1. It is unorthodox but I think what Bob was saying that if you want a transform to transform *and* update files it's called a patch. 2. Bootstrapper (aka: chainer) is pretty much how it's done. -Original Message- From: Jon W [mailto:know...@gmail.com] Sent: Thursday, January 29, 2009 07:59 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] how to break up a large installer - transforms, etc? On Wed, Jan 28, 2009 at 8:35 PM, Bob Arnson b...@joyofsetup.com wrote: Jon W wrote: Has anybody succeeded at creating a transform that adds files? That's a patch. So, a patch is an acceptable way to install add-on products? Sounds a bit unorthodox. Should I create 3 msi products and have them all install into the same directory? Much easier if you already have a bootstrapper. Ok, so creating 3 msis that depend upon each other and need to install in the same directory must also be ok. Anybody have another solution? Thanks, Jon -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SetupBld and IIs Problem
I think this is a bug introduced with the large changes to IIS CA recently to handle UAC/IIS7 better. Can you try an older build and see if the problem reproduces there? If it does repro with older builds then please open a bug with as much information as possible (especially the info below). Thanks. -Original Message- From: Uwe Stump [mailto:uwe.st...@gewi.com] Sent: Thursday, January 29, 2009 04:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] SetupBld and IIs Problem Dear all, after some research I found a workaround: I do wrap my msi to an exe file with setupbld now by using the command line option -msuc (c added). c means enable msi caching. So the whole msi gets cached in Windows\Installer. On uninstall the msi file will be found by MSI and the message box: The feature you are trying to use is on a network resource that is unavailable. Click OK to try again, or enter an alternate path to a folder containing the installation package 'IIsInstallerProblem.msi' in the box below. doesn't appear. I don't know if this is ok. What's your opinion? I don't know why I need the switch in this case (reference to IIsExtensions) but in the other cases (without IIsExtensions) not. (Resolving source between -Action ended 09:17:40: CommitMetabaseTransaction and -Action start 09:18:35: ConfigureIIsExec.) Many thanks to Bob, he gave me a good starting point (Check a verbose log to see what resource MSI is looking for from the original database). Kind regards, Uwe -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Anyone have any suggestions on how to debug this? I have checked the SQL server logs and there is nothing there pertaining to this WiX error. Thank you in advance for your help with this. This is the exact error: Error -2147217900: failed to execute SQL string, error detail: RESTORE DATABASE is terminating abnormally., SQL key: RestoreDB SQL string: RESTORE DATABASE Suite FROM DISK = 'G:\Database\SuiteBlank This is the WiX code. Creating the database works fine. the error happens within the SQL String. Running the SQL string in SQL Query analyzer works as well. Component Id=SuiteDatabaseComponent Guid=d6e96011-3252-4e85-80b5-b1ff64045e88 File Id=DatabaseBackup Name=SuiteBlank.bak Source=..\..\Database\Backups\SuiteBlank.bak / CreateFolder/ !-- installs database -- sql:SqlDatabase Id=db1 Server=[SQLSERVER] Instance=[SQLINSTANCE] Database=Suite CreateOnInstall=yes ConfirmOverwrite=yes DropOnUninstall=no User=SQLUser !-- define where the database files are saved -- sql:SqlFileSpec Id=mdf Name=Suite_Data Filename=[DATABASEDIR]Suite_Data.mdf Size=2MB GrowthSize=2MB/ sql:SqlLogFileSpec Id=ldf Name=Suite_Log Filename=[DATABASEDIR]Suite_Log.ldf/ /sql:SqlDatabase sql:SqlString Id='RestoreDB' SqlDb='db1' ContinueOnError='no' ExecuteOnInstall='yes' SQL=RESTORE DATABASE Suite FROM DISK = '[DATABASEDIR]SuiteBlank.bak' WITH MOVE 'Suite_Data' TO '[DATABASEDIR]Suite_Data.mdf', MOVE 'Suite_Log' TO '[DATABASEDIR]Suite_Log.ldf',REPLACE/ /Component Eric -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Wednesday, January 28, 2009 9:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 Is it possible the Sql Database is locked after it creates it? The .mdf and .ldf file DO get created before the .msi is finished, but maybe because the .msi isn't complete the files are locked? Just a thought. If this is the case is there a way around this? TO create the blanks sql Database, unlock it, then run the restore script? Eric Latendresse -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Wednesday, January 28, 2009 8:59 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 Still getting the error and no way to debug? Are there any other options? This way of restoring a database SHOULD work, right? Eric -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Tuesday, January 27, 2009 8:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 Yes, The sql server is local. It creates the blank database correctly and I can see the .mdf and .ldf files at the time of the error. The backup file is there as well. The problem must be with the restore script. I can run the script manually and it works fine. Is there anything that would cause WiX to read the sqlstring wrong? Maybe the single quotes aren't coming through as they should? Is there a WiX log or a way to add one so that I can get a more detailed message? Eric -Original Message- From: David Reed [mailto:david.r...@microsoft.com] Sent: Monday, January 26, 2009 3:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 That's often a 404-equivalent. There's usually more info in the server error log. Error -2147217900 Cannot open backup device 'incorrect_path_2_file.bak'. Device error or device off-line. See the SQL Server error log for more details. Make sure the SQL Server process has permissions to that path and that the file actually exists there. You are trying to restore to a local server instance, right? Not a remote server? -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Monday, January 26, 2009 13:21 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 I tried to restore the database from a backup file during the initial install and am getting this error below. Is there WiX log or something where I can get some more info on how to debug this? Below is my code and I think this should work. Anyone have any
[WiX-users] Adding permissions using RegistryPermissions
When I set permission using RegistryPermissions, the existing users are wiped out and the new user and SYSTEM are being added to the permissions. How do I retain all the existing permissions and add just the new user. Also, how to make permissions apply to subkeys also. Component Id=COMPPerm Guid=MyGUID Registry Id=Perm Root=HKLM Key=SOFTWARE\Test Action=write Permission Append=yes Domain=MyDomain User=MyUserName GenericAll=yes / /Registry /Component Thanks -- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to Merrill Lynch are references to any company in the Merrill Lynch Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DISABLEROLLBACK not working
Verbose log file is always where I start. -Original Message- From: Morris, John - Raleigh [mailto:john.mor...@softprocorp.com] Sent: Thursday, January 29, 2009 04:08 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] DISABLEROLLBACK not working I think this may be a bug in the Wix toolkit (not sure how). We have several installers that are based on the original beta-exit build of Wix 3.0. Most seem to be exhibiting this behavior. We haven't been able to identify a common thread between the different installers, except that this problem did not occur until we upgraded to the more recent Wix build. Can someone help confirm this is a known issue, or at least provide insight as to where to start looking for answers? Thanks! John Morris | Software Architect | SoftPro -Original Message- From: Morris, John - Raleigh [mailto:john.mor...@softprocorp.com] Sent: Tuesday, January 27, 2009 2:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] DISABLEROLLBACK not working Anyone? :-) John Morris | Software Architect | SoftPro -Original Message- From: Morris, John - Raleigh [mailto:john.mor...@softprocorp.com] Sent: Wednesday, January 21, 2009 8:13 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] DISABLEROLLBACK not working Has anyone seen this symtom before? Here is the scenario: I am trouble shooting a failing install. In the debug process, I run the install with DISABLEROLLBACK=1. When the failure happens, it is suppose to NOT rollback. That way, I can figure out what isn't right. This has worked before. For some reason, I am seeing this method not work on some machines. When I attempt this process, the install is always rolling back. And ideas? Thanks, John -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding permissions using RegistryPermissions
Util:PermissionEx merges. Not sure about the subkeys... I forget. -Original Message- From: Reddy, Mallikarjun (GWM-CAI) [mailto:mallikarjun_re...@ml.com] Sent: Thursday, January 29, 2009 08:26 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding permissions using RegistryPermissions When I set permission using RegistryPermissions, the existing users are wiped out and the new user and SYSTEM are being added to the permissions. How do I retain all the existing permissions and add just the new user. Also, how to make permissions apply to subkeys also. Component Id=COMPPerm Guid=MyGUID Registry Id=Perm Root=HKLM Key=SOFTWARE\Test Action=write Permission Append=yes Domain=MyDomain User=MyUserName GenericAll=yes / /Registry /Component Thanks -- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to Merrill Lynch are references to any company in the Merrill Lynch Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Secur ities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Not much that is helpful. When I've had really hard SQL issues, I've always used the SQL profiler to dig through all the calls and find the one that is failing. Note: I have seen successful attaches of database files but never tried to do a restore from backup. I always have issues restoring from backup. -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Thursday, January 29, 2009 08:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3 Anyone have any suggestions on how to debug this? I have checked the SQL server logs and there is nothing there pertaining to this WiX error. Thank you in advance for your help with this. This is the exact error: Error -2147217900: failed to execute SQL string, error detail: RESTORE DATABASE is terminating abnormally., SQL key: RestoreDB SQL string: RESTORE DATABASE Suite FROM DISK = 'G:\Database\SuiteBlank This is the WiX code. Creating the database works fine. the error happens within the SQL String. Running the SQL string in SQL Query analyzer works as well. Component Id=SuiteDatabaseComponent Guid=d6e96011-3252-4e85-80b5-b1ff64045e88 File Id=DatabaseBackup Name=SuiteBlank.bak Source=..\..\Database\Backups\SuiteBlank.bak / CreateFolder/ !-- installs database -- sql:SqlDatabase Id=db1 Server=[SQLSERVER] Instance=[SQLINSTANCE] Database=Suite CreateOnInstall=yes ConfirmOverwrite=yes DropOnUninstall=no User=SQLUser !-- define where the database files are saved -- sql:SqlFileSpec Id=mdf Name=Suite_Data Filename=[DATABASEDIR]Suite_Data.mdf Size=2MB GrowthSize=2MB/ sql:SqlLogFileSpec Id=ldf Name=Suite_Log Filename=[DATABASEDIR]Suite_Log.ldf/ /sql:SqlDatabase sql:SqlString Id='RestoreDB' SqlDb='db1' ContinueOnError='no' ExecuteOnInstall='yes' SQL=RESTORE DATABASE Suite FROM DISK = '[DATABASEDIR]SuiteBlank.bak' WITH MOVE 'Suite_Data' TO '[DATABASEDIR]Suite_Data.mdf', MOVE 'Suite_Log' TO '[DATABASEDIR]Suite_Log.ldf',REPLACE/ /Component Eric -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Wednesday, January 28, 2009 9:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 Is it possible the Sql Database is locked after it creates it? The .mdf and .ldf file DO get created before the .msi is finished, but maybe because the .msi isn't complete the files are locked? Just a thought. If this is the case is there a way around this? TO create the blanks sql Database, unlock it, then run the restore script? Eric Latendresse -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Wednesday, January 28, 2009 8:59 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 Still getting the error and no way to debug? Are there any other options? This way of restoring a database SHOULD work, right? Eric -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Tuesday, January 27, 2009 8:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 Yes, The sql server is local. It creates the blank database correctly and I can see the .mdf and .ldf files at the time of the error. The backup file is there as well. The problem must be with the restore script. I can run the script manually and it works fine. Is there anything that would cause WiX to read the sqlstring wrong? Maybe the single quotes aren't coming through as they should? Is there a WiX log or a way to add one so that I can get a more detailed message? Eric -Original Message- From: David Reed [mailto:david.r...@microsoft.com] Sent: Monday, January 26, 2009 3:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 That's often a 404-equivalent. There's usually more info in the server error log. Error -2147217900 Cannot open backup device 'incorrect_path_2_file.bak'. Device error or device off-line. See the SQL Server error log for more details. Make sure the SQL Server process has permissions to that path and that the file actually exists there. You are trying to restore to a
[WiX-users] Checking for IIS and SQL?
This isn't strictly wix related but more a general setup question: Is anyone aware of a robust check to see that SQL Server (2005, express, std, or ent) and IIS (6, 7 + compatibility components) are installed? Any help would be appreciated. Thanks, Peter -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix - integrating Microsoft SSIS package into setup
Hello, is there a way to integrate a Microsoft SQL Server SSIS package into a Wix setup? The setup should install the SSIS package and if possible allow to define some user settings. I'm not sure if I need a Wix custom action to achieve this (maybe somebody already wrote one), or if there is another way to do this. I would appreciate any help on this issue. Thanks Daniel -- View this message in context: http://n2.nabble.com/Wix---integrating-Microsoft-SSIS-package-into-setup-tp2240080p2240080.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Conditionally Creating a group for a IIS User
Hi, I wonder if anybody has an idea how to conditionally add a group to a user that is created during install? I am creating an user to run an IIS web application (well 5 actually). I need to target different versions of IIS, and it turns out I need to add the user to different groups for each version of IIS. Groups are IIS_WRG for IIS6.0, IIS_IUSRS for II7.0, and don't even ask about XP. I have lots of permissions assigned to the user, so I do not want to have to create different users for each version of IIS, and all the associate permissions (10+) that go with the user. Therefore I want to create the user once, and reference many times. The Util:Group must be nested within a Util:User, so I thought of creating a Util:User tag create the user with the same name, and to assign the group in components with conditions for IIS versions. This doesn't work because the order that the user tags are evaluated seem to be arbitrary, and therefore the installer tries to assign a group to a user that does not exist at that point. What would be really handy is a Util:UserRef tag. Is this feasibility possible (i.e. doesn't hit limitations imposed by MSI)? Secondly, is there a more sensible way to do this? I am using the latest WIX 3.0 Thanks in advance, Olly -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding permissions using RegistryPermissions
Rob, thanks for the quick reply. No change in behavior with PermissionEx. xmlns:util='http://schemas.microsoft.com/wix/Util' Registry Id=Perm Root=HKLM Key=SOFTWARE\Test Action=append util:PermissionEx Extended=yes Append=yes Domain=MyDomain User=MyUser GenericAll=yes / /Registry I noticed the subkeys are getting the permissions (even with Permission). Oddly, the subkeys are retaining the existing users/groups and adding the new user with the correct permissions. Any help for the root key would be appreciated. Thanks -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Thursday, January 29, 2009 11:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding permissions using RegistryPermissions Util:PermissionEx merges. Not sure about the subkeys... I forget. -Original Message- From: Reddy, Mallikarjun (GWM-CAI) [mailto:mallikarjun_re...@ml.com] Sent: Thursday, January 29, 2009 08:26 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding permissions using RegistryPermissions When I set permission using RegistryPermissions, the existing users are wiped out and the new user and SYSTEM are being added to the permissions. How do I retain all the existing permissions and add just the new user. Also, how to make permissions apply to subkeys also. Component Id=COMPPerm Guid=MyGUID Registry Id=Perm Root=HKLM Key=SOFTWARE\Test Action=write Permission Append=yes Domain=MyDomain User=MyUserName GenericAll=yes / /Registry /Component Thanks -- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to Merrill Lynch are references to any company in the Merrill Lynch Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Secur ities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
I've done restores successfully this way. Profiler will help determine the
call(s) made and more details about why they failed.
Eric, assuming that you're using integrated security, are you sure that your
installer is running elevated at the point where the restore is attempted?
We've since abandoned BAK files, but here's an example component from the
original RTM AdventureWorks2008 installer from last year:
Component Id=C_AdventureWorks2008Backup
Feature=F_AdventureWorks2008Restore Directory=INSTALLDIR
Guid={15E1D2B7-681F-41D2-8B17-A703317C359B} Win64=$(var.PlatformIs64bit)
KeyPath=yes
ReserveCost Id=RC_AdventureWorks2008Backup RunFromSource=83886080
RunLocal=83886080 /
RegistryKey Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL
Server\100\Samples
RegistryValue Name=InstallAdventureWorks2008YN
Value=[INSTALLADVENTUREWORKS2008YN] Type=string /
/RegistryKey
!--sql:SqlString
Id=SqlString_DropAdventureWorks2008
SqlDb=SqlDb_Master
Sequence=5
ExecuteOnUninstall=yes
ContinueOnError=yes
SQL=
USE master;
IF '[INSTALLADVENTUREWORKS2008YN]' = '1'
BEGIN
IF EXISTS (SELECT * FROM sys.databases WHERE name =
'AdventureWorks2008')
BEGIN
EXECUTE (N'ALTER DATABASE AdventureWorks2008
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;');
EXECUTE (N'DROP DATABASE AdventureWorks2008;');
END
END
/--
sql:SqlString
Id=SqlString_RestoreAdventureWorks2008
SqlDb=SqlDb_Master
Sequence=10
ExecuteOnInstall=yes
ExecuteOnReinstall=yes
ContinueOnError=no
SQL=
IF '[INSTALLADVENTUREWORKS2008YN]' = '1'
BEGIN
USE master;
DECLARE @sql_path nvarchar(256);
SELECT @sql_path = SUBSTRING(physical_name, 1,
CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
FROM master.sys.master_files WHERE database_id = 1 AND file_id
= 1;
IF EXISTS (SELECT * FROM sys.databases WHERE name =
'AdventureWorks2008')
BEGIN
EXECUTE (N'ALTER DATABASE AdventureWorks2008
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;');
EXECUTE (N'DROP DATABASE AdventureWorks2008;');
END
EXECUTE (N'RESTORE DATABASE AdventureWorks2008
FROM DISK =
''[INSTALLDIR]Tools\Samples\AdventureWorks2008.bak''
WITH MOVE ''AdventureWorks2008_Data'' TO N''' +
@sql_path + N'AdventureWorks2008.mdf'',
MOVE ''AdventureWorks2008_Log'' TO
N''' + @sql_path + N'AdventureWorks2008.ldf'',
MOVE ''FileStreamDocuments'' TO
N''' + @sql_path + N'Documents'';');
EXECUTE (N'ALTER DATABASE AdventureWorks2008 SET NEW_BROKER;');
END
/
/Component
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Thursday, January 29, 2009 09:05
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Not much that is helpful. When I've had really hard SQL issues, I've always
used the SQL profiler to dig through all the calls and find the one that is
failing.
Note: I have seen successful attaches of database files but never tried to do a
restore from backup. I always have issues restoring from backup.
-Original Message-
From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com]
Sent: Thursday, January 29, 2009 08:15
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Anyone have any suggestions on how to debug this? I have checked the SQL
server logs and there is nothing there pertaining to this WiX error.
Thank you in advance for your help with this.
This is the exact error:
Error -2147217900: failed to execute SQL string, error detail: RESTORE
DATABASE is terminating abnormally., SQL key: RestoreDB SQL string:
RESTORE DATABASE Suite FROM DISK = 'G:\Database\SuiteBlank
This is the WiX code. Creating the database works fine. the error
happens within the SQL String. Running the SQL string in SQL Query
analyzer works as well.
Component Id=SuiteDatabaseComponent
Guid=d6e96011-3252-4e85-80b5-b1ff64045e88
File Id=DatabaseBackup
Name=SuiteBlank.bak Source=..\..\Database\Backups\SuiteBlank.bak
Re: [WiX-users] Wix - integrating Microsoft SSIS package into setup
Been there, done that a few times. It depends on the package, Daniel. How are the package configurations setup? Environment variables? User registry keys? XML config files? I've used all three, including manipulating the XML files at installation time to persist user selections made during setup. Warning: oob functionality in SSIS doesn't support configuration in HKLM. Are you planning to execute the package immediately post-installation? I've had trouble with environment variables in that scenario, but user registry keys and XML files work fine. -Original Message- From: dschmitz [mailto:daniel.schm...@dealogic.com] Sent: Thursday, January 29, 2009 09:14 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix - integrating Microsoft SSIS package into setup Hello, is there a way to integrate a Microsoft SQL Server SSIS package into a Wix setup? The setup should install the SSIS package and if possible allow to define some user settings. I'm not sure if I need a Wix custom action to achieve this (maybe somebody already wrote one), or if there is another way to do this. I would appreciate any help on this issue. Thanks Daniel -- View this message in context: http://n2.nabble.com/Wix---integrating-Microsoft-SSIS-package-into-setup-tp2240080p2240080.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding permissions using RegistryPermissions
That really surprises me... are you sure you rebuilt and completely uninstalled/installed (i.e. didn't use cached package)? -Original Message- From: Reddy, Mallikarjun (GWM-CAI) [mailto:mallikarjun_re...@ml.com] Sent: Thursday, January 29, 2009 09:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding permissions using RegistryPermissions Rob, thanks for the quick reply. No change in behavior with PermissionEx. xmlns:util='http://schemas.microsoft.com/wix/Util' Registry Id=Perm Root=HKLM Key=SOFTWARE\Test Action=append util:PermissionEx Extended=yes Append=yes Domain=MyDomain User=MyUser GenericAll=yes / /Registry I noticed the subkeys are getting the permissions (even with Permission). Oddly, the subkeys are retaining the existing users/groups and adding the new user with the correct permissions. Any help for the root key would be appreciated. Thanks -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Thursday, January 29, 2009 11:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding permissions using RegistryPermissions Util:PermissionEx merges. Not sure about the subkeys... I forget. -Original Message- From: Reddy, Mallikarjun (GWM-CAI) [mailto:mallikarjun_re...@ml.com] Sent: Thursday, January 29, 2009 08:26 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding permissions using RegistryPermissions When I set permission using RegistryPermissions, the existing users are wiped out and the new user and SYSTEM are being added to the permissions. How do I retain all the existing permissions and add just the new user. Also, how to make permissions apply to subkeys also. Component Id=COMPPerm Guid=MyGUID Registry Id=Perm Root=HKLM Key=SOFTWARE\Test Action=write Permission Append=yes Domain=MyDomain User=MyUserName GenericAll=yes / /Registry /Component Thanks -- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to Merrill Lynch are references to any company in the Merrill Lynch Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Secur ities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your
[WiX-users] Need some help on wix
Hi, We are not able to update a dll present in gac through patch. I am new to wix. I want to know which tag/ attribute in the wix controls this behaviour. What’s the use of ‘AssemblyManifest’ of file and is it some how related to the above behaviour. Any link to the documentation will be appreciated. Thanks, Sandeep -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions from Merge Modules
The custom actions are type 51. The problem is that the merge modules have type 51 CA's using properties they expect me to set. They have it authored properly to be put in the msi before CostInitialize. Instead of going in before CostInitialize which is at sequence 800, they are merged in as sequence 1-12. Even if I author mine to be non overridden and to be sequence 1-12 mine still get placed after the merged ones starting at 13. Since theirs requires mine it isn't working. I did find a workaround that seems to be working. I'm merging multiple msm's but have found that if the one I'm trying to work with is first in the list it gets merged properly and are sequenced in the 700's as they should. Thanks, Lees -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 28, 2009 6:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions from Merge Modules Lisa Wright wrote: I'm having a similar problem with merge modules I am picking up from another team. I can't modify those msm's and I'm being forced to add custom actions to set the system folder properties they use so the files get installed to the correct place. Mine need to be sequenced before theirs because they are using the properties that I set. How is that different from the normal type-51 CAs that mergemod.dll adds? Your formatting didn't come through and I'm having trouble visualizing what you're trying to do. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where to store SQL Server login credentialsforuninstall?
Yan Sklyarenko wrote: Isn't it what the ContinueOnError attribute is there for? Yes or DropOnUninstall=no, as long as you leave a hint for the user somewhere that there are manual steps needed. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Language localization question
Andy2k8 wrote: I want to get rid of the language bootstrapper and want the MSI auto detect User locale on the target system and load the respective MSI that is available on the CD.Would building separate MSIs for different languages help me achieve that? MSI doesn't have a supported auto-selection system. You need code to make it happen. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SetupBld and IIs Problem
Uwe Stump wrote: I do not know if attachements are allowed. So here is the critical section of the log file: ... MSI (s) (0C!4C) [09:17:43:187]: Resolving source. The critical part is right before: That's where MSI identifies the resource it needs the source for. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions from Merge Modules
Lisa Wright wrote: I did find a workaround that seems to be working. I'm merging multiple msm's but have found that if the one I'm trying to work with is first in the list it gets merged properly and are sequenced in the 700's as they should. Unfortunately, mergemod.dll has its own behavior that's opaque to WiX... -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need some help on wix
check: 1. the new dll has a new file assembly version? 2. the linker option -fv is set? On Thu, Jan 29, 2009 at 8:30 PM, Sandeep Prakash sandeep.prak...@microsoft.com wrote: Hi, We are not able to update a dll present in gac through patch. I am new to wix. I want to know which tag/ attribute in the wix controls this behaviour. What's the use of 'AssemblyManifest' of file and is it some how related to the above behaviour. Any link to the documentation will be appreciated. Thanks, Sandeep -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The website root appears blank after configuring existent site - another IIS extension bug?
To whom it may concern,
I have just upgraded to WiX 3.0.4923 and am witnessing the same issue
installing an IIS website on Server 2003. The web site home directory
is not populating, even though the directory is specified correctly in
the wix script, there are no install errors reported, etc.
-Garth
--
Garth Brantley, Senior Development Engineer
DeJarnette Research Systems, Inc
(410) 583-0680 x412
(410) 583-0696 fax
--
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Wednesday, January 28, 2009 12:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] The website root appears blank after
configuring existent site - another IIS extension bug?
Can you open a bug on this issue? I'm a little confused on exactly what
is wrong but if you can capture that in the bug that would help us fix
it. There was recently a very large change to the CA to better support
IIS7 and this could be fallout from that.
-Original Message-
From: Chris Eldredge [mailto:chris.eldre...@gmail.com]
Sent: Wednesday, January 28, 2009 08:58
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] The website root appears blank after
configuring existent site - another IIS extension bug?
Sorry for the all the self-replies but I've been updating as I go.
Build 3.0.4827.0 works for me on Server 2003 and on Vista.
Chris Eldredge wrote:
Actually, scratch that. Neither build works on my Windows Server 2003
/
IIS 6 box, but both work on my Windows Vista / IIS 7 box.
I haven't tracked down why, but looking at the logs,
WriteMetabaseChanges comes before ConfigureIIs on the packages built
on the Vista box, and on the failed builds ConfigureIIsExec comes
before WriteMetabaseChanges.
Chris Eldredge wrote:
I've confirmed this seems to be a bug for me too, in 3.0.4923.0.
Going back to 3.0.4909.0 resolved the issue.
Yan Sklyarenko wrote:
Hello WiX developers,
Sorry, but it seems I found another bug in the IIS extension.
WiX version is 3.0.4917.0. Here is a component definition:
Component DiskId=1 Id=ModifyIISSite5
Guid={YOURGUID-2023-4D19-90D2-EE9101C71E44}
Directory=WebsiteFolder
Permanent=yes
iis:WebSite Id=IISSite5 Description=[IISSITE_NAME]
Directory=WebsiteFolder ConfigureIfExists=yes
iis:WebAddress Id=IISSiteAddress5 Port=[IISSITE_PORT]
/
/iis:WebSite
/Component
The properties IISSITE_NAME and IISSITE_PORT are set with the
command line to 'Default Web Site' and '80' appropriately. When the
product is installed, it appears that the root path is set to blank
('Home Directory' tab, 'Local path' field in IIS console).
'WebsiteFolder' is an Id of a valid Directory table entry.
This used to work before, thus I'm thinking this is a new build
(3.0.4917.0) which causes the problem.
The behavior is reproduced for both IIS5 and IIS6.
Here's a log file snippet (no errors there):
...
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/
ID: 1023
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/
ID: 2021
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/Root ID: 3001
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/
ID: 1015
...
Do you think it's worth registering as a bug?
-- Yan
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-
-
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by:
Re: [WiX-users] The website root appears blank after configuring existent site - another IIS extension bug?
Yep, thanks, we have a bug open on this now. I'll make sure Mike is working on
it tonight.
-Original Message-
From: Brantley, Garth [mailto:gbrant...@dejarnette.com]
Sent: Thursday, January 29, 2009 11:19
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] The website root appears blank after configuring
existent site - another IIS extension bug?
To whom it may concern,
I have just upgraded to WiX 3.0.4923 and am witnessing the same issue
installing an IIS website on Server 2003. The web site home directory
is not populating, even though the directory is specified correctly in
the wix script, there are no install errors reported, etc.
-Garth
--
Garth Brantley, Senior Development Engineer
DeJarnette Research Systems, Inc
(410) 583-0680 x412
(410) 583-0696 fax
--
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Wednesday, January 28, 2009 12:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] The website root appears blank after
configuring existent site - another IIS extension bug?
Can you open a bug on this issue? I'm a little confused on exactly what
is wrong but if you can capture that in the bug that would help us fix
it. There was recently a very large change to the CA to better support
IIS7 and this could be fallout from that.
-Original Message-
From: Chris Eldredge [mailto:chris.eldre...@gmail.com]
Sent: Wednesday, January 28, 2009 08:58
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] The website root appears blank after
configuring existent site - another IIS extension bug?
Sorry for the all the self-replies but I've been updating as I go.
Build 3.0.4827.0 works for me on Server 2003 and on Vista.
Chris Eldredge wrote:
Actually, scratch that. Neither build works on my Windows Server 2003
/
IIS 6 box, but both work on my Windows Vista / IIS 7 box.
I haven't tracked down why, but looking at the logs,
WriteMetabaseChanges comes before ConfigureIIs on the packages built
on the Vista box, and on the failed builds ConfigureIIsExec comes
before WriteMetabaseChanges.
Chris Eldredge wrote:
I've confirmed this seems to be a bug for me too, in 3.0.4923.0.
Going back to 3.0.4909.0 resolved the issue.
Yan Sklyarenko wrote:
Hello WiX developers,
Sorry, but it seems I found another bug in the IIS extension.
WiX version is 3.0.4917.0. Here is a component definition:
Component DiskId=1 Id=ModifyIISSite5
Guid={YOURGUID-2023-4D19-90D2-EE9101C71E44}
Directory=WebsiteFolder
Permanent=yes
iis:WebSite Id=IISSite5 Description=[IISSITE_NAME]
Directory=WebsiteFolder ConfigureIfExists=yes
iis:WebAddress Id=IISSiteAddress5 Port=[IISSITE_PORT]
/
/iis:WebSite
/Component
The properties IISSITE_NAME and IISSITE_PORT are set with the
command line to 'Default Web Site' and '80' appropriately. When the
product is installed, it appears that the root path is set to blank
('Home Directory' tab, 'Local path' field in IIS console).
'WebsiteFolder' is an Id of a valid Directory table entry.
This used to work before, thus I'm thinking this is a new build
(3.0.4917.0) which causes the problem.
The behavior is reproduced for both IIS5 and IIS6.
Here's a log file snippet (no errors there):
...
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/
ID: 1023
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/
ID: 2021
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/Root ID: 3001
WriteMetabaseChanges: Writing Metabase Value Under Key:
/LM/W3SVC/1/
ID: 1015
...
Do you think it's worth registering as a bug?
-- Yan
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-
-
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by:
Re: [WiX-users] Install variable not kept around for uninstall?
So I persisted my property value to the registry and use a registry search
in the property to try to retrieve the value.
My issue is 2 fold. One, the property values aren't being populated from the
registry properly on uninstall. It might be that the keys are deleted
(uninstalled) before they get a chance to be read or it might be they're
just being ignored.
Second, I'm not sure that I have my custom action set up correctly to get
run at uninstall. I need it to get the server name in the expected sql
format (either {dbname}\{instancename} or just {dbname}).
The relevant values are below. Any help would be appreciated, I really can't
figure out what to do at this point.
Thanks,
Peter
It looks something like this:
RegistryKey
Id=CreateKey
Root=HKLM
Action=create
Key=$(var.RegKey)
RegistryValue
Id=SetDatabaseServer
Action=write
Type=string
Name=DatabaseServer
Value=[TMEDATABASESERVER]
/
RegistryValue
Id=SetDatabaseInstance
Action=write
Type=string
Name=DatabaseInstance
Value=[TMEDATABASEINSTANCE]
/
RegistryValue
Id=SetDatabaseName
Action=write
Type=string
Name=DatabaseName
Value=[TMEDATABASENAME]
/
/RegistryKey
And
Property Id=TMEDATABASESERVER Value=(local)
RegistrySearch
Id=RegistrySearchTMEDatabaseServer
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseServer
/
/Property
Property Id=TMEDATABASEINSTANCE Value=SQLEXPRESS
RegistrySearch
Id=RegistrySearchTMEDatabaseInstance
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseInstance
/
/Property
Property Id=TmeDatabase Value=.\SQL /
Property Id=TMEDATABASENAME Value=TME
RegistrySearch
Id=RegistrySearchTMEDatabaseName
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseName
/
/Property
Because I support both named and unnamed instances I have a custom action to
copy the property from TMEDATABASESERVER and TMEDATABASEINSTANCE to
TmeDatabase correctly depending on whether TMEDATABASEINSTANCE is specified.
That looks like:
CustomAction Id=CA_SetDatabaseNoInstance Return=check
Property=TmeDatabase Value=[TMEDATABASESERVER] /
CustomAction Id=CA_SetDatabaseInstance Return=check
Property=TmeDatabase Value=[TMEDATABASESERVER]\[TMEDATABASEINSTANCE] /
InstallExecuteSequence
Custom Action=CA_SetDatabaseInstance
Before=InstallValidate![CDATA[TMEDATABASEINSTANCE]]/Custom
Custom Action=CA_SetDatabaseNoInstance
Before=InstallValidate![CDATA[NOT TMEDATABASEINSTANCE]]/Custom
/InstallExecuteSequence
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Saturday, January 24, 2009 2:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install variable not kept around for uninstall?
If you need properties at uninstall time you need to persist them
somewhere and read them on uninstall, the registry is a common location
for these.
Neil
-Original Message-
From: Peter Oehlert [mailto:poehl...@securityinnovation.com]
Sent: 24 January 2009 19:58
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Install variable not kept around for uninstall?
So my scenario is that I query the user at install time what the
database
server, instance, and name should be. I then use these variables in a
sql:SqlDatabase / element to install a database.
This works great, except that if I change any of the default values at
uninstall it seems to go back to using the default values. I basically
have
a UI Dialog with a Edit control that is tied to a property for each of
these
values. I then dereference the property in the SqlDatabase element. How
do I
persist this value so that when I uninstall it tries to drop the correct
database rather than the default one?
Thanks in advance,
Peter Oehlert
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Re: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Thanks David. I got this to work! Seems that putting USE master; in
front of the script did the trick. Which makes complete sense now. So
sending your code helped! I appreciate your time!
Eric
-Original Message-
From: David Reed [mailto:david.r...@microsoft.com]
Sent: Thursday, January 29, 2009 11:39 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
I've done restores successfully this way. Profiler will help determine
the call(s) made and more details about why they failed.
Eric, assuming that you're using integrated security, are you sure that
your installer is running elevated at the point where the restore is
attempted?
We've since abandoned BAK files, but here's an example component from
the original RTM AdventureWorks2008 installer from last year:
Component Id=C_AdventureWorks2008Backup
Feature=F_AdventureWorks2008Restore Directory=INSTALLDIR
Guid={15E1D2B7-681F-41D2-8B17-A703317C359B}
Win64=$(var.PlatformIs64bit) KeyPath=yes
ReserveCost Id=RC_AdventureWorks2008Backup
RunFromSource=83886080 RunLocal=83886080 /
RegistryKey Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL
Server\100\Samples
RegistryValue Name=InstallAdventureWorks2008YN
Value=[INSTALLADVENTUREWORKS2008YN] Type=string /
/RegistryKey
!--sql:SqlString
Id=SqlString_DropAdventureWorks2008
SqlDb=SqlDb_Master
Sequence=5
ExecuteOnUninstall=yes
ContinueOnError=yes
SQL=
USE master;
IF '[INSTALLADVENTUREWORKS2008YN]' = '1'
BEGIN
IF EXISTS (SELECT * FROM sys.databases WHERE name =
'AdventureWorks2008')
BEGIN
EXECUTE (N'ALTER DATABASE
AdventureWorks2008 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;');
EXECUTE (N'DROP DATABASE
AdventureWorks2008;');
END
END
/--
sql:SqlString
Id=SqlString_RestoreAdventureWorks2008
SqlDb=SqlDb_Master
Sequence=10
ExecuteOnInstall=yes
ExecuteOnReinstall=yes
ContinueOnError=no
SQL=
IF '[INSTALLADVENTUREWORKS2008YN]' = '1'
BEGIN
USE master;
DECLARE @sql_path nvarchar(256);
SELECT @sql_path = SUBSTRING(physical_name, 1,
CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
FROM master.sys.master_files WHERE database_id = 1 AND
file_id = 1;
IF EXISTS (SELECT * FROM sys.databases WHERE name =
'AdventureWorks2008')
BEGIN
EXECUTE (N'ALTER DATABASE
AdventureWorks2008 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;');
EXECUTE (N'DROP DATABASE
AdventureWorks2008;');
END
EXECUTE (N'RESTORE DATABASE AdventureWorks2008
FROM DISK =
''[INSTALLDIR]Tools\Samples\AdventureWorks2008.bak''
WITH MOVE ''AdventureWorks2008_Data'' TO N'''
+ @sql_path + N'AdventureWorks2008.mdf'',
MOVE ''AdventureWorks2008_Log''
TO N''' + @sql_path + N'AdventureWorks2008.ldf'',
MOVE ''FileStreamDocuments''
TO N''' + @sql_path + N'Documents'';');
EXECUTE (N'ALTER DATABASE AdventureWorks2008 SET
NEW_BROKER;');
END
/
/Component
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Thursday, January 29, 2009 09:05
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Not much that is helpful. When I've had really hard SQL issues, I've
always used the SQL profiler to dig through all the calls and find the
one that is failing.
Note: I have seen successful attaches of database files but never tried
to do a restore from backup. I always have issues restoring from
backup.
-Original Message-
From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com]
Sent: Thursday, January 29, 2009 08:15
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Restoring SQL Database with Sqlstring in WiX v3
Anyone have any suggestions on how to debug this? I have checked the SQL
server logs and there is nothing there pertaining to this WiX error.
Thank you in advance for your help with this.
This is the exact error:
Error -2147217900: failed to execute SQL string, error detail: RESTORE
DATABASE is terminating abnormally., SQL key: RestoreDB SQL string:
RESTORE DATABASE Suite FROM
Re: [WiX-users] Need some help on wix
Hi Eitan, I verified the following: 1) Old dll has version 3.8.173.1 and the newer one has 1.8.173.2 . Is it ok to differ at the fourth place only? 2) We have an internal site http://patchman/wipe which takes old msi and the modified dlls as input and gives msp and modified msi as output. I found the following in its build log. Are you suggesting to use -f in the case of light.exe? build.log E:\WIPE September 2008\wix2\candle.exe -out E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf797ff11f2.wixobj E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf797ff11f2.wxs E:\WIPE September 2008\wix2\light.exe -out E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\patch30.pcp E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf797ff11f2.wixobj E:\WIPE September 2008\wix2\msimsp.exe -s patch30.pcp -p MicrosoftEDIPathpatch30.msp -l buildpatch.log -f patchtemp Thanks, Sandeep From: Eitan Behar [ei...@baconao.net] Sent: Friday, January 30, 2009 12:10 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Need some help on wix check: 1. the new dll has a new file assembly version? 2. the linker option -fv is set? On Thu, Jan 29, 2009 at 8:30 PM, Sandeep Prakash sandeep.prak...@microsoft.com wrote: Hi, We are not able to update a dll present in gac through patch. I am new to wix. I want to know which tag/ attribute in the wix controls this behaviour. What's the use of 'AssemblyManifest' of file and is it some how related to the above behaviour. Any link to the documentation will be appreciated. Thanks, Sandeep -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need some help on wix
The fourth place (the revision) is generally ignored by MSI. -- John M. Cooper -Original Message- From: Sandeep Prakash [mailto:sandeep.prak...@microsoft.com] Sent: Thursday, January 29, 2009 2:49 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Need some help on wix Hi Eitan, I verified the following: 1) Old dll has version 3.8.173.1 and the newer one has 1.8.173.2 . Is it ok to differ at the fourth place only? 2) We have an internal site http://patchman/wipe which takes old msi and the modified dlls as input and gives msp and modified msi as output. I found the following in its build log. Are you suggesting to use -f in the case of light.exe? build.log E:\WIPE September 2008\wix2\candle.exe -out E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf797ff11f2.wixobj E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf797ff11f2.wxs E:\WIPE September 2008\wix2\light.exe -out E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\patch30.pcp E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf797ff11f2.wixobj E:\WIPE September 2008\wix2\msimsp.exe -s patch30.pcp -p MicrosoftEDIPathpatch30.msp -l buildpatch.log -f patchtemp Thanks, Sandeep From: Eitan Behar [ei...@baconao.net] Sent: Friday, January 30, 2009 12:10 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Need some help on wix check: 1. the new dll has a new file assembly version? 2. the linker option -fv is set? On Thu, Jan 29, 2009 at 8:30 PM, Sandeep Prakash sandeep.prak...@microsoft.com wrote: Hi, We are not able to update a dll present in gac through patch. I am new to wix. I want to know which tag/ attribute in the wix controls this behaviour. What's the use of 'AssemblyManifest' of file and is it some how related to the above behaviour. Any link to the documentation will be appreciated. Thanks, Sandeep -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install variable not kept around for uninstall?
Have you tried running the uninstall with logging enabled (msiexec /x
setup.msi /L*vx Setup.log) to see what is going on?
Neil
-Original Message-
From: Peter Oehlert [mailto:poehl...@securityinnovation.com]
Sent: 29 January 2009 22:09
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install variable not kept around for uninstall?
So I persisted my property value to the registry and use a registry
search
in the property to try to retrieve the value.
My issue is 2 fold. One, the property values aren't being populated from
the
registry properly on uninstall. It might be that the keys are deleted
(uninstalled) before they get a chance to be read or it might be they're
just being ignored.
Second, I'm not sure that I have my custom action set up correctly to
get
run at uninstall. I need it to get the server name in the expected sql
format (either {dbname}\{instancename} or just {dbname}).
The relevant values are below. Any help would be appreciated, I really
can't
figure out what to do at this point.
Thanks,
Peter
It looks something like this:
RegistryKey
Id=CreateKey
Root=HKLM
Action=create
Key=$(var.RegKey)
RegistryValue
Id=SetDatabaseServer
Action=write
Type=string
Name=DatabaseServer
Value=[TMEDATABASESERVER]
/
RegistryValue
Id=SetDatabaseInstance
Action=write
Type=string
Name=DatabaseInstance
Value=[TMEDATABASEINSTANCE]
/
RegistryValue
Id=SetDatabaseName
Action=write
Type=string
Name=DatabaseName
Value=[TMEDATABASENAME]
/
/RegistryKey
And
Property Id=TMEDATABASESERVER Value=(local)
RegistrySearch
Id=RegistrySearchTMEDatabaseServer
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseServer
/
/Property
Property Id=TMEDATABASEINSTANCE Value=SQLEXPRESS
RegistrySearch
Id=RegistrySearchTMEDatabaseInstance
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseInstance
/
/Property
Property Id=TmeDatabase Value=.\SQL /
Property Id=TMEDATABASENAME Value=TME
RegistrySearch
Id=RegistrySearchTMEDatabaseName
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseName
/
/Property
Because I support both named and unnamed instances I have a custom
action to
copy the property from TMEDATABASESERVER and TMEDATABASEINSTANCE to
TmeDatabase correctly depending on whether TMEDATABASEINSTANCE is
specified.
That looks like:
CustomAction Id=CA_SetDatabaseNoInstance Return=check
Property=TmeDatabase Value=[TMEDATABASESERVER] /
CustomAction Id=CA_SetDatabaseInstance Return=check
Property=TmeDatabase Value=[TMEDATABASESERVER]\[TMEDATABASEINSTANCE]
/
InstallExecuteSequence
Custom Action=CA_SetDatabaseInstance
Before=InstallValidate![CDATA[TMEDATABASEINSTANCE]]/Custom
Custom Action=CA_SetDatabaseNoInstance
Before=InstallValidate![CDATA[NOT TMEDATABASEINSTANCE]]/Custom
/InstallExecuteSequence
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Saturday, January 24, 2009 2:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install variable not kept around for uninstall?
If you need properties at uninstall time you need to persist them
somewhere and read them on uninstall, the registry is a common location
for these.
Neil
-Original Message-
From: Peter Oehlert [mailto:poehl...@securityinnovation.com]
Sent: 24 January 2009 19:58
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Install variable not kept around for uninstall?
So my scenario is that I query the user at install time what the
database
server, instance, and name should be. I then use these variables in a
sql:SqlDatabase / element to install a database.
This works great, except that if I change any of the default values at
uninstall it seems to go back to using the default values. I basically
have
a UI Dialog with a Edit control that is tied to a property for each of
these
values. I then dereference the property in the SqlDatabase element. How
do I
persist this value so that when I uninstall it tries to drop the correct
database rather than the default one?
Thanks in advance,
Peter Oehlert
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Re: [WiX-users] Need some help on wix
I think that is only true for the MSI version, all parts of file versions are used. Neil -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: 29 January 2009 22:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Need some help on wix The fourth place (the revision) is generally ignored by MSI. -- John M. Cooper -Original Message- From: Sandeep Prakash [mailto:sandeep.prak...@microsoft.com] Sent: Thursday, January 29, 2009 2:49 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Need some help on wix Hi Eitan, I verified the following: 1) Old dll has version 3.8.173.1 and the newer one has 1.8.173.2 . Is it ok to differ at the fourth place only? 2) We have an internal site http://patchman/wipe which takes old msi and the modified dlls as input and gives msp and modified msi as output. I found the following in its build log. Are you suggesting to use -f in the case of light.exe? build.log E:\WIPE September 2008\wix2\candle.exe -out E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf 797ff11f2.wixobj E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf 797ff11f2.wxs E:\WIPE September 2008\wix2\light.exe -out E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\patch30.pcp E:\temp\4b4db160-82bc-46ea-bb88-22c8cc7897fa\7efc83e9-3c16-4677-a6bb-ecf 797ff11f2.wixobj E:\WIPE September 2008\wix2\msimsp.exe -s patch30.pcp -p MicrosoftEDIPathpatch30.msp -l buildpatch.log -f patchtemp Thanks, Sandeep From: Eitan Behar [ei...@baconao.net] Sent: Friday, January 30, 2009 12:10 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Need some help on wix check: 1. the new dll has a new file assembly version? 2. the linker option -fv is set? On Thu, Jan 29, 2009 at 8:30 PM, Sandeep Prakash sandeep.prak...@microsoft.com wrote: Hi, We are not able to update a dll present in gac through patch. I am new to wix. I want to know which tag/ attribute in the wix controls this behaviour. What's the use of 'AssemblyManifest' of file and is it some how related to the above behaviour. Any link to the documentation will be appreciated. Thanks, Sandeep -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Secure custom actions/properties
I'm using a WiX custom action to import an RSA key container for encrypting parts of my config files, which is working fine. However, I have a concern - in order to import the container, I have to somehow include the RSAKeyValue XML in the .msi, which effectively means that anybody with Orca can pretty easily copy my public and private keys. I'd like to make it a little harder for them, and I've heard rumors - though I can't find any evidence - that it's possible to secure custom action data or properties. Does WiX support this, and if so, how is it done? My googling has thus far only told me about the SecureCustomProperties property, for controlling property access over the network during a managed install. Is there something else available that can encrypt the data within the MSI itself? Thanks, Steve -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Secure custom actions/properties
There is no Windows Installer feature that encrypts the data inside an MSI. The MSI features you are talking about 1. Prevent data from being logged to the log file (Property/@Hidden and CustomAction/@HideTarget) and 2. Enable you to pass Properties from the UI sequence to the Execute sequence (Property/@Secure). -Original Message- From: Steve Smith [mailto:st...@codejitsu.com] Sent: Thursday, January 29, 2009 15:17 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Secure custom actions/properties I'm using a WiX custom action to import an RSA key container for encrypting parts of my config files, which is working fine. However, I have a concern - in order to import the container, I have to somehow include the RSAKeyValue XML in the .msi, which effectively means that anybody with Orca can pretty easily copy my public and private keys. I'd like to make it a little harder for them, and I've heard rumors - though I can't find any evidence - that it's possible to secure custom action data or properties. Does WiX support this, and if so, how is it done? My googling has thus far only told me about the SecureCustomProperties property, for controlling property access over the network during a managed install. Is there something else available that can encrypt the data within the MSI itself? Thanks, Steve -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Secure custom actions/properties
PS: Data Protection API sounds more suited for what you need. -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Thursday, January 29, 2009 15:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Secure custom actions/properties There is no Windows Installer feature that encrypts the data inside an MSI. The MSI features you are talking about 1. Prevent data from being logged to the log file (Property/@Hidden and CustomAction/@HideTarget) and 2. Enable you to pass Properties from the UI sequence to the Execute sequence (Property/@Secure). -Original Message- From: Steve Smith [mailto:st...@codejitsu.com] Sent: Thursday, January 29, 2009 15:17 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Secure custom actions/properties I'm using a WiX custom action to import an RSA key container for encrypting parts of my config files, which is working fine. However, I have a concern - in order to import the container, I have to somehow include the RSAKeyValue XML in the .msi, which effectively means that anybody with Orca can pretty easily copy my public and private keys. I'd like to make it a little harder for them, and I've heard rumors - though I can't find any evidence - that it's possible to secure custom action data or properties. Does WiX support this, and if so, how is it done? My googling has thus far only told me about the SecureCustomProperties property, for controlling property access over the network during a managed install. Is there something else available that can encrypt the data within the MSI itself? Thanks, Steve -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need some help on wix
Sandeep Prakash wrote: 2) We have an internal site http://patchman/wipe which takes old msi and the modified dlls as input and gives msp and modified msi as output. I found the following in its build log. Are you suggesting to use -f in the case of light.exe? No, because that's building the patch; you need to use -fv when building the updated MSI. You need to speak to whoever wrote your patching system to make sure it's following the rules for building patches for assemblies in the GAC. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install variable not kept around for uninstall?
Yea, I have the logfile but it's not really indicating to me the failure.
The reg keys get deleted, the property initialization from the reg search
never seems to happen and the database uninstall script uses the hard coded
values from the properties rather than the values from the registry key.
I'll send anyone interested the log file.
--Peter
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Thursday, January 29, 2009 2:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install variable not kept around for uninstall?
Have you tried running the uninstall with logging enabled (msiexec /x
setup.msi /L*vx Setup.log) to see what is going on?
Neil
-Original Message-
From: Peter Oehlert [mailto:poehl...@securityinnovation.com]
Sent: 29 January 2009 22:09
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Install variable not kept around for uninstall?
So I persisted my property value to the registry and use a registry
search
in the property to try to retrieve the value.
My issue is 2 fold. One, the property values aren't being populated from
the
registry properly on uninstall. It might be that the keys are deleted
(uninstalled) before they get a chance to be read or it might be they're
just being ignored.
Second, I'm not sure that I have my custom action set up correctly to
get
run at uninstall. I need it to get the server name in the expected sql
format (either {dbname}\{instancename} or just {dbname}).
The relevant values are below. Any help would be appreciated, I really
can't
figure out what to do at this point.
Thanks,
Peter
It looks something like this:
RegistryKey
Id=CreateKey
Root=HKLM
Action=create
Key=$(var.RegKey)
RegistryValue
Id=SetDatabaseServer
Action=write
Type=string
Name=DatabaseServer
Value=[TMEDATABASESERVER]
/
RegistryValue
Id=SetDatabaseInstance
Action=write
Type=string
Name=DatabaseInstance
Value=[TMEDATABASEINSTANCE]
/
RegistryValue
Id=SetDatabaseName
Action=write
Type=string
Name=DatabaseName
Value=[TMEDATABASENAME]
/
/RegistryKey
And
Property Id=TMEDATABASESERVER Value=(local)
RegistrySearch
Id=RegistrySearchTMEDatabaseServer
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseServer
/
/Property
Property Id=TMEDATABASEINSTANCE Value=SQLEXPRESS
RegistrySearch
Id=RegistrySearchTMEDatabaseInstance
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseInstance
/
/Property
Property Id=TmeDatabase Value=.\SQL /
Property Id=TMEDATABASENAME Value=TME
RegistrySearch
Id=RegistrySearchTMEDatabaseName
Type=raw
Root=HKLM
Key=$(var.RegKey)
Name=DatabaseName
/
/Property
Because I support both named and unnamed instances I have a custom
action to
copy the property from TMEDATABASESERVER and TMEDATABASEINSTANCE to
TmeDatabase correctly depending on whether TMEDATABASEINSTANCE is
specified.
That looks like:
CustomAction Id=CA_SetDatabaseNoInstance Return=check
Property=TmeDatabase Value=[TMEDATABASESERVER] /
CustomAction Id=CA_SetDatabaseInstance Return=check
Property=TmeDatabase Value=[TMEDATABASESERVER]\[TMEDATABASEINSTANCE]
/
InstallExecuteSequence
Custom Action=CA_SetDatabaseInstance
Before=InstallValidate![CDATA[TMEDATABASEINSTANCE]]/Custom
Custom Action=CA_SetDatabaseNoInstance
Before=InstallValidate![CDATA[NOT TMEDATABASEINSTANCE]]/Custom
/InstallExecuteSequence
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Saturday, January 24, 2009 2:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install variable not kept around for uninstall?
If you need properties at uninstall time you need to persist them
somewhere and read them on uninstall, the registry is a common location
for these.
Neil
-Original Message-
From: Peter Oehlert [mailto:poehl...@securityinnovation.com]
Sent: 24 January 2009 19:58
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Install variable not kept around for uninstall?
So my scenario is that I query the user at install time what the
database
server, instance, and name should be. I then use these variables in a
sql:SqlDatabase / element to install a database.
This works great, except that if I change any of the default values at
uninstall it seems to go back to
[WiX-users] WiX 3.0: how to create Quick Launch shortcut and Desktop shortcut?
Hi, In WiX 3.0, is there a way to create a Quick Launch shortcut and Desktop shortcut based on the user's choice? I know there is a way to create a checkbox for Launch Applition option: http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm I'm wondering if there is a way to create a checkbox for Quick Luanch shortcut and Desktop shortcut on the last page of installation. Some code example are very welcome. Thanks. /Brian. __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.0: how to create Quick Launch shortcut and Desktop shortcut?
For the desktop you can use a standard Windows Installer directory reference (see the SDK). For quick launch the only way I have found is to use this: Directory Id=AppDataFolder Directory Id=Microsoft Name=Microsoft Directory Id=InternetExplorer Name=Internet Explorer Directory Id=QuickLaunchFolder Name=Quick Launch / /Directory /Directory /Directory Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com From: Little Forest [mailto:little.for...@ymail.com] Sent: Fri 30/01/2009 00:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 3.0: how to create Quick Launch shortcut and Desktop shortcut? Hi, In WiX 3.0, is there a way to create a Quick Launch shortcut and Desktop shortcut based on the user's choice? I know there is a way to create a checkbox for Launch Applition option: http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm I'm wondering if there is a way to create a checkbox for Quick Luanch shortcut and Desktop shortcut on the last page of installation. Some code example are very welcome. Thanks. /Brian. __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com http://ca.answers.yahoo.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in iis:WebApplication?
Sorry for delay with this response, Rob. I have run a simple test for 3 different builds: 4513, 4805 and 4923. It works the same way for any. Actually, the result is the following: the DTC service gets started automatically once addressed either by IIS extension or by IIS console, when you try to change the isolation level. So, it must have been something with that machine, when it failed... Anyway, this part doesn't seem to be broken by those recent changes in IIS extension, which is good news :). Sorry for the false alarm. -- Yan -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Wednesday, January 28, 2009 7:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in iis:WebApplication? It does surprise me that IIS console can configure this and the CustomAction cannot. I wonder if this is another issue related recent build changes. Would you mind trying an older build of WiX (two months or maybe six months) and see if it works. If this used to work and doesn't now then there is definitely a bug to be fixed. -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, January 28, 2009 01:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in iis:WebApplication? What happens if you create a medium isolated AppPool on Windows XP with DTC disabled? If you mean doing this manually via IIS console, then it works fine with DTC disabled. I can easily create applications with Medium and High isolation level, and DTC stays disabled. If you mean using WiX IIS extension, then it fails with the error I filed as a bug previously. I think this is less an issue with the extension and more a design issue with IIS I'm confident you're right. But I hope you can give me a hint how to work such IIS issues around. I really don't want to fall back to the custom actions :) One of my goals when switching the installation to WiX was to avoid inventing my own custom actions (at least, deferred ones). Thank you! -- Yan -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Tuesday, January 27, 2009 6:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in iis:WebApplication? What happens if you create a medium isolated AppPool on Windows XP with DTC disabled? Does it have issues as well or does it automatically enable DTC? I think this is less an issue with the extension and more a design issue with IIS. We try to plaster over a lot of bad designs in the WiX CustomActions but sometimes things still poke through. -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Tuesday, January 27, 2009 03:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in iis:WebApplication? I've decided to bring this back to your attention, guys. I have received the following feedback to the bug I've registered: This error code 0x8004e00f is CONTEXT_E_TMNOTAVAILABLE, which happens when COM+ was unable to talk to the Microsoft Distributed Transaction Coordinator. This service is only required when the application is installed as a COM+ application as seen in administrative tools - component services, which occurs when isolation is set to medium or high. Either install with an Isolation value of low (the default if no isolation value is specified), or if you want to install with isolation values of medium or high, you'll have to enable the Microsoft Distributed Transaction Coordinator on the machine you're installing to, then install the MSI. DTC is disabled by default for XP machines, as far as I can see. This means manual action before running install, which is not good user experience. Could you please confirm that the way IISExtension works at the moment is not a subject to change in the nearest future? It might happen that I simply chose the incorrect approach. All I want to accomplish is to take existent 'Default web site', switch its root to my INSTALLDIR, and tune its properties, for instance, change the isolation level to Medium. What's the way you would keep to in order to achieve this? Please, suggest. Thanks a lot! -- Yan -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Tuesday, January 20, 2009 7:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in iis:WebApplication? Thanks, I'll bring this to Mike's attention when we meet on Thursday. -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Tuesday, January 20, 2009 08:15 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in iis:WebApplication? Done: #2524017 -- Yan -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Tuesday, January 20, 2009 5:51 PM To: General discussion for Windows
