Re: [WiX-users] Creating patches
I have now modified my build script to use a locally build msi installer and comparing it with a version build on my build server yesterday. There is no practical difference between the two msi files except the version numbers. Is that why I keep getting errors? I get the following error from Torch: error TRCH0279 : The table definition of 'WixVariable' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. And I get this from Pyro: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. MinorUpdate\Patch.wxs(13) : warning PYRO1079 : The cabinet Patch.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet. Creating cabinet 'AppData\Local\Temp\q0qw3fj2\#Patch.cab'. Generating database. pyro.exe : error PYRO0001 : Cannot set column 'Protocol' with value 1 because it is less than the minimum allowed value for this column, 6. Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Row.set_Item(Int32 field, Object value) at Microsoft.Tools.WindowsInstallerXml.Binder.BindTransform(Output transform, String transformFile) at Microsoft.Tools.WindowsInstallerXml.Binder.GenerateDatabase(Output output, String databaseFile, Boolean keepAddedColumns, Boolean useSubdirectory) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args) Any help will be appreciated. /Thomas Due > -Original Message- > From: uni [mailto:unigauld...@gmail.com] > Sent: 2. maj 2013 12:07 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Creating patches > > 于02 May 2013 17:31:10,Thomas Due写到: > > Hello, > > > > I am trying to grasp the concept of minor and small upgrades, but I am > having some trouble with getting it to work. > > > > First of all, it doesn't seem to work at all with 3.7. > > I have downgraded my WiX to 3.5, and there something happens at least, > but my msp seems to be empty when I examine it with instead > (http://www.instedit.com/). > > > > A bit about what I do: > > I have a fairly complex installer with a couple of hundred files total, > > divided > among 4 features. I build this with TeamCity, and I have two separate > installers (no real changes, except for the version nummer - 1.2.0.22679 and > 1.2.5.22754). I imagine that this should be enough to generate something. > > > > I have a build script, a simple batch file, which executes the four steps > described in both the WiX doc and Nick Ramirez' book. > > > > My patch.wxs then includes a couple of file components, as I want these > replaces (mind you, I am still in the testing phase, trying to understand the > concept). > > > > First my "build script": > > === > > "%wixdir%bin\torch.exe" -p -xi %oldmsi% %newmsi% -v -out diff.wixmst > > "%wixdir%bin\candle.exe" -v Patch.wxs "%wixdir%bin\Light.exe" -v > > Patch.wixobj -out patch.wixmsp "%wixdir%bin\pyro.exe" -v "patch.wixmsp > > -out patch.msp -t Patch diff.wixmst > > > > %oldmsi% and %newmsi" are complete paths to the wixpdb files for > respectively old and new installer. > > Then my Patch.wsx: > > === > > > xmlns="http://schemas.microsoft.com/wix/2006/wi"; > > > > > >Classification="Update" > >Manufacturer="$(var.Manufacturer)" > >Description="Patch" > >DisplayName="Patch $(var.CurVersion)"> > > > > > > > > > Version="$(var.CurVersion)" > > Supersede="yes"> > > > > > > > > > > > > > > BuildVariables.wxi is simply a number of preprocessor variables, which is > shared with the installer project. > > > > Now, as I said, with 3.7 I get this result: > > Updating file information. > > Creating cabinet files. > > There will be '8' threads used to produce CAB files. > > Patch.wxs(20) : warning PYRO1079 : The cabinet 'ïPatch.cab' does not > contain any files. If this patch contains no files, this warning can likely > be > safely ignored. Otherwise, try passing -p to torch.exe when first building > the > transforms, or add a ComponentRef to your PatchFamily authoring to pull > changed files into the cabinet. > > Creating cabinet '\Local\Temp\kvov1bbk\#ïPatch.cab'. > > Generating database. > > di
Re: [WiX-users] Custom Action Extraction Issue
Can you pass the credential info to the CA and do the impersonation inside the utility? Or install the utility and call it on first run? -Original Message- From: Joe Barker [mailto:joeb...@gmail.com] Sent: 02 May 2013 16:36 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom Action Extraction Issue Hi, In my installer, I have the user enter a domain/user/password combination at the beginning which is then used as the user account to run an application pool in IIS. This combination of domain/user/password is then later impersonated as part of a custom action, which runs an executable to handle some other application specifics before the installer finishes. This custom action fails, however, unless I run the installer from a command prompt that was launched with administrative privileges. After some investigation, we've found that this is because the msi that's executed from the administrative command prompt extracts CA's to C:\Windows\Installer\, which means the impersonated user can read the files; when the msi is executed from a normal prompt, or the GUI, CA's are extracted to C:\Users\\AppData\Local\Temp\ (or somewhere around there), meaning the user that's being impersonated doesn't have permission to the folder, and therefore an exception is thrown. Is there any way to either control where the CA is extracted to, or to work around this issue? Not impersonating the user isn't an option, unfortunately. Any help would be much appreciated. Thanks, Joe - - Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action Extraction Issue
I'm already passing the credential info into the CA. Do you mean passing it to the CA, to the pass to the utility and run impersonation in there? I'll have to look and see if there's a way we can guarantee that the utility will be called on first run, as our application is a web-based application, so it's a little more difficult, as it only needs to be ran once per server/install. On Fri, May 3, 2013 at 9:53 AM, David Watson wrote: > Can you pass the credential info to the CA and do the impersonation inside > the utility? > Or install the utility and call it on first run? > -Original Message- > From: Joe Barker [mailto:joeb...@gmail.com] > Sent: 02 May 2013 16:36 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Custom Action Extraction Issue > Hi, > In my installer, I have the user enter a domain/user/password combination at > the beginning which is then used as the user account to run an application > pool in IIS. This combination of domain/user/password is then later > impersonated as part of a custom action, which runs an executable to handle > some other application specifics before the installer finishes. > This custom action fails, however, unless I run the installer from a command > prompt that was launched with administrative privileges. After some > investigation, we've found that this is because the msi that's executed from > the administrative command prompt extracts CA's to C:\Windows\Installer\, > which means the impersonated user can read the files; when the msi is > executed from a normal prompt, or the GUI, CA's are extracted to > C:\Users\\AppData\Local\Temp\ (or somewhere around there), meaning the > user that's being impersonated doesn't have permission to the folder, and > therefore an exception is thrown. > Is there any way to either control where the CA is extracted to, or to work > around this issue? Not impersonating the user isn't an option, unfortunately. > Any help would be much appreciated. > Thanks, > Joe > - > - > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get > 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead Download > for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > SDL PLC confidential, all rights reserved. > If you are not the intended recipient of this mail SDL requests and requires > that you delete it without acting upon or copying any of its contents, and we > further request that you advise us. > SDL PLC is a public limited company registered in England and Wales. > Registered number: 02675207. > Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 > 7DY, UK. > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Platform x64 And Config file also?
Hello. I create an msi für x64. A Component i must mark with Win64=yes. But a Config file has no platform. What is the right way to handle this? and so on... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Platform-x64-And-Config-file-also-tp7585596.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] add files with heat
Hi, I was looking for a way to add files from multiple directories with HeatDirectory element. Also, I would like to know if there is a way to append the fragment generated by HeatDirectory to an existing .wxs file. Regards, Victor Mukherjee -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Alternative to Heat.exe
I never use wild cards...some day you will distribute unwanted files to customers. How often is your setup changes? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Alternative-to-Heat-exe-tp7585574p7585598.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Professional encryption
Bug ID for this issue is 3287, the only solution I found so far is to build the MSI in a VM that doesn't have FIPS (SHA2) enabled. -Original Message- From: Nick Miller [mailto:nmil...@livetechnology.com] Sent: May-02-13 7:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption VirtualBox is your friend. ;) -Original Message- From: Wesley Manning [mailto:wmann...@dynagen.ca] Sent: Thursday, May 02, 2013 12:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption That was me actually. I'm going to have to get hold of a computer with windows 7 professional and see if I can reproduce it. I can't on a Ultimate computer I have. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: May-02-13 12:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption There was some discussion in the last few weeks about mysteriously encrypted MSIs. I don't remember a resolution. More information to help track down the root cause would be welcome. On Thu, May 2, 2013 at 5:56 AM, Wesley Manning wrote: > Hi, > > I had three customers now in a 2 week period where my burn installer > fails on their computers. They all have Windows 7 Professional. When > I get them to go in to the Package Cache some MSIs are encrypted. I > get them to remove encryption on the MSI files there, retry and the install > then works. > > Anybody else have this issue? I'm aware MSI can't install > successfully encrypted but burn removes encryption from the package > cache so this should not happen. > > Wes > > > > -- > Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET Get 100% visibility into your production application - at no > cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Professional encryption
My problem is different. It's my installer exe that can't run on users with windows 7 professional. I can build the installer fine. -Original Message- From: Jonathan Racine [mailto:jonathan.rac...@hybris.com] Sent: May-03-13 10:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption Bug ID for this issue is 3287, the only solution I found so far is to build the MSI in a VM that doesn't have FIPS (SHA2) enabled. -Original Message- From: Nick Miller [mailto:nmil...@livetechnology.com] Sent: May-02-13 7:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption VirtualBox is your friend. ;) -Original Message- From: Wesley Manning [mailto:wmann...@dynagen.ca] Sent: Thursday, May 02, 2013 12:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption That was me actually. I'm going to have to get hold of a computer with windows 7 professional and see if I can reproduce it. I can't on a Ultimate computer I have. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: May-02-13 12:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Professional encryption There was some discussion in the last few weeks about mysteriously encrypted MSIs. I don't remember a resolution. More information to help track down the root cause would be welcome. On Thu, May 2, 2013 at 5:56 AM, Wesley Manning wrote: > Hi, > > I had three customers now in a 2 week period where my burn installer > fails on their computers. They all have Windows 7 Professional. When > I get them to go in to the Package Cache some MSIs are encrypted. I > get them to remove encryption on the MSI files there, retry and the install > then works. > > Anybody else have this issue? I'm aware MSI can't install > successfully encrypted but burn removes encryption from the package > cache so this should not happen. > > Wes > > > > -- > Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET Get 100% visibility into your production application - at no > cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free t
Re: [WiX-users] Custom Action Extraction Issue
I was guessing at what exactly you are doing. Yes get the utility to do its own impersonation. Or run a post install configuration utility. -Original Message- From: Joe Barker [mailto:joeb...@gmail.com] Sent: 03 May 2013 10:11 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Action Extraction Issue I'm already passing the credential info into the CA. Do you mean passing it to the CA, to the pass to the utility and run impersonation in there? I'll have to look and see if there's a way we can guarantee that the utility will be called on first run, as our application is a web-based application, so it's a little more difficult, as it only needs to be ran once per server/install. On Fri, May 3, 2013 at 9:53 AM, David Watson wrote: > Can you pass the credential info to the CA and do the impersonation > inside the utility? > Or install the utility and call it on first run? > -Original Message- > From: Joe Barker [mailto:joeb...@gmail.com] > Sent: 02 May 2013 16:36 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Custom Action Extraction Issue Hi, In my > installer, I have the user enter a domain/user/password combination at > the beginning which is then used as the user account to run an > application pool in IIS. This combination of domain/user/password is > then later impersonated as part of a custom action, which runs an > executable to handle some other application specifics before the installer finishes. > This custom action fails, however, unless I run the installer from a > command prompt that was launched with administrative privileges. After > some investigation, we've found that this is because the msi that's > executed from the administrative command prompt extracts CA's to > C:\Windows\Installer\, which means the impersonated user can read the > files; when the msi is executed from a normal prompt, or the GUI, CA's > are extracted to C:\Users\\AppData\Local\Temp\ (or somewhere > around there), meaning the user that's being impersonated doesn't have > permission to the folder, and therefore an exception is thrown. > Is there any way to either control where the CA is extracted to, or to > work around this issue? Not impersonating the user isn't an option, unfortunately. > Any help would be much appreciated. > Thanks, > Joe > -- > --- > - > Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > SDL PLC confidential, all rights reserved. > If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. > SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. > Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production Get down to > code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users - - Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Alternative to Heat.exe
Hi tom, So their is a way to you use Wild card? As we have package without unwanted files. And in WIX project we want use a wild card to get all the files under package folder into MSI .Instead of specify each file as component to pull into MSI. We have integrated the MSi to dailybuild .So everytime we add bunch of files product.wxs needs to be updated ;so files get pulled into MSI.(which is frustrating for Tech leads).So tech leads wants to take care of the Filtered Website folder(through msbuild) and just want WIX to create MSI package out of the Website directory using Wild card. if it can be done with wild card to pull files under website directory into MSI .please let me know. Thanks Chatra -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Alternative-to-Heat-exe-tp7585574p7585602.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] add files with heat
In visual studio under build you need to define a preprocessor variable that points to the location of the root directory. Example: DatabaseDir=..\Folder. Then under build events you need to write a Pre-build Event command line to have heat generate the wxs file every time you make a build. Example: "$(WIX)bin\heat.exe" dir "$(ProjectDir)..\Folder" -dr INSTALLLOCATION -cg NameofyourGroup -gg -sf -srd -var "var.DatabaseDir" -out "$(ProjectDir)..\wxsfolder\NameofyourGroup .wxs". Hope this is what you were looking for. J On Fri, May 3, 2013 at 6:03 AM, Victor Mukherjee wrote: > Hi, > > I was looking for a way to add files from multiple directories with > HeatDirectory element. > Also, I would like to know if there is a way to append the fragment > generated by HeatDirectory to an existing .wxs file. > > Regards, > Victor Mukherjee > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- "They may forget what you said but they will never forget how you made them feel." -- Anonymous -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Change content of the config file based on [ComputerName]
Hi, I want to change the content of the config file based on the machine (SPECHW01,SPECHW02..) the MSI gets deployed.Below is the content of the file and node "Param" I want to change. http://web.service/keepalive.aspx true if the file is getting deployed on machine "SPECHW01" then change the content of file web.config. Below is the node "Param" I want to change to. http://web1.service/keepalive.aspx true if the MSI is deployed on machine "SPECHW02" the content of Web.config needs to be changed as below for node param. http://web2.service/keepalive.aspx true Below is the component where I need to make it work. and component need to verify the machine it gets installed and change the contents of the file. Thanks in Advance Chatra -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Change-content-of-the-config-file-based-on-ComputerName-tp7585604.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] add files with heat
In general, it would be better to use the element. For example: True -- John Merryweather Cooper Build & Install Engineer - ESA Jack Henry & Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Friday, May 03, 2013 10:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] add files with heat In visual studio under build you need to define a preprocessor variable that points to the location of the root directory. Example: DatabaseDir=..\Folder. Then under build events you need to write a Pre-build Event command line to have heat generate the wxs file every time you make a build. Example: "$(WIX)bin\heat.exe" dir "$(ProjectDir)..\Folder" -dr INSTALLLOCATION -cg NameofyourGroup -gg -sf -srd -var "var.DatabaseDir" -out "$(ProjectDir)..\wxsfolder\NameofyourGroup .wxs". Hope this is what you were looking for. J On Fri, May 3, 2013 at 6:03 AM, Victor Mukherjee wrote: > Hi, > > I was looking for a way to add files from multiple directories with > HeatDirectory element. > Also, I would like to know if there is a way to append the fragment > generated by HeatDirectory to an existing .wxs file. > > Regards, > Victor Mukherjee > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production Get down to > code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- "They may forget what you said but they will never forget how you made them feel." -- Anonymous -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why is RollbackBoundary discarded?
Jeremiah, yes, the relative pathing is correct. The problem is not about finding the file but rather the rollback logic. Thank you for the suggestion though. Greg -- Message: 1 Date: Thu, 2 May 2013 18:20:10 -0500 From: Jeremiahf Subject: Re: [WiX-users] Why is RollbackBoundary discarded? To: "General discussion for Windows Installer XML toolset." Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Are you sure this is correct? $(var.ProjectDir)..\..\ How many folders are you actually backing out then back into and are they located in your Project Directory? J On Thu, May 2, 2013 at 6:05 PM, Prosch, Greg wrote: > For the burn code below I am getting the following error message: > > warning LGHT1129: The RollbackBoundary > 'After_PowerShellAccessPolicyConfig' was discarded because it was not > followed by a package. Without a package the rollback boundary doesn't > do anything. Verify that the RollbackBoundary element is not followed > by another RollbackBoundary and that the element is not at the end of > the chain. > > Why? The RollbackBoundary appears to be followed by a package. > > >Id="PowerShellAccessPolicyConfig" > > SourceFile="$(var.ProjectDir)..\..\ATTACExplorerLauncher\InstallScripts\PowerShellAccessPolicyConfig.bat" > Cache="no" > Compressed="yes" > PerMachine="yes" > Permanent="yes" > Vital="yes" > > > > > > > >Id="EnableWindowsFeatures" > > SourceFile="$(var.ProjectDir)..\..\ATTACExplorerLauncher\InstallScripts\EnableWindowsFeatures.bat" > Cache="no" > Compressed="yes" > PerMachine="yes" > Permanent="yes" > Vital="yes" > After="PowerShellAccessPolicyConfig" > > > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why is RollbackBoundary discarded?
Bingo! Thank you Bob. I really didn't need those since I wasn't changing the default flow anyway. Greg Date: Thu, 02 May 2013 21:35:54 -0400 From: Bob Arnson Subject: Re: [WiX-users] Why is RollbackBoundary discarded? To: wix-users@lists.sourceforge.net Message-ID: <5183147a.6000...@joyofsetup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 02-May-13 19:05, Prosch, Greg wrote: > Why? The RollbackBoundary appears to be followed by a package. Physically but not logically, because you reordered the packages using the After attribute. -- sig://boB http://joyofsetup.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why is RollbackBoundary discarded?
In general, with the WiX toolset it's generally best to only add the attributes you need. On Fri, May 3, 2013 at 9:47 AM, Prosch, Greg wrote: > Bingo! Thank you Bob. I really didn't need those since I wasn't changing > the default flow anyway. > > Greg > > > Date: Thu, 02 May 2013 21:35:54 -0400 > From: Bob Arnson > Subject: Re: [WiX-users] Why is RollbackBoundary discarded? > To: wix-users@lists.sourceforge.net > Message-ID: <5183147a.6000...@joyofsetup.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 02-May-13 19:05, Prosch, Greg wrote: > > Why? The RollbackBoundary appears to be followed by a package. > Physically but not logically, because you reordered the packages using > the After attribute. > > -- > sig://boB > http://joyofsetup.com/ > > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Alternative to Heat.exe
You could harvest them all and use an XSLT to filter them. The command line heat accepts a -t parameter to transform the output, and the MSBuild task should have a related property. -Original Message- From: chennam [mailto:chatrapathi.chen...@gmail.com] Sent: Friday, May 03, 2013 9:57 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Alternative to Heat.exe Hi tom, So their is a way to you use Wild card? As we have package without unwanted files. And in WIX project we want use a wild card to get all the files under package folder into MSI .Instead of specify each file as component to pull into MSI. We have integrated the MSi to dailybuild .So everytime we add bunch of files product.wxs needs to be updated ;so files get pulled into MSI.(which is frustrating for Tech leads).So tech leads wants to take care of the Filtered Website folder(through msbuild) and just want WIX to create MSI package out of the Website directory using Wild card. if it can be done with wild card to pull files under website directory into MSI .please let me know. Thanks Chatra -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Alternative-to-Heat-exe-tp7585574p7585602.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Change content of the config file based on [ComputerName]
Hmm, I think I would have one config file and conditionally modify it with CA's like XmlFile/XmlConfig. I'd also try to eliminate the machine name dependency and instead use a dev/test/live burn bundle passing a parameter via a MsiProperty to the installer. -Original Message- From: chennam [mailto:chatrapathi.chen...@gmail.com] Sent: Friday, May 03, 2013 11:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Change content of the config file based on [ComputerName] Hi, I want to change the content of the config file based on the machine (SPECHW01,SPECHW02..) the MSI gets deployed.Below is the content of the file and node "Param" I want to change. http://web.service/keepalive.aspx true if the file is getting deployed on machine "SPECHW01" then change the content of file web.config. Below is the node "Param" I want to change to. http://web1.service/keepalive.aspx true if the MSI is deployed on machine "SPECHW02" the content of Web.config needs to be changed as below for node param. http://web2.service/keepalive.aspx true Below is the component where I need to make it work. and component need to verify the machine it gets installed and change the contents of the file. Thanks in Advance Chatra -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Change-content-of-the-config-file-based-on-ComputerName-tp7585604.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Network Component Type "Service"
Hello, Does anybody have experience installing drivers with Wix? I have a NIC GigE filter driver that installs fine but does not add the service to the NIC's on the computer. How do I install the network service in wix? Does anybody have experience installing Network service drivers? Thank you, Michael Ogilvie -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Network Component Type "Service"
I haven't done it myself but I know others have used the Difx extension to do so. On Fri, May 3, 2013 at 10:33 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Hello, > > Does anybody have experience installing drivers with Wix? > > > > I have a NIC GigE filter driver that installs fine but does not add the > service to the NIC's on the computer. How do I install the network > service in wix? > > Does anybody have experience installing Network service drivers? > > > Thank you, > > Michael Ogilvie > > > > > -- > Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only > SaaS-based application performance monitoring service that delivers > powerful full stack analytics. Optimize and monitor your browser, app, & > servers with just a few lines of code. Try New Relic and get this > awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only > SaaS-based application performance monitoring service that delivers > powerful full stack analytics. Optimize and monitor your browser, app, & > servers with just a few lines of code. Try New Relic and get this > awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Network Component Type "Service"
I use Wix to install drivers but only USB/HID drivers which are straight forward. The element goes with the component with element of the inf file. Other driver components do not need the difx element. You need this: xmlns:difx="http://schemas.microsoft.com/wix/DifxAppExtension"; And you need to add x32 or x64 difxapp extension depending on bitness of driver. But looks like you already know this? This is all I know... Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: May-03-13 2:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Network Component Type "Service" I haven't done it myself but I know others have used the Difx extension to do so. On Fri, May 3, 2013 at 10:33 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Hello, > > Does anybody have experience installing drivers with Wix? > > > > I have a NIC GigE filter driver that installs fine but does not add > the service to the NIC's on the computer. How do I install the network > service in wix? > > Does anybody have experience installing Network service drivers? > > > Thank you, > > Michael Ogilvie > > > > -- > -- > -- > Try New Relic Now & We'll Send You this Cool Shirt New Relic is the > only SaaS-based application performance monitoring service that > delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_apr > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > -- > -- > Try New Relic Now & We'll Send You this Cool Shirt New Relic is the > only SaaS-based application performance monitoring service that > delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_apr > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production Get down to > code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Heat with file path longer than 260 chars report an error
I have used HeatDirectory to harvest a folder with many subdirectories and files, but Heat.exe report an error because the filepath of an item is larger than 260 chars (with the name and the full subdirectories path)Is there any way to harvest a folder with may subdirectories as the single filepath is longer than 260 chars? -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with file path longer than 260 chars report an error
That character limit on paths is imposed by .NET. :-( On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci wrote: > I have used HeatDirectory to harvest a folder with many subdirectories and > files, but Heat.exe report an error because the filepath of an item is > larger than 260 chars (with the name and the full subdirectories path)Is > there any way to harvest a folder with may subdirectories as the single > filepath is longer than 260 chars? > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Edwin G. Castro -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with file path longer than 260 chars report an error
Unfortunately, the .NET Framework doesn't handle that. On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci wrote: > I have used HeatDirectory to harvest a folder with many subdirectories and > files, but Heat.exe report an error because the filepath of an item is > larger than 260 chars (with the name and the full subdirectories path)Is > there any way to harvest a folder with may subdirectories as the single > filepath is longer than 260 chars? > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with file path longer than 260 chars report an error
Have not at all tried this, and it may not work or cause all other kinds of issues... But judging from http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx , you could try prefixing the fully qualified path with \\?\ The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path". -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Friday, May 03, 2013 1:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Heat with file path longer than 260 chars report an error That character limit on paths is imposed by .NET. :-( On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci wrote: > I have used HeatDirectory to harvest a folder with many subdirectories > and files, but Heat.exe report an error because the filepath of an > item is larger than 260 chars (with the name and the full > subdirectories path)Is there any way to harvest a folder with may > subdirectories as the single filepath is longer than 260 chars? > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production Get down to > code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Edwin G. Castro -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with file path longer than 260 chars report an error
It's not just .NET. Many functions in the Win32 API have the same limitation unless you use UNC path names (in which case the limit is 32767 characters). Daniel Madill -Original Message- From: Edwin Castro [mailto:egca...@gmail.com] Sent: May-03-13 2:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Heat with file path longer than 260 chars report an error That character limit on paths is imposed by .NET. :-( On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci wrote: > I have used HeatDirectory to harvest a folder with many subdirectories and > files, but Heat.exe report an error because the filepath of an item is > larger than 260 chars (with the name and the full subdirectories path)Is > there any way to harvest a folder with may subdirectories as the single > filepath is longer than 260 chars? > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Edwin G. Castro -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with file path longer than 260 chars report an error
On 2013-05-03 20:10, Edwin Castro wrote: > That character limit on paths is imposed by .NET. :-( I use https://alphafs.codeplex.com/ to work with pathes up to 32000 characters. I hope they will fix it in .NET sometime. Marc -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
The way it works in MSI isn't really mysterious. Basically the property name needs to be public (and that means it must be all uppercase). If WiX does its thing properly then you can open the generated MSI file with an editor such as Orca, look in the Properties table, and in the Property table there'll be a SecureCustomProperties property and your property name will be in that list. This works. If it didn't work then Microsoft would be all over it as a security bug. Generally speaking, people get account passwords from a MSI dialog and store it in a property such as MYPASSWORD, and then pass it to a custom action that uses it. However, you're using managed code custom actions, and it seems from the log that the (DTF?) code just does its own logging into the MSI log without caring whether there's a password in there. So it may be a DTF thing, not sure, and if it is then HideTarget etc won't help at all. The short answer is that if the DTF code is logging a connection string that typically contains a password, then it probably shouldn't. Phil -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Thursday, May 02, 2013 4:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Hi Steve, My requirements are strictly to use command line. Crazy? Maybe. I have to say I have seen this topic all over blogs. Seems like there is always a way, you just have to figure out how On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie wrote: > Hmm... I commented out my custom action that sets the property: > > > And ran the install, everything worked and my Web App Pool + Web site > launched without errors (would have failed if I didn't have a password > for the Web App Pool) > > However I do publish the property during the UI: > Order="9">1 (my web site info dialog page during install) > > I checked my MSI log file and there wasn't any viewable strings for > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. Its > value is '**' > > Publish your password within the UI area and see if that works... > (also commenting out your custom action to set the property > > Steve > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: May-02-13 6:29 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > Sure thing... > > Action start 17:26:56: CA_DBAction. > Action ended 17:26:56: CA_DBAction. Return value 1. > Action start 17:26:56: InstallFinalize. > SFXCA: Extracting custom action to temporary directory: > C:\WINDOWS\Installer\MSI1045.tmp-\ > SFXCA: Binding to CLR version v2.0.50727 Calling custom action > DatabaseCA!DatabaseCA.CustomActions.DatabaseCA > Begin DatabaseCA > Connecton String: Data Source=source;Packet > Size=4096;Uid=sqluser;Pwd=mypassword > > I as well have a custom action and HideTarget does nothing. > > > On Thu, May 2, 2013 at 4:53 PM, Chad Petersen > wrote: > > > If possible paste in a snippet of your log file around where the > > password is seen. I tried for a long time to hide passwords using > > the > same method. > > But it was some built-in custom actions that were logging my > > passwords rather than code I'd written myself. > > > > > Id="ExecuteSqlStrings" Hidden="yes"/> > > > > These were two entries that I made to make those extensions hide the > > data passed to them, such as my password. > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: Thursday, May 02, 2013 2:38 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > > > I have tried that and no luck. My MSI is installed via command line. > > > > I've even tried to give the property Id a value in case I missed > > something and still doesn't work. > > > > > /> > > > > My test system is running Server 2003 R2 SP 2 windows installer > > version > > 4.5 6001.22159 > > > > I've upgraded from WIX 3.6 TO 3.7 in case it was a bug as I have > > found in hundreds of blogs online but every time I see that a fix > > was submitted, I can't tell what version it was submitted in. (sorry > > for the run on > > sentence.) > > > > J > > > > > > On Thu, May 2, 2013 at 4:24 PM, Steven Ogilvie > > > >wrote: > > > > > I declare the property: > > > > > > This is how I use my password controls: > > > X="180" > > > Y="152" Property="WEBAPPPOOL_PASSWORD" Password="yes" TabSkip="no" > > > /> > > > > > > Logfile: > > > MSI (c) (70:1C) [14:50:59:778]: PROPERTY CHANGE: Adding > > > WEBAPPPOOL_PASSWORD property. Its value is '**' > > > > > > > > > -Original Message- > > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > > Sent: May-02-13 5:08 PM > > > To: wix-users@lists.sourceforge.net > > > Subject: [WiX-users] Hide/blank out Passwords in MSI log file > > > > >
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
I was not using managed code custom actions... I was doing: Tried adding: HideTarget="yes" that didn't help NOT Installed This property was in a custom dialog: 1 It was the custom action " CA_WebAppPoolPassword.SetProperty " that was displaying the property in the MSI log file. Took it out and now the password is not being displayed in plain letters... Steve -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: May-03-13 2:27 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file The way it works in MSI isn't really mysterious. Basically the property name needs to be public (and that means it must be all uppercase). If WiX does its thing properly then you can open the generated MSI file with an editor such as Orca, look in the Properties table, and in the Property table there'll be a SecureCustomProperties property and your property name will be in that list. This works. If it didn't work then Microsoft would be all over it as a security bug. Generally speaking, people get account passwords from a MSI dialog and store it in a property such as MYPASSWORD, and then pass it to a custom action that uses it. However, you're using managed code custom actions, and it seems from the log that the (DTF?) code just does its own logging into the MSI log without caring whether there's a password in there. So it may be a DTF thing, not sure, and if it is then HideTarget etc won't help at all. The short answer is that if the DTF code is logging a connection string that typically contains a password, then it probably shouldn't. Phil -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Thursday, May 02, 2013 4:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Hi Steve, My requirements are strictly to use command line. Crazy? Maybe. I have to say I have seen this topic all over blogs. Seems like there is always a way, you just have to figure out how On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie wrote: > Hmm... I commented out my custom action that sets the property: > > > And ran the install, everything worked and my Web App Pool + Web site > launched without errors (would have failed if I didn't have a password > for the Web App Pool) > > However I do publish the property during the UI: > Order="9">1 (my web site info dialog page during install) > > I checked my MSI log file and there wasn't any viewable strings for > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. Its > value is '**' > > Publish your password within the UI area and see if that works... > (also commenting out your custom action to set the property > > Steve > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: May-02-13 6:29 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > Sure thing... > > Action start 17:26:56: CA_DBAction. > Action ended 17:26:56: CA_DBAction. Return value 1. > Action start 17:26:56: InstallFinalize. > SFXCA: Extracting custom action to temporary directory: > C:\WINDOWS\Installer\MSI1045.tmp-\ > SFXCA: Binding to CLR version v2.0.50727 Calling custom action > DatabaseCA!DatabaseCA.CustomActions.DatabaseCA > Begin DatabaseCA > Connecton String: Data Source=source;Packet > Size=4096;Uid=sqluser;Pwd=mypassword > > I as well have a custom action and HideTarget does nothing. > > > On Thu, May 2, 2013 at 4:53 PM, Chad Petersen > wrote: > > > If possible paste in a snippet of your log file around where the > > password is seen. I tried for a long time to hide passwords using > > the > same method. > > But it was some built-in custom actions that were logging my > > passwords rather than code I'd written myself. > > > > > Id="ExecuteSqlStrings" Hidden="yes"/> > > > > These were two entries that I made to make those extensions hide the > > data passed to them, such as my password. > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: Thursday, May 02, 2013 2:38 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > > > I have tried that and no luck. My MSI is installed via command line. > > > > I've even tried to give the property Id a value in case I missed > > something and still doesn't work. > > > > > /> > > > > My test system is running Server 2003 R2 SP 2 windows installer > > version > > 4.5 6001.22159 > > > > I've upgraded from WIX 3.6 TO 3.7 in case it was a bug as I have > > found in hundreds of blogs online but every time I see that a fix > > was submitted, I can't tell what version it was submitted in. (sorry > > for the run on > > sentence.) > > > > J > > > > > > On Thu, May
Re: [WiX-users] Change content of the config file based on [ComputerName]
The Issue I am working on is for Production environment where content of Web.config is different for 5 machines at below node. http://web.service/keepalive.aspx true For other environments we have only one web.config for each. But we have 5 different for PROD. And I don't want to place all 5 on all the machines ,So that was the reason I want to modify the node based on the conditions during Installation .Condition can be "Environment" and "ComputerName". I was looking for some thing how to write "CA's like XmlFile/XmlConfig" where having more than one condition to satisfy.Please point out me good source. Thanks Chatra -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Change-content-of-the-config-file-based-on-ComputerName-tp7585604p7585622.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Change content of the config file based on [ComputerName]
The better option is to have one Web.config file and 6 other components (containing the XmlFile elements) with conditions on them for writing the appropriate values. Not that I like the idea, but you could have 6 Components with a Web.config in each and a Condition element for each component based on the machine name http://msdn.microsoft.com/en-us/library/windows/desktop/aa368009(v=vs.85).aspx. -Original Message- From: chennam [mailto:chatrapathi.chen...@gmail.com] Sent: Friday, May 03, 2013 1:54 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Change content of the config file based on [ComputerName] The Issue I am working on is for Production environment where content of Web.config is different for 5 machines at below node. http://web.service/keepalive.aspx true For other environments we have only one web.config for each. But we have 5 different for PROD. And I don't want to place all 5 on all the machines ,So that was the reason I want to modify the node based on the conditions during Installation .Condition can be "Environment" and "ComputerName". I was looking for some thing how to write "CA's like XmlFile/XmlConfig" where having more than one condition to satisfy.Please point out me good source. Thanks Chatra -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Change-content-of-the-config-file-based-on-ComputerName-tp7585604p7585622.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with file path longer than 260 chars report an error
Unfortunately, won't work in NETFX and MSI APIs don't like the Unicode path format either. On Fri, May 3, 2013 at 11:15 AM, Hoover, Jacob wrote: > Have not at all tried this, and it may not work or cause all other kinds > of issues... But judging from > http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx , you > could try prefixing the fully qualified path with \\?\ > > The Windows API has many functions that also have Unicode versions to > permit an extended-length path for a maximum total path length of 32,767 > characters. This type of path is composed of components separated by > backslashes, each up to the value returned in the lpMaximumComponentLength > parameter of the GetVolumeInformation function (this value is commonly 255 > characters). To specify an extended-length path, use the "\\?\" prefix. For > example, "\\?\D:\very long path". > > -Original Message- > From: Edwin Castro [mailto:egca...@gmail.com] > Sent: Friday, May 03, 2013 1:10 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Heat with file path longer than 260 chars report > an error > > That character limit on paths is imposed by .NET. :-( > > > On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci wrote: > > > I have used HeatDirectory to harvest a folder with many subdirectories > > and files, but Heat.exe report an error because the filepath of an > > item is larger than 260 chars (with the name and the full > > subdirectories path)Is there any way to harvest a folder with may > > subdirectories as the single filepath is longer than 260 chars? > > > > > > -- > > Get 100% visibility into Java/.NET code with AppDynamics Lite > > It's a free troubleshooting tool designed for production Get down to > > code-level detail for bottlenecks, with <2% overhead. > > Download for free and get started troubleshooting in minutes. > > http://p.sf.net/sfu/appdyn_d2d_ap2 > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > Edwin G. Castro > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free > troubleshooting tool designed for production Get down to code-level detail > for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
Steven, "Tried adding: HideTarget="yes" that didn't help" Indeed! I'm even tried to remove logging from the custom action and I still see the password... I've even checked MsiHiddenProperties and see that PASSWORD is listed along with CA_DBAction... Not in SecureCustomProperties... I added secure="yes" and now it is there.. Execute the installer with logging and it is still unsecure in plain text in the log. It must be between the MSI installer and the SQL connection that is being made. Thoughts? J On Fri, May 3, 2013 at 1:48 PM, Steven Ogilvie wrote: > I was not using managed code custom actions... > > I was doing: > > > Property="CA_WebAppPoolPassword." > Value="WEBAPPPOOL_PASSWORD=[WEBAPPPOOL_PASSWORD]"/> > Tried adding: HideTarget="yes" that didn't help > >After="CA_DataBasePassword.SetProperty">NOT Installed > > This property was in a custom dialog: > Y="152" Text="Web App Pool user password:" Transparent="yes" NoPrefix="yes" > /> > Y="152" Property="WEBAPPPOOL_PASSWORD" Password="yes" TabSkip="no" /> > Order="9">1 > > It was the custom action " CA_WebAppPoolPassword.SetProperty " that was > displaying the property in the MSI log file. > > Took it out and now the password is not being displayed in plain letters... > > Steve > > > -Original Message- > From: Phil Wilson [mailto:phil.wil...@mvps.org] > Sent: May-03-13 2:27 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log > file > > The way it works in MSI isn't really mysterious. Basically the property > name needs to be public (and that means it must be all uppercase). If WiX > does its thing properly then you can open the generated MSI file with an > editor such as Orca, look in the Properties table, and in the Property > table there'll be a SecureCustomProperties property and your property name > will be in that list. > > This works. If it didn't work then Microsoft would be all over it as a > security bug. > > Generally speaking, people get account passwords from a MSI dialog and > store it in a property such as MYPASSWORD, and then pass it to a custom > action that uses it. > > However, you're using managed code custom actions, and it seems from the > log that the (DTF?) code just does its own logging into the MSI log without > caring whether there's a password in there. So it may be a DTF thing, not > sure, and if it is then HideTarget etc won't help at all. The short answer > is that if the DTF code is logging a connection string that typically > contains a password, then it probably shouldn't. > > Phil > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: Thursday, May 02, 2013 4:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log > file > > Hi Steve, > > My requirements are strictly to use command line. Crazy? Maybe. I have to > say I have seen this topic all over blogs. Seems like there is always a > way, you just have to figure out how > > > On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie > wrote: > > > Hmm... I commented out my custom action that sets the property: > > > > > > And ran the install, everything worked and my Web App Pool + Web site > > launched without errors (would have failed if I didn't have a password > > for the Web App Pool) > > > > However I do publish the property during the UI: > > > Order="9">1 (my web site info dialog page during install) > > > > I checked my MSI log file and there wasn't any viewable strings for > > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. Its > > value is '**' > > > > Publish your password within the UI area and see if that works... > > (also commenting out your custom action to set the property > > > > Steve > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: May-02-13 6:29 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > > > Sure thing... > > > > Action start 17:26:56: CA_DBAction. > > Action ended 17:26:56: CA_DBAction. Return value 1. > > Action start 17:26:56: InstallFinalize. > > SFXCA: Extracting custom action to temporary directory: > > C:\WINDOWS\Installer\MSI1045.tmp-\ > > SFXCA: Binding to CLR version v2.0.50727 Calling custom action > > DatabaseCA!DatabaseCA.CustomActions.DatabaseCA > > Begin DatabaseCA > > Connecton String: Data Source=source;Packet > > Size=4096;Uid=sqluser;Pwd=mypassword > > > > I as well have a custom action and HideTarget does nothing. > > > > > > On Thu, May 2, 2013 at 4:53 PM, Chad Petersen > > wrote: > > > > > If possible paste in a snippet of your log file around where the > > > password is seen. I tried for a long time to hide passwords using > > > the > > same method. > > > But it was some built-in custom actions that were logging my > > > passwords rather than co
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
Replying to JeremiahF with the original problem - I replied to you to preserve most of the thread. Phil -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Friday, May 03, 2013 11:48 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file I was not using managed code custom actions... I was doing: Tried adding: HideTarget="yes" that didn't help NOT Installed This property was in a custom dialog: 1 It was the custom action " CA_WebAppPoolPassword.SetProperty " that was displaying the property in the MSI log file. Took it out and now the password is not being displayed in plain letters... Steve -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: May-03-13 2:27 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file The way it works in MSI isn't really mysterious. Basically the property name needs to be public (and that means it must be all uppercase). If WiX does its thing properly then you can open the generated MSI file with an editor such as Orca, look in the Properties table, and in the Property table there'll be a SecureCustomProperties property and your property name will be in that list. This works. If it didn't work then Microsoft would be all over it as a security bug. Generally speaking, people get account passwords from a MSI dialog and store it in a property such as MYPASSWORD, and then pass it to a custom action that uses it. However, you're using managed code custom actions, and it seems from the log that the (DTF?) code just does its own logging into the MSI log without caring whether there's a password in there. So it may be a DTF thing, not sure, and if it is then HideTarget etc won't help at all. The short answer is that if the DTF code is logging a connection string that typically contains a password, then it probably shouldn't. Phil -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Thursday, May 02, 2013 4:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Hi Steve, My requirements are strictly to use command line. Crazy? Maybe. I have to say I have seen this topic all over blogs. Seems like there is always a way, you just have to figure out how On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie wrote: > Hmm... I commented out my custom action that sets the property: > > > And ran the install, everything worked and my Web App Pool + Web site > launched without errors (would have failed if I didn't have a password > for the Web App Pool) > > However I do publish the property during the UI: > Order="9">1 (my web site info dialog page during install) > > I checked my MSI log file and there wasn't any viewable strings for > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. Its > value is '**' > > Publish your password within the UI area and see if that works... > (also commenting out your custom action to set the property > > Steve > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: May-02-13 6:29 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > Sure thing... > > Action start 17:26:56: CA_DBAction. > Action ended 17:26:56: CA_DBAction. Return value 1. > Action start 17:26:56: InstallFinalize. > SFXCA: Extracting custom action to temporary directory: > C:\WINDOWS\Installer\MSI1045.tmp-\ > SFXCA: Binding to CLR version v2.0.50727 Calling custom action > DatabaseCA!DatabaseCA.CustomActions.DatabaseCA > Begin DatabaseCA > Connecton String: Data Source=source;Packet > Size=4096;Uid=sqluser;Pwd=mypassword > > I as well have a custom action and HideTarget does nothing. > > > On Thu, May 2, 2013 at 4:53 PM, Chad Petersen > wrote: > > > If possible paste in a snippet of your log file around where the > > password is seen. I tried for a long time to hide passwords using > > the > same method. > > But it was some built-in custom actions that were logging my > > passwords rather than code I'd written myself. > > > > > Id="ExecuteSqlStrings" Hidden="yes"/> > > > > These were two entries that I made to make those extensions hide the > > data passed to them, such as my password. > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: Thursday, May 02, 2013 2:38 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > > > I have tried that and no luck. My MSI is installed via command line. > > > > I've even tried to give the property Id a value in case I missed > > something and still doesn't work. > > > > > /> > > > > My test system is running Server 2003
[WiX-users] Burn/Boostrapper WITHOUT .NET installer
Running Wix 3.6, I had to follow one of many examples on the net on adding to my code to check/install .NET 4.0, just to get my Setup to build. Here's the thing...I know Setup requires .NET to run, but I DON"T want to check for .NET, and I don't want to package the .NET installer. .NET is a Windows feature that is turned on by default on Windows Server platform that my applications runs on, and internally we check the .NET version anyway. We don't want to add an extra EXE to our deployment, and we don't want to embed it in our Setup. Is there a way to build a boostrapper without .NET checking? All the example code I have seen have the .NET / code. Is there an example of boostrapper code that doesn't require a .NET package? If I remove these Package statements, it doesn't compile either. Thanks, George -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
I'm repeating myself to attempt to make this clear. This appears to be the part of the log that you are worried about: = SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI1045.tmp-\ SFXCA: Binding to CLR version v2.0.50727 Calling custom action DatabaseCA!DatabaseCA.CustomActions.DatabaseCA Begin DatabaseCA Connecton String: Data Source=source;Packet Size=4096;Uid=sqluser;Pwd=mypassword == This is NOT coming from Windows Installer. The SFXCA (which I believe is DTF) custom action is logging the connection string that contains the password. Any discussion of HideTarget is irrelevant as this is not Windows Installer logging data, it is the custom action code. Phil -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Friday, May 03, 2013 3:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Steven, "Tried adding: HideTarget="yes" that didn't help" Indeed! I'm even tried to remove logging from the custom action and I still see the password... I've even checked MsiHiddenProperties and see that PASSWORD is listed along with CA_DBAction... Not in SecureCustomProperties... I added secure="yes" and now it is there.. Execute the installer with logging and it is still unsecure in plain text in the log. It must be between the MSI installer and the SQL connection that is being made. Thoughts? J On Fri, May 3, 2013 at 1:48 PM, Steven Ogilvie wrote: > I was not using managed code custom actions... > > I was doing: > > > Property="CA_WebAppPoolPassword." > Value="WEBAPPPOOL_PASSWORD=[WEBAPPPOOL_PASSWORD]"/> > Tried adding: HideTarget="yes" that didn't help > >After="CA_DataBasePassword.SetProperty">NOT Installed > > This property was in a custom dialog: > Y="152" Text="Web App Pool user password:" Transparent="yes" NoPrefix="yes" > /> > Y="152" Property="WEBAPPPOOL_PASSWORD" Password="yes" TabSkip="no" /> > Order="9">1 > > It was the custom action " CA_WebAppPoolPassword.SetProperty " that > was displaying the property in the MSI log file. > > Took it out and now the password is not being displayed in plain letters... > > Steve > > > -Original Message- > From: Phil Wilson [mailto:phil.wil...@mvps.org] > Sent: May-03-13 2:27 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI > log file > > The way it works in MSI isn't really mysterious. Basically the > property name needs to be public (and that means it must be all > uppercase). If WiX does its thing properly then you can open the > generated MSI file with an editor such as Orca, look in the Properties > table, and in the Property table there'll be a SecureCustomProperties > property and your property name will be in that list. > > This works. If it didn't work then Microsoft would be all over it as a > security bug. > > Generally speaking, people get account passwords from a MSI dialog and > store it in a property such as MYPASSWORD, and then pass it to a > custom action that uses it. > > However, you're using managed code custom actions, and it seems from > the log that the (DTF?) code just does its own logging into the MSI > log without caring whether there's a password in there. So it may be a > DTF thing, not sure, and if it is then HideTarget etc won't help at > all. The short answer is that if the DTF code is logging a connection > string that typically contains a password, then it probably shouldn't. > > Phil > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: Thursday, May 02, 2013 4:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI > log file > > Hi Steve, > > My requirements are strictly to use command line. Crazy? Maybe. I have > to say I have seen this topic all over blogs. Seems like there is > always a way, you just have to figure out how > > > On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie > wrote: > > > Hmm... I commented out my custom action that sets the property: > > > > > > And ran the install, everything worked and my Web App Pool + Web > > site launched without errors (would have failed if I didn't have a > > password for the Web App Pool) > > > > However I do publish the property during the UI: > > > Order="9">1 (my web site info dialog page during install) > > > > I checked my MSI log file and there wasn't any viewable strings for > > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. > > Its value is '**' > > > > Publish your password within the UI area and see if that works... > > (also commenting out your custom action to set the property > > > > Steve > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: May
[WiX-users] Bundle Package Install Failure
Hello,One of our clients is encountering a setup failure with the following
msg: '0X80070002 - The system cannot find the file specified.'The log file is
below. The install scope is perMachine. Any ideas on why it would be failing
when trying to cache the bundle? This is the first time we've encountered this
after many successful installations and is rather urgent. Any insight would be
greatly appreciated... [063C:11BC][2013-05-03T19:00:08]i001: Burn v3.7.1224.0,
Windows v6.1 (Build 7601: Service Pack 1), path:
C:\Systems\Product_1\Product_1\Setup.exe, cmdline: '-burn.unelevated
BurnPipe.{1DE19E8A-81A6-4AA5-BF48-70A9F6456F73}
{6B32BA48-178D-44AA-B502-0EE1BD74773C} 716'
[063C:11BC][2013-05-03T19:00:08]i000: Setting string variable 'WixBundleLog' to
value 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008.log'
[063C:11BC][2013-05-03T19:00:08]i000: Setting string variable
'WixBundleOriginalSource' to value 'C:\Systems\Product_1\Product_1\Setup.exe'
[063C:11BC][2013-05-03T19:00:08]i052: Condition '((VersionNT >= v5.1) AND
(ServicePackLevel >= 3)) OR ((VersionNT >= v5.2) AND (ServicePackLevel >= 2))
OR (VersionNT >= v6.0)' evaluates to true.
[063C:11BC][2013-05-03T19:00:08]i000: Setting string variable 'WixBundleName'
to value 'ProductName'
[063C:11BC][2013-05-03T19:00:09]i100: Detect begin, 5 packages
[063C:11BC][2013-05-03T19:00:09]i000: Setting string variable
'NETFRAMEWORK40CLIENT' to value '1'
[063C:11BC][2013-05-03T19:00:09]i052: Condition 'NETFRAMEWORK40CLIENT'
evaluates to true.
[063C:11BC][2013-05-03T19:00:09]i101: Detected package: NetFx40ClientRedist,
state: Present, cached: None
[063C:11BC][2013-05-03T19:00:09]i101: Detected package: Drivers64bit, state:
Absent, cached: None
[063C:11BC][2013-05-03T19:00:09]i101: Detected package: Drivers32bit, state:
Absent, cached: None
[063C:11BC][2013-05-03T19:00:09]i101: Detected package: App64bit, state:
Absent, cached: None
[063C:11BC][2013-05-03T19:00:09]i101: Detected package: App32bit, state:
Absent, cached: None
[063C:11BC][2013-05-03T19:00:09]i199: Detect complete, result: 0x0
[063C:11BC][2013-05-03T19:00:12]i200: Plan begin, 5 packages, action: Install
[063C:11BC][2013-05-03T19:00:12]w321: Skipping dependency registration on
package with no dependency providers: NetFx40ClientRedist
[063C:11BC][2013-05-03T19:00:12]i052: Condition 'VersionNT64' evaluates to true.
[063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
'WixBundleRollbackLog_Drivers64bit' to value
'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_0_Drivers64bit_rollback.log'
[063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
'WixBundleLog_Drivers64bit' to value
'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_0_Drivers64bit.log'
[063C:11BC][2013-05-03T19:00:12]i052: Condition 'NOT VersionNT64' evaluates to
false.
[063C:11BC][2013-05-03T19:00:12]i052: Condition 'VersionNT64' evaluates to true.
[063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
'WixBundleRollbackLog_App64bit' to value
'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_1_App64bit_rollback.log'
[063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
'WixBundleLog_App64bit' to value
'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_1_App64bit.log'
[063C:11BC][2013-05-03T19:00:12]i052: Condition 'NOT VersionNT64' evaluates to
false.
[063C:11BC][2013-05-03T19:00:12]i201: Planned package: NetFx40ClientRedist,
state: Present, default requested: Present, ba requested: Present, execute:
None, rollback: None, cache: No, uncache: No, dependency: None
[063C:11BC][2013-05-03T19:00:12]i201: Planned package: Drivers64bit, state:
Absent, default requested: Present, ba requested: Present, execute: Install,
rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[063C:11BC][2013-05-03T19:00:12]i201: Planned package: Drivers32bit, state:
Absent, default requested: Absent, ba requested: Absent, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[063C:11BC][2013-05-03T19:00:12]i201: Planned package: App64bit, state: Absent,
default requested: Present, ba requested: Present, execute: Install, rollback:
Uninstall, cache: Yes, uncache: No, dependency: Register
[063C:11BC][2013-05-03T19:00:12]i201: Planned package: App32bit, state: Absent,
default requested: Absent, ba requested: Absent, execute: None, rollback: None,
cache: No, uncache: No, dependency: None
[063C:11BC][2013-05-03T19:00:12]i299: Plan complete, result: 0x0
[063C:11BC][2013-05-03T19:00:12]i300: Apply begin
[02CC:0654][2013-05-03T19:00:12]i360: Creating a system restore point.
[02CC:0654][2013-05-03T19:00:23]i361: Created a system restore point.
[02CC:0654][2013-05-03T19:00:23]i000: Caching bundle from:
'C:\Users\manager\AppData\Local\Temp\{ff8d5642-a119-4dfd-bf71-b8f8c7ed0617}\.be\Setup.exe'
to: 'C:\ProgramData\Package
Cache\{ff8d5642-a119-4dfd-bf71-b8f8c7ed0617}\Setup.exe'
[02CC:0654][2013-05-03T19:00:23
[WiX-users] Understanding Burn log cmdline
I'm using Burn v3.7.1224.0. What is the meaning of the following cmdline
present in the install log:
cmdline: '-burn.unelevated BurnPipe.{BA274BA7-1C44-402F-9E0C-5919915C3ADC}
{1B81FC8C-86AE-416C-AD37-DC7B377EDBCB} 716'
In other words, under what circumstances would a user execute the installer
that would produce such a cmdline in the log?
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
Aha I stand corrected :) have a good weekend all -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: May-03-13 7:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Replying to JeremiahF with the original problem - I replied to you to preserve most of the thread. Phil -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Friday, May 03, 2013 11:48 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file I was not using managed code custom actions... I was doing: Tried adding: HideTarget="yes" that didn't help NOT Installed This property was in a custom dialog: 1 It was the custom action " CA_WebAppPoolPassword.SetProperty " that was displaying the property in the MSI log file. Took it out and now the password is not being displayed in plain letters... Steve -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: May-03-13 2:27 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file The way it works in MSI isn't really mysterious. Basically the property name needs to be public (and that means it must be all uppercase). If WiX does its thing properly then you can open the generated MSI file with an editor such as Orca, look in the Properties table, and in the Property table there'll be a SecureCustomProperties property and your property name will be in that list. This works. If it didn't work then Microsoft would be all over it as a security bug. Generally speaking, people get account passwords from a MSI dialog and store it in a property such as MYPASSWORD, and then pass it to a custom action that uses it. However, you're using managed code custom actions, and it seems from the log that the (DTF?) code just does its own logging into the MSI log without caring whether there's a password in there. So it may be a DTF thing, not sure, and if it is then HideTarget etc won't help at all. The short answer is that if the DTF code is logging a connection string that typically contains a password, then it probably shouldn't. Phil -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Thursday, May 02, 2013 4:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Hi Steve, My requirements are strictly to use command line. Crazy? Maybe. I have to say I have seen this topic all over blogs. Seems like there is always a way, you just have to figure out how On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie wrote: > Hmm... I commented out my custom action that sets the property: > > > And ran the install, everything worked and my Web App Pool + Web site > launched without errors (would have failed if I didn't have a password > for the Web App Pool) > > However I do publish the property during the UI: > Order="9">1 (my web site info dialog page during install) > > I checked my MSI log file and there wasn't any viewable strings for > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. Its > value is '**' > > Publish your password within the UI area and see if that works... > (also commenting out your custom action to set the property > > Steve > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: May-02-13 6:29 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > Sure thing... > > Action start 17:26:56: CA_DBAction. > Action ended 17:26:56: CA_DBAction. Return value 1. > Action start 17:26:56: InstallFinalize. > SFXCA: Extracting custom action to temporary directory: > C:\WINDOWS\Installer\MSI1045.tmp-\ > SFXCA: Binding to CLR version v2.0.50727 Calling custom action > DatabaseCA!DatabaseCA.CustomActions.DatabaseCA > Begin DatabaseCA > Connecton String: Data Source=source;Packet > Size=4096;Uid=sqluser;Pwd=mypassword > > I as well have a custom action and HideTarget does nothing. > > > On Thu, May 2, 2013 at 4:53 PM, Chad Petersen > wrote: > > > If possible paste in a snippet of your log file around where the > > password is seen. I tried for a long time to hide passwords using > > the > same method. > > But it was some built-in custom actions that were logging my > > passwords rather than code I'd written myself. > > > > > Id="ExecuteSqlStrings" Hidden="yes"/> > > > > These were two entries that I made to make those extensions hide the > > data passed to them, such as my password. > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: Thursday, May 02, 2013 2:38 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
Your right Phil, it is a custom action that is creating the connection string, as per the log below, luckily our connection string is encrypted... For me, I took out the custom action to set the property and that solved my issue... (I am using a Publish element in the dialog the sets the property for Web App Pool password.. Sorry J, I don't think you will be able to get rid of it... -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: May-03-13 7:20 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file I'm repeating myself to attempt to make this clear. This appears to be the part of the log that you are worried about: = SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI1045.tmp-\ SFXCA: Binding to CLR version v2.0.50727 Calling custom action DatabaseCA!DatabaseCA.CustomActions.DatabaseCA Begin DatabaseCA Connecton String: Data Source=source;Packet Size=4096;Uid=sqluser;Pwd=mypassword == This is NOT coming from Windows Installer. The SFXCA (which I believe is DTF) custom action is logging the connection string that contains the password. Any discussion of HideTarget is irrelevant as this is not Windows Installer logging data, it is the custom action code. Phil -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Friday, May 03, 2013 3:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file Steven, "Tried adding: HideTarget="yes" that didn't help" Indeed! I'm even tried to remove logging from the custom action and I still see the password... I've even checked MsiHiddenProperties and see that PASSWORD is listed along with CA_DBAction... Not in SecureCustomProperties... I added secure="yes" and now it is there.. Execute the installer with logging and it is still unsecure in plain text in the log. It must be between the MSI installer and the SQL connection that is being made. Thoughts? J On Fri, May 3, 2013 at 1:48 PM, Steven Ogilvie wrote: > I was not using managed code custom actions... > > I was doing: > > > Property="CA_WebAppPoolPassword." > Value="WEBAPPPOOL_PASSWORD=[WEBAPPPOOL_PASSWORD]"/> > Tried adding: HideTarget="yes" that didn't help > >After="CA_DataBasePassword.SetProperty">NOT Installed > > This property was in a custom dialog: > Y="152" Text="Web App Pool user password:" Transparent="yes" NoPrefix="yes" > /> > Y="152" Property="WEBAPPPOOL_PASSWORD" Password="yes" TabSkip="no" /> > Order="9">1 > > It was the custom action " CA_WebAppPoolPassword.SetProperty " that > was displaying the property in the MSI log file. > > Took it out and now the password is not being displayed in plain letters... > > Steve > > > -Original Message- > From: Phil Wilson [mailto:phil.wil...@mvps.org] > Sent: May-03-13 2:27 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI > log file > > The way it works in MSI isn't really mysterious. Basically the > property name needs to be public (and that means it must be all > uppercase). If WiX does its thing properly then you can open the > generated MSI file with an editor such as Orca, look in the Properties > table, and in the Property table there'll be a SecureCustomProperties > property and your property name will be in that list. > > This works. If it didn't work then Microsoft would be all over it as a > security bug. > > Generally speaking, people get account passwords from a MSI dialog and > store it in a property such as MYPASSWORD, and then pass it to a > custom action that uses it. > > However, you're using managed code custom actions, and it seems from > the log that the (DTF?) code just does its own logging into the MSI > log without caring whether there's a password in there. So it may be a > DTF thing, not sure, and if it is then HideTarget etc won't help at > all. The short answer is that if the DTF code is logging a connection > string that typically contains a password, then it probably shouldn't. > > Phil > > -Original Message- > From: Jeremiahf [mailto:jeremi...@gmail.com] > Sent: Thursday, May 02, 2013 4:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI > log file > > Hi Steve, > > My requirements are strictly to use command line. Crazy? Maybe. I have > to say I have seen this topic all over blogs. Seems like there is > always a way, you just have to figure out how > > > On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie > wrote: > > > Hmm... I commented out my custom action that sets the property: > > > > > > And ran the install, everything worked and my Web App Pool + Web > > site launched wi
Re: [WiX-users] Bundle Package Install Failure
Do you have the correct version of .net installed?
On May 3, 2013, at 7:43 PM, - Arzola - wrote:
> Hello,One of our clients is encountering a setup failure with the following
> msg: '0X80070002 - The system cannot find the file specified.'The log file
> is below. The install scope is perMachine. Any ideas on why it would be
> failing when trying to cache the bundle? This is the first time we've
> encountered this after many successful installations and is rather urgent.
> Any insight would be greatly appreciated...
> [063C:11BC][2013-05-03T19:00:08]i001: Burn v3.7.1224.0, Windows v6.1 (Build
> 7601: Service Pack 1), path: C:\Systems\Product_1\Product_1\Setup.exe,
> cmdline: '-burn.unelevated BurnPipe.{1DE19E8A-81A6-4AA5-BF48-70A9F6456F73}
> {6B32BA48-178D-44AA-B502-0EE1BD74773C} 716'
> [063C:11BC][2013-05-03T19:00:08]i000: Setting string variable 'WixBundleLog'
> to value 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008.log'
> [063C:11BC][2013-05-03T19:00:08]i000: Setting string variable
> 'WixBundleOriginalSource' to value 'C:\Systems\Product_1\Product_1\Setup.exe'
> [063C:11BC][2013-05-03T19:00:08]i052: Condition '((VersionNT >= v5.1) AND
> (ServicePackLevel >= 3)) OR ((VersionNT >= v5.2) AND (ServicePackLevel >= 2))
> OR (VersionNT >= v6.0)' evaluates to true.
> [063C:11BC][2013-05-03T19:00:08]i000: Setting string variable 'WixBundleName'
> to value 'ProductName'
> [063C:11BC][2013-05-03T19:00:09]i100: Detect begin, 5 packages
> [063C:11BC][2013-05-03T19:00:09]i000: Setting string variable
> 'NETFRAMEWORK40CLIENT' to value '1'
> [063C:11BC][2013-05-03T19:00:09]i052: Condition 'NETFRAMEWORK40CLIENT'
> evaluates to true.
> [063C:11BC][2013-05-03T19:00:09]i101: Detected package: NetFx40ClientRedist,
> state: Present, cached: None
> [063C:11BC][2013-05-03T19:00:09]i101: Detected package: Drivers64bit, state:
> Absent, cached: None
> [063C:11BC][2013-05-03T19:00:09]i101: Detected package: Drivers32bit, state:
> Absent, cached: None
> [063C:11BC][2013-05-03T19:00:09]i101: Detected package: App64bit, state:
> Absent, cached: None
> [063C:11BC][2013-05-03T19:00:09]i101: Detected package: App32bit, state:
> Absent, cached: None
> [063C:11BC][2013-05-03T19:00:09]i199: Detect complete, result: 0x0
> [063C:11BC][2013-05-03T19:00:12]i200: Plan begin, 5 packages, action: Install
> [063C:11BC][2013-05-03T19:00:12]w321: Skipping dependency registration on
> package with no dependency providers: NetFx40ClientRedist
> [063C:11BC][2013-05-03T19:00:12]i052: Condition 'VersionNT64' evaluates to
> true.
> [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> 'WixBundleRollbackLog_Drivers64bit' to value
> 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_0_Drivers64bit_rollback.log'
> [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> 'WixBundleLog_Drivers64bit' to value
> 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_0_Drivers64bit.log'
> [063C:11BC][2013-05-03T19:00:12]i052: Condition 'NOT VersionNT64' evaluates
> to false.
> [063C:11BC][2013-05-03T19:00:12]i052: Condition 'VersionNT64' evaluates to
> true.
> [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> 'WixBundleRollbackLog_App64bit' to value
> 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_1_App64bit_rollback.log'
> [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> 'WixBundleLog_App64bit' to value
> 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_1_App64bit.log'
> [063C:11BC][2013-05-03T19:00:12]i052: Condition 'NOT VersionNT64' evaluates
> to false.
> [063C:11BC][2013-05-03T19:00:12]i201: Planned package: NetFx40ClientRedist,
> state: Present, default requested: Present, ba requested: Present, execute:
> None, rollback: None, cache: No, uncache: No, dependency: None
> [063C:11BC][2013-05-03T19:00:12]i201: Planned package: Drivers64bit, state:
> Absent, default requested: Present, ba requested: Present, execute: Install,
> rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
> [063C:11BC][2013-05-03T19:00:12]i201: Planned package: Drivers32bit, state:
> Absent, default requested: Absent, ba requested: Absent, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> [063C:11BC][2013-05-03T19:00:12]i201: Planned package: App64bit, state:
> Absent, default requested: Present, ba requested: Present, execute: Install,
> rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
> [063C:11BC][2013-05-03T19:00:12]i201: Planned package: App32bit, state:
> Absent, default requested: Absent, ba requested: Absent, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> [063C:11BC][2013-05-03T19:00:12]i299: Plan complete, result: 0x0
> [063C:11BC][2013-05-03T19:00:12]i300: Apply begin
> [02CC:0654][2013-05-03T19:00:12]i360: Creating a system restore point.
> [02CC:0654][2013-05-03T19:00:23]i361: Created a system restore point.
> [02CC:06
Re: [WiX-users] Burn/Boostrapper WITHOUT .NET installer
Hi George, You can remove the dotnet reference in the chain and it would not install. Regards, Markus Am 04.05.2013 um 02:15 schrieb George Fleming : > Running Wix 3.6, I had to follow one of many examples on the net on adding > to my code to check/install .NET 4.0, just to get my Setup to > build. > > Here's the thing...I know Setup requires .NET to run, but I DON"T want to > check for .NET, and I don't want to package the .NET installer. .NET is a > Windows feature that is turned on by default on Windows Server platform that > my applications runs on, and internally we check the .NET version anyway. We > don't want to add an extra EXE to our deployment, and we don't want to embed > it in our Setup. Is there a way to build a boostrapper without .NET checking? > > All the example code I have seen have the .NET > / code. Is there an example of boostrapper > code that doesn't require a .NET package? If I remove these Package > statements, it doesn't compile either. > > Thanks, > > George > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle Package Install Failure
Yes. As seen below, the installer is detecting that the required .net
framework 4.0 is already present with no need to install.
[063C:11BC][2013-05-03T19:00:12]i201: Planned package: NetFx40ClientRedist,
state: Present, default requested: Present, ba requested: Present, execute:
None, rollback: None, cache: No, uncache: No, dependency: None
> CC: wix-users@lists.sourceforge.net
> From: jeremi...@gmail.com
> Date: Fri, 3 May 2013 22:51:15 -0500
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Bundle Package Install Failure
>
> Do you have the correct version of .net installed?
>
>
>
> On May 3, 2013, at 7:43 PM, - Arzola - wrote:
>
> > Hello,One of our clients is encountering a setup failure with the following
> > msg: '0X80070002 - The system cannot find the file specified.'The log file
> > is below. The install scope is perMachine. Any ideas on why it would be
> > failing when trying to cache the bundle? This is the first time we've
> > encountered this after many successful installations and is rather urgent.
> > Any insight would be greatly appreciated...
> > [063C:11BC][2013-05-03T19:00:08]i001: Burn v3.7.1224.0, Windows v6.1 (Build
> > 7601: Service Pack 1), path: C:\Systems\Product_1\Product_1\Setup.exe,
> > cmdline: '-burn.unelevated BurnPipe.{1DE19E8A-81A6-4AA5-BF48-70A9F6456F73}
> > {6B32BA48-178D-44AA-B502-0EE1BD74773C} 716'
> > [063C:11BC][2013-05-03T19:00:08]i000: Setting string variable
> > 'WixBundleLog' to value
> > 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008.log'
> > [063C:11BC][2013-05-03T19:00:08]i000: Setting string variable
> > 'WixBundleOriginalSource' to value
> > 'C:\Systems\Product_1\Product_1\Setup.exe'
> > [063C:11BC][2013-05-03T19:00:08]i052: Condition '((VersionNT >= v5.1) AND
> > (ServicePackLevel >= 3)) OR ((VersionNT >= v5.2) AND (ServicePackLevel >=
> > 2)) OR (VersionNT >= v6.0)' evaluates to true.
> > [063C:11BC][2013-05-03T19:00:08]i000: Setting string variable
> > 'WixBundleName' to value 'ProductName'
> > [063C:11BC][2013-05-03T19:00:09]i100: Detect begin, 5 packages
> > [063C:11BC][2013-05-03T19:00:09]i000: Setting string variable
> > 'NETFRAMEWORK40CLIENT' to value '1'
> > [063C:11BC][2013-05-03T19:00:09]i052: Condition 'NETFRAMEWORK40CLIENT'
> > evaluates to true.
> > [063C:11BC][2013-05-03T19:00:09]i101: Detected package:
> > NetFx40ClientRedist, state: Present, cached: None
> > [063C:11BC][2013-05-03T19:00:09]i101: Detected package: Drivers64bit,
> > state: Absent, cached: None
> > [063C:11BC][2013-05-03T19:00:09]i101: Detected package: Drivers32bit,
> > state: Absent, cached: None
> > [063C:11BC][2013-05-03T19:00:09]i101: Detected package: App64bit, state:
> > Absent, cached: None
> > [063C:11BC][2013-05-03T19:00:09]i101: Detected package: App32bit, state:
> > Absent, cached: None
> > [063C:11BC][2013-05-03T19:00:09]i199: Detect complete, result: 0x0
> > [063C:11BC][2013-05-03T19:00:12]i200: Plan begin, 5 packages, action:
> > Install
> > [063C:11BC][2013-05-03T19:00:12]w321: Skipping dependency registration on
> > package with no dependency providers: NetFx40ClientRedist
> > [063C:11BC][2013-05-03T19:00:12]i052: Condition 'VersionNT64' evaluates to
> > true.
> > [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> > 'WixBundleRollbackLog_Drivers64bit' to value
> > 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_0_Drivers64bit_rollback.log'
> > [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> > 'WixBundleLog_Drivers64bit' to value
> > 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_0_Drivers64bit.log'
> > [063C:11BC][2013-05-03T19:00:12]i052: Condition 'NOT VersionNT64' evaluates
> > to false.
> > [063C:11BC][2013-05-03T19:00:12]i052: Condition 'VersionNT64' evaluates to
> > true.
> > [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> > 'WixBundleRollbackLog_App64bit' to value
> > 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_1_App64bit_rollback.log'
> > [063C:11BC][2013-05-03T19:00:12]i000: Setting string variable
> > 'WixBundleLog_App64bit' to value
> > 'C:\Users\manager\AppData\Local\Temp\ProductName_20130503190008_1_App64bit.log'
> > [063C:11BC][2013-05-03T19:00:12]i052: Condition 'NOT VersionNT64' evaluates
> > to false.
> > [063C:11BC][2013-05-03T19:00:12]i201: Planned package: NetFx40ClientRedist,
> > state: Present, default requested: Present, ba requested: Present, execute:
> > None, rollback: None, cache: No, uncache: No, dependency: None
> > [063C:11BC][2013-05-03T19:00:12]i201: Planned package: Drivers64bit, state:
> > Absent, default requested: Present, ba requested: Present, execute:
> > Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
> > [063C:11BC][2013-05-03T19:00:12]i201: Planned package: Drivers32bit, state:
> > Absent, default requested: Absent, ba requested: Absent, execute: None,
> > rollback: None, cache: No, uncache: No, dependency
Re: [WiX-users] Understanding Burn log cmdline
If they launched the bundle elevated.
On Fri, May 3, 2013 at 7:08 PM, Vic Allen wrote:
> I'm using Burn v3.7.1224.0. What is the meaning of the following cmdline
> present in the install log:
> cmdline: '-burn.unelevated BurnPipe.{BA274BA7-1C44-402F-9E0C-5919915C3ADC}
> {1B81FC8C-86AE-416C-AD37-DC7B377EDBCB} 716'
>
> In other words, under what circumstances would a user execute the
> installer that would produce such a cmdline in the log?
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log file
Is the message showing the password actually being logged by the custom action itself? On Fri, May 3, 2013 at 3:53 PM, Jeremiahf wrote: > Steven, > > "Tried adding: HideTarget="yes" that didn't help" Indeed! > > I'm even tried to remove logging from the custom action and I still see the > password... > I've even checked MsiHiddenProperties and see that PASSWORD is listed along > with CA_DBAction... Not in SecureCustomProperties... I added secure="yes" > and now it is there.. Execute the installer with logging and it is still > unsecure in plain text in the log. It must be between the MSI installer and > the SQL connection that is being made. Thoughts? > > J > > > On Fri, May 3, 2013 at 1:48 PM, Steven Ogilvie >wrote: > > > I was not using managed code custom actions... > > > > I was doing: > > > > > > > Property="CA_WebAppPoolPassword." > > Value="WEBAPPPOOL_PASSWORD=[WEBAPPPOOL_PASSWORD]"/> > > Tried adding: HideTarget="yes" that didn't help > > > >> After="CA_DataBasePassword.SetProperty">NOT Installed > > > > This property was in a custom dialog: > > > Y="152" Text="Web App Pool user password:" Transparent="yes" > NoPrefix="yes" > > /> > > > Y="152" Property="WEBAPPPOOL_PASSWORD" Password="yes" TabSkip="no" /> > > > Order="9">1 > > > > It was the custom action " CA_WebAppPoolPassword.SetProperty " that was > > displaying the property in the MSI log file. > > > > Took it out and now the password is not being displayed in plain > letters... > > > > Steve > > > > > > -Original Message- > > From: Phil Wilson [mailto:phil.wil...@mvps.org] > > Sent: May-03-13 2:27 PM > > To: 'General discussion for Windows Installer XML toolset.' > > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log > > file > > > > The way it works in MSI isn't really mysterious. Basically the property > > name needs to be public (and that means it must be all uppercase). If WiX > > does its thing properly then you can open the generated MSI file with an > > editor such as Orca, look in the Properties table, and in the Property > > table there'll be a SecureCustomProperties property and your property > name > > will be in that list. > > > > This works. If it didn't work then Microsoft would be all over it as a > > security bug. > > > > Generally speaking, people get account passwords from a MSI dialog and > > store it in a property such as MYPASSWORD, and then pass it to a custom > > action that uses it. > > > > However, you're using managed code custom actions, and it seems from the > > log that the (DTF?) code just does its own logging into the MSI log > without > > caring whether there's a password in there. So it may be a DTF thing, not > > sure, and if it is then HideTarget etc won't help at all. The short > answer > > is that if the DTF code is logging a connection string that typically > > contains a password, then it probably shouldn't. > > > > Phil > > > > -Original Message- > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > Sent: Thursday, May 02, 2013 4:17 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] WiX-users] Hide/blank out Passwords in MSI log > > file > > > > Hi Steve, > > > > My requirements are strictly to use command line. Crazy? Maybe. I have to > > say I have seen this topic all over blogs. Seems like there is always a > > way, you just have to figure out how > > > > > > On Thu, May 2, 2013 at 5:43 PM, Steven Ogilvie > > wrote: > > > > > Hmm... I commented out my custom action that sets the property: > > > > > > > > > And ran the install, everything worked and my Web App Pool + Web site > > > launched without errors (would have failed if I didn't have a password > > > for the Web App Pool) > > > > > > However I do publish the property during the UI: > > > > > Order="9">1 (my web site info dialog page during install) > > > > > > I checked my MSI log file and there wasn't any viewable strings for > > > the WebAppPool_Password it was all: WEBAPPPOOL_PASSWORD property. Its > > > value is '**' > > > > > > Publish your password within the UI area and see if that works... > > > (also commenting out your custom action to set the property > > > > > > Steve > > > > > > -Original Message- > > > From: Jeremiahf [mailto:jeremi...@gmail.com] > > > Sent: May-02-13 6:29 PM > > > To: General discussion for Windows Installer XML toolset. > > > Subject: Re: [WiX-users] Hide/blank out Passwords in MSI log file > > > > > > Sure thing... > > > > > > Action start 17:26:56: CA_DBAction. > > > Action ended 17:26:56: CA_DBAction. Return value 1. > > > Action start 17:26:56: InstallFinalize. > > > SFXCA: Extracting custom action to temporary directory: > > > C:\WINDOWS\Installer\MSI1045.tmp-\ > > > SFXCA: Binding to CLR version v2.0.50727 Calling custom action > > > DatabaseCA!DatabaseCA.CustomActions.DatabaseCA > > > Begin DatabaseCA > > > Connecton String: Data Source=source;Packet > > > Size=4096;Uid=sqluser;Pwd=mypasswor
