[WiX-users] 32 vs 64 bit MSI?
I know this isn't really specifically WiX related, but I also know you guys know lots of MSI and installer stuff. I'm seeing references to 32-bit MSIs vs. 64-bit MSIs. Is there actually something inherently architecture-related about an MSI, or is it just a matter of the 32/64 nature of the programs it installs? I could see it getting messy figuring out which part of the registry to put stuff in for 32 vs. 64 bit programs on a 64-bit platform, so I guess Windows Installer would need to know where to do registry entries. But how does it tell? Thanks! -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Windows Installer Cache - gone!
Hi, all. I know you're going to just shake your head at this, but here it is. I create installers for one of many products that install onto a group of roughly 14,000 systems at my employer. Some of these systems have drives that are small by modern standards, and thanks to a weird partitioning scheme, the drive with the Windows directory is seldom more than 30 - 40 GB. I've just found out that, in order to get enough drive space to keep running, our support team sometimes deletes the contents of the windows\installer directory - the Windows Installer Cache. In a bit of reading on the Microsoft site - https://support.microsoft.com/en-us/kb/2667628 - this is something of a fatal injury for the Windows Installer in terms of uninstall or repair of already installed packages. Despite that, nobody is going to reinstall Windows on these devices - they're scattered around the country connected to slow DSL lines for the most part, and nobody local is willing or able to do that. I don't really care about the bigger problem, but I'm wondering if anyone has any thoughts about authoring packages that might have to install into that mess, or might have to be used to upgrade an already installed package whose cache contents got deleted. (Different ProductCode, same UpgradeCode.) Thanks, Walt -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows Installer Cache - gone!
I don't do patches. Nobody does patches for this platform - it isn't worth the effort. The MSIs aren't installed interactively - ever. Strictly Microsoft system management tools and our own home-grown extensions. We have the worst case of NIH syndrome ever. Thanks for the feedback, mostly just wanted a sanity check from someone more experienced with this stuff that there's really nothing to be done. :) On Thu, Jun 18, 2015 at 11:27 AM, Phil Wilson phildgwil...@gmail.com wrote: If memory serves, I think that Windows will ask for the original install media if the cached MSI is missing. That should be testable. I don't think there's anything that can be done in the MSI file to help, so I woouldn't worry about different authoring approaches. Patches are more problematical. If there is an installed product that was then patched, the base MSI can be provided, but since the installed product consists of MSI+patches, the actual installed product can't be rebuilt. It may ask for the patch in that situation. It looks like you have some testing to do. --- Phil Wilson On Thu, Jun 18, 2015 at 8:23 AM, Walter Dexter wfdex...@gmail.com wrote: Hi, all. I know you're going to just shake your head at this, but here it is. I create installers for one of many products that install onto a group of roughly 14,000 systems at my employer. Some of these systems have drives that are small by modern standards, and thanks to a weird partitioning scheme, the drive with the Windows directory is seldom more than 30 - 40 GB. I've just found out that, in order to get enough drive space to keep running, our support team sometimes deletes the contents of the windows\installer directory - the Windows Installer Cache. In a bit of reading on the Microsoft site - https://support.microsoft.com/en-us/kb/2667628 - this is something of a fatal injury for the Windows Installer in terms of uninstall or repair of already installed packages. Despite that, nobody is going to reinstall Windows on these devices - they're scattered around the country connected to slow DSL lines for the most part, and nobody local is willing or able to do that. I don't really care about the bigger problem, but I'm wondering if anyone has any thoughts about authoring packages that might have to install into that mess, or might have to be used to upgrade an already installed package whose cache contents got deleted. (Different ProductCode, same UpgradeCode.) Thanks, Walt -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per-User Previlage To Write to Program Files
May want to just open up one of your InstallShield MSIs with Orca and see if you can tell how the applicable stuff is set. My experience with the more heavy-duty installers is that there's a lot of crap in their MSIs, but you might find something. On Fri, May 8, 2015 at 11:39 AM, Zig fnot-...@ziglar.me wrote: On 5/7/2015 11:04 PM, Scott Ferguson wrote: Hi, Have a look at InstallShield Limited in VS 2010 and up. Under the Application Information General Information section all I do is set the ALLUSERS switch to ALLUSERS=(Per-user installation). Then in the Application Files area I have it install to Program Files. When I run the .msi the UAC dialog comes up and I select Yes and it installs without issue. Yeah, I believe, technically, a true per-user installation should never trigger a UAC prompt. If you _need_ to replicate _that_ behavior in WiX, try removing the installScope declaration entirely, and set ALLUSERS=. That will probably cause Windows Installer to do a UAC bump, so you can access Program Files. That said, installing to Program Files really isn't per-user... and I suspect someone else on this list will be able to provide a better explanation of why trying to continue down the same path is a horrible idea, and if there are scenarios where it might break? The process is slightly different for Setup and Deployment but still similar that I set it to per-user and install to Program Files without issue. This is something for you to think about anyway. Also over the last 15 - 18 years I have never installed an application on any of my computers to anywhere other than Program Files; whether it was per-machine or not. I didn't know users/user name/AppData/Local/Programs existed until now. Just out of curiosity, are you accessing that by setting MSIINSTALLPERUSER = 1 ? -Zig -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per-User Previlage To Write to Program Files
Scott, There's little doubt that security on Windows has tightened up in recent versions. Have you been able to install as you describe in 7 and 8 or was that strictly XP? On May 7, 2015, at 10:04 PM, Scott Ferguson scott.fergu...@a2ktechnologies.co.nz wrote: Hi, Yes I've picked up that it probably shouldn't be possible. But I can assure you that I have been installing per-user installs to the Program Files directory for 8 years on this one product alone and using either Setup and Deployment or InstallShield it has never been an issue. Have a look at InstallShield Limited in VS 2010 and up. Under the Application Information General Information section all I do is set the ALLUSERS switch to ALLUSERS=(Per-user installation). Then in the Application Files area I have it install to Program Files. When I run the .msi the UAC dialog comes up and I select Yes and it installs without issue. The process is slightly different for Setup and Deployment but still similar that I set it to per-user and install to Program Files without issue. This is something for you to think about anyway. Also over the last 15 - 18 years I have never installed an application on any of my computers to anywhere other than Program Files; whether it was per-machine or not. I didn't know users/user name/AppData/Local/Programs existed until now. Anyway I am moving my app to users/user name/AppData/Local/Programs as I need to use Wix. BTW Wix is extremely cool! I am very greatful that it is available. :-) Kind regards Scott Ferguson Blackbox22 Senior Software Developer D: 09 2328 638 P: 0508 232 797 M: 027 256 7579 E: scott.fergu...@a2ktechnologies.co.nz W: www.a2ktechnologies.co.nz A: Unit 1, 74 France Street South, Newton, Auckland 1010 Legal Notice | Unsubscribe Confidentiality Notice This email may contain information that is confidential and is intended only for the use of the recipient above. Any distribution or copying or dissemination of the information contained in this email message is strictly prohibited. If you have received this email in error, please contact this office immediately by telephone, fax or email and delete the original message. Thank you. -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Friday, 8 May 2015 12:15 p.m. To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Per-User Previlage To Write to Program Files You have to be elevated to install to ProgramFiles. Your per-user MSI never should have been able to install to ProgramFiles unless you always launched it from an elevated process. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Scott Ferguson [mailto:scott.fergu...@a2ktechnologies.co.nz] Sent: Thursday, May 7, 2015 2:55 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Per-User Previlage To Write to Program Files Hi, I am using Wix 3.9.1208. I have an installer created earlier with Install Shield Limited Edition that installed as a per user package. I have been upgrading the original installation over the last two years. I now need to upgrade the program using Wix as I need the additional functionality Wix provides. The issue I am having is when I use Wix as the installer and I have the InstallScope attribute set to per-user I get an error message that says the installer has insufficient privileges to access this directory and the message is pointing to the Program Files/My Application directory. I have done quite a bit of research on this over the last two days and I believe this issue has been brought up several times e.g. http://sourceforge.net/p/wix/mailman/search/?q=per-user+Program+Files+insufficient+privilege The answer seems to be to be either move the installation away from Program Files or to elevate the InstallScope attribute to perMachine. I can confirm that perMachine does fix the privileges issue but it is not a viable solution for me in this instance. Neither of those two options will work for me. 1) I cannot change the InstallScope attribute as I am creating an update so the InstallScope between the two versions need to be the same or it will install side-by-side instead of updating. 2) To change the location of the install directory means changes to settings and possibly the source code (I won't know until I test)! Does anyone know of a solution that will allow me to do a per-user install to Program Files? Kind regards Scott Ferguson -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and
Re: [WiX-users] How to include an entire folder as payload for my custom bootstrapper application?
I think you'd have to rig heat to run as part of package creation. Personally I never managed to get it to do what I wanted, but I know people do. On Apr 19, 2015, at 11:06 AM, ronif ro...@microsoft.com wrote: Hi Rob, Thanks for your answer, So there is no way to include a folder without specifying all the files inside? I wanted to avoid that because those files might change and I want to include them all automatically. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-include-an-entire-folder-as-payload-for-my-custom-bootstrapper-application-tp7599907p7600011.html Sent from the wix-users mailing list archive at Nabble.com. -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrades
I suspect I'm stuck but thought I'd ask.
I have two existing MSIs, call them Base.msi and Dell.msi. They install
separate facets of my product - the base files, then additional files
needed to support particular Dell hardware.
I now want to create a new single MSI that replaces Base.msi and
Dell.msi. Call it both.msi.
Is there a way, strictly in both.msi, to keep Base.msi and Dell.msi
from installing if both.msi is already installed?
As I have both.msi defined now, both.msi has the same UpgradeCode as
base.msi. The relevant (I think) parts of my WiX package are below.
Any advice or suggestions would be much appreciated.
These are in a .wxi:
Include
?define ProductName=Blah blah name blah blah ?
?define UpgradeCode={1F67D6DC-04DB-4D4F-8797-F0F55DCAFBCC} ?
?define ProductVersion=1.2.0 ? !-- Product version. --
?define MaxVersion=1.2.0 ? !-- Highest version this should upgrade.
Most of the time, should be same as ProductVersion.--
?define MinVersion=1.0.0 ? !-- Lowest version this should upgrade. --
?define DellUpgradeCode={FB3ED31C-630E-4861-91A3-5BF83761C5CD} ?
?define DellMaxVersion=1.0.3 ? !-- Highest version this should
upgrade. 1.0.3 is the final separate Dell MSI version. --
?define DellMinVersion=1.0.0 ? !-- Lowest version this should upgrade.
I don't think 1.0.0 was ever distributed but doesn't matter. --
/Include
Product
Id=*
Name=$(var.ProductName)
Language=1033
Version=$(var.ProductVersion)
Manufacturer=Company USA LLC
UpgradeCode=$(var.UpgradeCode)
Package
InstallerVersion=300
Compressed=yes
InstallScope=perMachine
Comments=No detail.
Description=Blah Blah.
Manufacturer=Blah blah blah /
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion
IgnoreRemoveFailure=yes
IncludeMinimum=yes
IncludeMaximum=yes
Minimum=$(var.MinVersion)
Maximum=$(var.MaxVersion)
MigrateFeatures=yes
Property=UPGRADE_1
/UpgradeVersion
/Upgrade
Upgrade Id=$(var.DellUpgradeCode)
UpgradeVersion
IgnoreRemoveFailure=yes
IncludeMinimum=yes
IncludeMaximum=yes
Minimum=$(var.DellMinVersion)
Maximum=$(var.DellMaxVersion)
MigrateFeatures=yes
Property=UPGRADE_DELL
/UpgradeVersion
/Upgrade
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Installer - Copy folder from DVD to HDD and then run bootstrapper from HDD folder
What you're describing is vaguely similar to how we do things. There's a single server in each of our locations that contains MSIs that are installed on other systems in that location across the network. I just package the client MSIs in a bigger MSI, and install the bigger MSI on the server. WindowsInstaller treats the client MSIs just like any other file and puts them in place. The clients then pull their MSIs from the server. Our scenario is slightly different than yours, in that we don't ever install the client MSIs on the server. On Tue, Jan 27, 2015 at 10:20 AM, Tall Tyke chris.mo...@eque2.com wrote: I currently have a bootsrapper exe and a msi (the latter rarely changes, but the former gets updated regularly), both written in WiX 3.9 and we now have a request to make the install process even easier for the user, so I was wondering if the following scenario is possible ?! The DVD folder structure would contain : Installers [Folder] SQL Server [Folder] setup.exe Running the setup.exe, it will install SQL express; using the sql installers located in the SQL Server folder on the DVD - I can do this. It will then ask the user for the name of a folder; which it will then create ( ideally - but not essential yet - share it ! ). eg C:\MyFolder It will then COPY the Installers folder ( obviously it's content ) from the DVD into the folder eg C:\MyFolder\Installers It will then run my existing bootstrapper exe that will now live in C:\MyFolder\Installers\MyBootInstaller.exe and that exe will then run my installer, which will also be in C:\MyFolder\Installers\MyInstaller.msi The reason we want this, is because then the next person to install the product on their PC, will just install the MyBootInstaller.exe from the folder and never actually see the DVD; hence why the folder ideally needs to be shared. Also we want to run the SQL installer from the DVD, so we don't waste time copying the SQL installers to the folder ( as they are over 1.5gb in size ) !! Any hints tips on how I can accomplish this, would be gratefully received; but obviously if someone tells me that this is not possible, then I'll have to have a re-think, but hopefully won't have wasted too much time getting to that conclusion !! Cheers, Chris. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Installer-Copy-folder-from-DVD-to-HDD-and-then-run-bootstrapper-from-HDD-folder-tp7599027.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] can WiX be used to create windows service for any console application?
You probably don't have sufficient permission. Try running your MSI as Administrator. On Jul 9, 2014, at 7:19 AM, Pritesh Acharya priteshacha...@gmail.com wrote: I am new to WiX and I've been trying to use it to create a installer for a basic console application which just prints hello world in console and hangs there. My question is, can WiX be used to create windows service for any console application? I know that it can be used to create service installer for windows service application. i did create installer for windows service for the console application, and while installing i get stuck in the middle and after a while it shows following error: Service failed to start. Verify that you have sufficient privileges to start system services -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] simple re-packaging of a 3rd party redistributable
I do this quite a lot. So long as the setup.exe isn't masking an MSI, its a simple matter of installing the files to the target system and doing a custom action to invoke it. On Jun 15, 2014 6:14 PM, Nicolás Alvarez nicolas.alva...@gmail.com wrote: 2014-06-15 14:36 GMT-03:00 Moyer, Andy andy.mo...@cpii.com: What I need help with is, how can I make an .msi or .exe that bundles up all the files shown in the attached screen shot Attached files don't reach the mailing list. Please upload the screenshot to an image-sharing website and post the link instead. -- Nicolás -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Options to run temporary exe during install?
I've only done it with VBS, which I know isn't recommended, etc, but to do that, I have the below. If you're really using calc.exe in your testing, are you sure it isn't working? Sometimes weirdness happens with user contexts - did you check to see if calc.exe is running on your system under a different user, who perhaps doesn't have screen access? I'd write a little program that just creates a file with the current date and time and try testing with that. I notice that you have CustomAction in the InstallExecuteSequence. I don't know if that's just a posting error, but it should be Custom Action with a space. In any case, here's how I'm running a VBS that most definitely does work. Hopefully I'm being of some assistance... :) Binary Id=CreateHostsVBS SourceFile=../../scripts/generateHostsFile.vbs / CustomAction Id=CA_CreateHostsVBS BinaryKey=CreateHostsVBS VBScriptCall=Run Execute=deferred Return=check / InstallExecuteSequence Custom Action=CA_CreateHostsVBS After=InstallFiles NOT Installed /Custom /InstallExecuteSequence On Wed, Jun 4, 2014 at 11:12 AM, Shane Corbin shane_cor...@selinc.com wrote: I suspect I would need to somehow extract the executable out of the binary table before I can use it. I'm not sure how to accomplish this though. I was attempting to do something like: Binary Id=CalcID SourceFile=C:\Windows\system32\calc.exe / CustomAction Id=CA1ID Return=check HideTarget=no Execute=deferred Impersonate=no ExeCommand= BinaryKey=CalcID / InstallExecuteSequence CustomAction=quot;CA1IDquot; After=quot;InstallInitializequot; NOT Installed /Custom /InstallExecuteSequence That does not work for me. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Options-to-run-temporary-exe-during-install-tp7595004p7595036.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] All or nothing delayed install?
*Tons of background...* I have an MSI that installs three executables, a bunch of image files, and a few INI files. On the target device, which is similar to a cash register, two of the executables (A1.exe and A2.exe) are always running, but the third executable (N.exe) runs for about 10 seconds every 5 minutes. (A is for always, N is for Nearly Never.) I've got the MSI working such that it delays the install any EXE files it can't replace until the next reboot, but doesn't actually do the reboot. The effect of this is that until the daily 4:00 AM reboot occurs, I have version 1 of A1.exe and A2.exe running, and version 2 of N.exe running occasionally, along with the version 2 image and INI files. When a new release of software comes out, all three are always rebuild and issued. I don't want our QA team to have to test the split-version combo. In looking at the system in this state, it looks like Windows Installer is actually installing all the V2 files, but it's leaving the V1 A1.exe and A2.exe files running and moving them to c:\config.msi\ and giving them some odd names. These are third party executables so I can't make changes to them - for example to make them interact properly with the Windows 7 Restart Manager. I can guarantee that the OS will be Windows 7 or later, so I don't need to be concerned with Vista or XP. I could let it do a reboot, but that would necessitate a fair amount of communication with our end users, which we can skip if they don't notice the install happening. I also have a hook where I can run commands right before the daily 4:00 AM reboot, so I could use that to control the MSI installation, but it adds another layer of complication. *And now the question...* Is there a way to make Windows Installer delay installing all of the V2 files until A1.exe and A2.exe can actually start running, or should I just let it reboot or use my hook? -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Options to run temporary exe during install?
I don't have my packages on this system, so I can't look to see how I have it working, but I believe you'd use a Binary / to reference the executable, then a CustomAction with BinaryKey and ExeCommand attributes to run it, and let Windows Installer take care of the temporary nature of it. Since the Binary ... / doesn't have a directory for you to put the file in, it can't put it on the system. I suppose it might put it on the system somewhere, so if your requirement is that the exe isn't hanging around in a temporary folder somewhere, you would need to follow up on exactly how it works. Someone much more WiX-knowledgeable than I will no doubt chime in, but I didn't know how soon you were in need of at least a shove in the right direction. On Tue, Jun 3, 2014 at 7:02 PM, Shane Corbin shane_cor...@selinc.com wrote: I have an exe that I'd like the MSI to execute as part of the installation process. The exe does not need to remain on the system when installation is complete. This has to be a common thing to do. What is the common way to approach this? My original thought was to: 1) Copy the exe to [TempFolder] 2) use CAQuietExec to run the exe from [TempFolder] 3) use CAQuietExec to delete the exe from [TempFolder] What's the appropriate way to approach this? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Options-to-run-temporary-exe-during-install-tp7595004.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
I do this in some MSIs that we deploy strictly silently via Microsoft
system management stuff.
My upgrade block looks like this:
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion
IgnoreRemoveFailure=yes
IncludeMinimum=yes
IncludeMaximum=yes
Minimum=$(var.MinVersion)
Maximum=$(var.MaxVersion)
MigrateFeatures=yes
Property=UPGRADE_1
/UpgradeVersion
/Upgrade
And also this, which I think matters:
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence
Then I have a wxi file that I include that contains:
Include
?define ProductName=Wonder-product blah blah blah ?
?define UpgradeCode={USE-YOUR-OWN-UPGRADE-GUID} ?
?define ProductVersion=1.0.7.0 ? !-- Product version. --
?define MaxVersion=1.0.7.0 ? !-- Highest version this should upgrade.
Most of the time, should be same as ProductVersion.--
?define MinVersion=1.0.0.0 ? !-- Lowest version this should upgrade.
--
/Include
You don't really need the vars and the .wxi file - I just like having the
version numbers, upgrade code and product name all together instead of
scattered around.
I'm pretty sure this is all the stuff that matters to make this work, but
it's been months, and I pretty much just beat on it until it worked.
On Fri, May 30, 2014 at 11:03 AM, Ben Metheny benmeth...@gmail.com wrote:
I have a requirement to allow 'overwrite' of same version. I've tried
various combinations of Upgrade, here is my current:
Upgrade Id=INSERT_GUID_HERE
UpgradeVersion OnlyDetect=yes Property=SELFFOUND
Minimum=1.0.0 IncludeMinimum=yes
Maximum=1.0.0 IncludeMaximum=yes /
UpgradeVersion OnlyDetect=yes Property=NEWERFOUND
Minimum=1.0.1 IncludeMinimum=no /
/Upgrade
and in InstallExecuteSequence I have:
RemoveExistingProducts Before=InstallInitialize /
I think the 'right' thing to do is to require uninstall and then reinstall
'manually', but my requirement is to allow user to go through installer
forms - using custom managed BA - and change values, including
'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly
in the BA, showing all required screen with values from previous install
filled. Is there some way to force MSI to uninstall itself then install
again? I suppose I could, from the BA, run the msi with /uninstall options
then run it again with /install options but is this the best way to do
something like that?
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
Why is doing this a bad idea? I know that's the common belief, but I don't know the reason. On Fri, May 30, 2014 at 11:09 AM, John Cooper jocoo...@jackhenry.com wrote: Instead of using the old Upgrade authoring, use the MajorUpgrade authoring and take a look at the AllowSameVersionUpgrades attribute. Note that this is a really bad idea(tm) in the field. -- 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: Ben Metheny [mailto:benmeth...@gmail.com] Sent: Friday, May 30, 2014 11:03 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Uninstall then Reinstall Same Package I have a requirement to allow 'overwrite' of same version. I've tried various combinations of Upgrade, here is my current: Upgrade Id=INSERT_GUID_HERE UpgradeVersion OnlyDetect=yes Property=SELFFOUND Minimum=1.0.0 IncludeMinimum=yes Maximum=1.0.0 IncludeMaximum=yes / UpgradeVersion OnlyDetect=yes Property=NEWERFOUND Minimum=1.0.1 IncludeMinimum=no / /Upgrade and in InstallExecuteSequence I have: RemoveExistingProducts Before=InstallInitialize / I think the 'right' thing to do is to require uninstall and then reinstall 'manually', but my requirement is to allow user to go through installer forms - using custom managed BA - and change values, including 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly in the BA, showing all required screen with values from previous install filled. Is there some way to force MSI to uninstall itself then install again? I suppose I could, from the BA, run the msi with /uninstall options then run it again with /install options but is this the best way to do something like that? -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ 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. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
So it all comes down to multiple MSIs with the same version number causing problems. On Friday, May 30, 2014, John Cooper jocoo...@jackhenry.com wrote: 1) Because you lose control over the particular ProductCode that represents your GA/RTM installer. Now ANY installer built by ANYONE can be installed. This exponentially increases the number of combinations you'll need to support in the field. Not good unto itself. Pretty easy scenario too--one of you dev's loans a dev build with the same version to one of your product support team to help a client with a problem. Happens all the time. If you allow same version, you live with the consequences. 2) Because of 1), your patch authoring will be much more difficult. No longer will you be able to target one ProductCode. Now, you must support all of them. And test patches against all of them. 3) Because an install of the same version with different ProductCode doesn't necessarily behave like you expect during an upgrade, repair, etc. In one case, all the assemblies have the same AssemblyFIleVersion, but there are code changes you want propagated. Not going to happen like you think. In the other, the versions are different. Now you have different combinations of assemblies in the same product release--and you must support all combinations. Not good. Don’t believe me? Study the Component Rules carefully and think about the consequences. -- John Merryweather Cooper Build Install Engineer – ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com javascript:; www.jackhenry.com -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com javascript:;] Sent: Friday, May 30, 2014 1:36 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Uninstall then Reinstall Same Package Why is doing this a bad idea? I know that's the common belief, but I don't know the reason. On Fri, May 30, 2014 at 11:09 AM, John Cooper jocoo...@jackhenry.com javascript:; wrote: Instead of using the old Upgrade authoring, use the MajorUpgrade authoring and take a look at the AllowSameVersionUpgrades attribute. Note that this is a really bad idea(tm) in the field. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com javascript:; www.jackhenry.com -Original Message- From: Ben Metheny [mailto:benmeth...@gmail.com javascript:;] Sent: Friday, May 30, 2014 11:03 AM To: WiX-users@lists.sourceforge.net javascript:; Subject: [WiX-users] Uninstall then Reinstall Same Package I have a requirement to allow 'overwrite' of same version. I've tried various combinations of Upgrade, here is my current: Upgrade Id=INSERT_GUID_HERE UpgradeVersion OnlyDetect=yes Property=SELFFOUND Minimum=1.0.0 IncludeMinimum=yes Maximum=1.0.0 IncludeMaximum=yes / UpgradeVersion OnlyDetect=yes Property=NEWERFOUND Minimum=1.0.1 IncludeMinimum=no / /Upgrade and in InstallExecuteSequence I have: RemoveExistingProducts Before=InstallInitialize / I think the 'right' thing to do is to require uninstall and then reinstall 'manually', but my requirement is to allow user to go through installer forms - using custom managed BA - and change values, including 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly in the BA, showing all required screen with values from previous install filled. Is there some way to force MSI to uninstall itself then install again? I suppose I could, from the BA, run the msi with /uninstall options then run it again with /install options but is this the best way to do something like that? -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net javascript:; 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. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet
Re: [WiX-users] Reference for logical operators, conditions, etc
Yes, that's it. Thanks! For some reason I assumed WiX defined the syntax and it was being compiled into something that Windows Installer would understand, so I never even tried the Microsoft site. With the advantage of hindsight I realize the CDATA should have been a clue. On Apr 4, 2014 1:57 AM, Rob Mensching r...@firegiant.com wrote: This? http://msdn.microsoft.com/en-us/library/aa368012(v=vs.85).aspx ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Thursday, April 3, 2014 8:37 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Reference for logical operators, conditions, etc I feel foolish asking, because I know it's a RTFM moment, but my problem is that I can't find the M. I see scraps of WiX input that look like: ![CDATA[Installed OR NETFRAMEWORK20]] but I can't find the reference for the logical operators, comparison operators if any, etc. Can someone provide a link or at least point me in the right direction? That scrap is taken from How To: Read a Registry Entry During Installation in the V3 documentation. I'm probably just not seeing it, of course. Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Reference for logical operators, conditions, etc
I feel foolish asking, because I know it's a RTFM moment, but my problem is that I can't find the M. I see scraps of WiX input that look like: ![CDATA[Installed OR NETFRAMEWORK20]] but I can't find the reference for the logical operators, comparison operators if any, etc. Can someone provide a link or at least point me in the right direction? That scrap is taken from How To: Read a Registry Entry During Installation in the V3 documentation. I'm probably just not seeing it, of course. Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Making 64 bit installer from 32bit wix file
You've had a number of suggestions for troubleshooting. Have you followed them? If so, what did you find? If not,why not? On Mar 21, 2014 2:29 AM, karthikrangaraj kranga...@dnpphoto.eu wrote: To All, For testing and i made an installer using Install Shield LE and the application works perfectly fine on both Windows 8 32/64 bit. There is nothing wrong with the dependencies. I may be making some mistakes with WIX or there may be some other problem. I want to dig more but I need some suggestion guys. Thank you. - Wix 3.8 users -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Making-64-bit-installer-from-32bit-wix-file-tp7593557p7593650.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Making 64 bit installer from 32bit wix file
So you have compared every single file installed between the InstallShield install and the WiX install and they're the same? Same for any registry settings? I'm not likely to be able to help you, but if you don't tell the WiX-smart guys here what you've done and what you've found, they're not going to be able to either. On Fri, Mar 21, 2014 at 7:05 AM, karthikrangaraj kranga...@dnpphoto.euwrote: I didn't try much because when i run the project on Windows 8 using VS, everything is working fine. I odn't think there is a dependency issue. In my understanding there may be problem with the way I pulled the sources(normally ANY CPU, for x86 you get the files from x86 release folder and the same for x64 as well). It didn't work. Or may be something with my WIX code...but it installed properly in the correct folder and after that the application is not functioning when you launch it. - Wix 3.8 users -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Making-64-bit-installer-from-32bit-wix-file-tp7593557p7593657.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue
I understand what you're trying to do, but please stop and ask if it makes
sense.
The format of the path under ProgramData is usually
publisher/software/files and not editable by the user.
For that matter, the software should be under Program Files, referenced by
symbol, not C:\.
It's a bit confusing when you say you're trying to create a directory
using copyfile because that's not you create directories. It's also
confusing that you have hardcoded the directory as the Program Files
folder. Typically you use the ProgramFilesFolder like this:
http://wix.tramontana.co.hu/tutorial/getting-started/the-files-inside
and the rest of that tutorial would probably help. Then your copyfile
doesn't refer to your hardcoded path, it does a copy from SourceDir to
INSTALLFOLDER, which is the property name for the install location
chosen by the user.
---
Phil Wilson
On Thu, Mar 13, 2014 at 6:43 AM, Suvrajyoti Panda
suvrajyo...@contata.co.in wrote:
Guys, Please let me know if some one has any idea on the below problem.
Original Message
Subject:Creating directory under C:\Programdata same as what the
user
specified in the UI dialogue
Date: Thu, 13 Mar 2014 10:37:13 +0530
From: Suvrajyoti Panda suvrajyo...@contata.co.in
To: General discussion about the WiX toolset.
wix-users@lists.sourceforge.net
Hi All,
I had appended this query in another topic, so reposting the same under
different heading.
I have this requirement in which i want to create directory under
C:\Programdata same as what the user specified in the UI dialogue .I am
trying to do that using CopyFile. Below is the code:
Property Id=CopyDestination Value=C:\ProgramData\Energy Solutions
International\PipelineOptimizer $(var.SvnVersion)/
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutions' Name=Energy Solutions
International
Directory Id='TORT' Name='PipelineOptimizer $(var.SvnVersion)'
/Directory
/Directory
/Directory
Component Id=PreferencesFile
Guid={A4E1FFCE-1534-43BF-AA2B-CDFD39381720} Directory=TARGETDIR
File Id='preferences'
Source='$(var.GuiPath)\screens\preferences.xml' KeyPath='yes'
CopyFile Id='Copy_Prefs'
DestinationProperty='CopyDestination' /
/File
/Component
SetDirectory Id=EnergySolutions Value=C:\Energy Solutions
International/
Property Id=WIXUI_INSTALLDIR Value=TORT /
UIRef Id=WixUI_InstallDir /
While doing the installation if the user changes the install directory
from the one that is default(it comes out as PipelineOptimizer 06.00.00)
to some other name, the file being copied using the CopyFile attribute
is still copied to the same directory under the programdata as the one
which is defaulted in the UI which is to C:\ProgramData\Energy Solutions
International\PipelineOptimizer 06.00.00. What i want though is that if
the user changes the directory to say PipelineOptimizer 06.00.00 Test,
then the file should be copied to the C:\ProgramData\Energy Solutions
International\PipelineOptimizer 06.00.00 Test but this does not happen.
Is there a way i can achieve the same. I tried using custom action to
set the property CopyDestination but was not able to do so. Please let
me know if there is a solution to this if possible with some sample code.
Also is there a way in which we can create 2 prompts to the user during
install. This would allow us to use the directory variable independent
of the path so that we can use this approach for the ProgramData
subfolder .
i. Prompt 1: The install path. For example, the default path is
C:\Energy Solutions International\.
ii.Prompt 2: The install directory. For example, the default
directory is PipelineOptimizer 06.00.00.
and then use the value of the install directory somehow to copy the file
to right location. Is the above approach possible? Please help as it is
urgent for me.
Regards,
Suvra Jyoti
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
Re: [WiX-users] ReserveCost doesn't appear to reserve disk space
This really isn't an install issue at this point, but... Do you actually need to store things in this file, or are you just wanting to make sure you have X MB available for your program? If the latter, you could create and package a file that contains the same byte value over and over. That should compress to very small. Then as your program writes to other files on the disk, reduce the size of your padding file by the same amount. If you mark the file system/hidden most users won't see it. It wouldn't be perfect thanks to disk block sizes and so forth, but it'd be close enough for most things. What are your real requirements and what of your description is just thinking about how you might be able to make it work? On Fri, Mar 14, 2014 at 12:18 PM, Alain Forget afor...@cmu.edu wrote: Interesting; I hadn't heard of NTFS sparse files, but unfortunately, I can't assume NTFS on my target installation machines. I'm currently wondering if there's some kind of file container I can use that will take up X disk space all the time, but that my program can open and add remove files to it, without modifying the externally visible size...just like a TrueCrypt volume, but simpler, easy-to-use programmatically, and preferably is essentially invisible to the user. I'd also prefer to be able to generate this container on the client, rather than having to pre-package a potentially very large container with my installer (and/or requiring the user to download the large container). If it happens to have built-in compression and/or encryption, then bonus! Alain -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Friday, March 14, 2014 13:05 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ReserveCost doesn't appear to reserve disk space I suppose it would need a custom action, but couldn't one allocate an NTFS sparse file (assuming an NTFS file system, anyway)? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: March-14-14 12:57 PM To: 'General discussion about the WiX toolset.' Subject: Re: [WiX-users] ReserveCost doesn't appear to reserve disk space Ah, so ReserveCost is to reserve space perhaps for CustomActions or other things Windows Installer might not be able to predict. Yeah, I was afraid of that. The only idea I had to reserve disk space was to use a TrueCrypt volume of 100MB (or whatever size) and then programmatically open it and close it when needed and store data. Of course, then there'd be various complications, such as finding an available drive letter at run-time to opening the volume, and so on. Thanks for the info, and if there are any other ideas, please do let me know. Alain -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Friday, March 14, 2014 12:49 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] ReserveCost doesn't appear to reserve disk space It's mostly internal to the install - by the time costing is complete for the target volume there should be at least that 100MB remaining. Because it's part of the cost you should get a low disk error if there's not enough space on that volume during the install. Programs and Features includes the cost because you said you'd be needing it :) My Win32 brain tells me that disk space isn't in a directory anyway, so there isn't a way to say that some space belongs to a particular directory as far as I know, and I know of no way that Windows would somehow know that your apps (that haven't even run yet) are the only ones allowed to use the space. --- Phil Wilson On Fri, Mar 14, 2014 at 9:20 AM, Alain Forget afor...@cmu.edu wrote: Hi all, This may relate to Windows Installer in general (and not WiX specifically), but when I use ReserveCost to reserve say 100MB for Directory A, I would expect the amount of free space on the disk to be reduced by at least 100MB after installation, to signify that the overall disk space has been reduced (even though there is 100MB reserved for Directory A). However, this does not occur. Curiously, it does appear as though ReserveCost is having some effect, because in the Programs and Features area, my installer now takes 100+MB of space, while before it did not. From reading docs online (see refs below), I had understood that ReserveCost will reserve or section/block off whatever amount of space I request for the specified directory after installation, which I presume would remain unavailable to other directories on disk until the program is uninstalled. Is this incorrect? If
Re: [WiX-users] Upgrade and side by side with the same installer
Based on something Rob wrote at some point, I've been using * as Product Code and not changing the upgrade code. It really seems like the OP's basic requirement is that each release is an independent product, so if they just do that they'll be 99% of the way there. Of course the last 1% is always the hardest. On Mar 7, 2014, at 12:30 PM, Pavan Konduru pavan.kond...@accelrys.com wrote: Hi Walter, Changing the upgrade code will only treat it as an upgrade. We would need to change the product code to make it install side-by-side. --Pavan -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Friday, March 07, 2014 6:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Silly naive question... Would giving each version a different Upgrade codeand a version based destination directory (like MyApp.1.1.1 instead of just MyApp) accomplish at least most of what Pavan wants? On Mar 6, 2014 3:20 PM, Bryan Wolf brw...@jackhenry.com wrote: My thoughts were more focused on what the product actually supports in terms of side-by-side and less of what MSI can do for you. Once you establish what the product does, it'll be easier to model your installer better. E.g. Visual Studio is basically sandboxed off but some features (like VS2010 compilers on VS2012) are green-lighted based on presence. -Original Message- From: Pavan Konduru [mailto:pavan.kond...@accelrys.com] Sent: Thursday, March 6, 2014 3:01 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Hi Bryan, Thank you for your inputs. The product is installed for all users(per machine). All users have access to any installed versions of the product on the machine. Am not sure if this will make life easier! The upgrade/side-by-side was being supported through Installanywhere installer(even though the product is only a Windows only deployment), which is a complete different technology. I am in the process of changing the IA installer to WIX. --Pavan -Original Message- From: Bryan Wolf [mailto:brw...@jackhenry.com] Sent: Thursday, March 06, 2014 12:07 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Another way of looking at what John is suggesting is considering that you probably want to take a step back a moment and focus more on version 3 and less on version 2. You're looking at some sort of super-linear number of installations you're going to have to support; all those permutations on top of what is already a matrix of install testing that needs to be done means you could be talking somewhere in the order of 10,000 different tests for just a couple of operating systems and configurations by versions 4 and 5. Obviously you can't test that much, so it would just be gap in the end result. Version 2 is the easy part. The hard part is asking the age-old question, What if more than 1 person did this? Specifically, the answer may lay in focusing on what the wording of the word support means. Does adding users to version 1 affect version 2? Permissions? Maybe those questions might make it easier - but I advise not going through with scenario-based installers. :-) -Original Message- From: Pavan Konduru [mailto:pavan.kond...@accelrys.com] Sent: Thursday, March 6, 2014 1:19 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Hi John, Thank you for your inputs. Looks like things would get pretty complicated when Hotfixes and patches will be involved. The problem is the product architecture supports different versions residing side-by-side. Been pulling my hair out to see how to make this work. How about creating 2 installers, one which does a side-by-side and one which would do an upgrade. The bootstrapper checks for existing product and give an option to user for upgrade/side-by-side. Call the appropriate installer based on User selection? Is this feasible? It would surely involve a lot of redundant code and maintenance. --Pavan -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Wednesday, March 05, 2014 2:48 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer No (it's not a good architecture). Major Upgrade mostly works really well and can be fully automated. Side-by-side converts it to a manual process. You're also going to have to maintain a set of patches for each release (really, each separate product, since you're going to have to have separate upgrade code GUID's to make this work). Of course, there are plenty of products out here that execute
Re: [WiX-users] Upgrade and side by side with the same installer
Silly naive question... Would giving each version a different Upgrade codeand a version based destination directory (like MyApp.1.1.1 instead of just MyApp) accomplish at least most of what Pavan wants? On Mar 6, 2014 3:20 PM, Bryan Wolf brw...@jackhenry.com wrote: My thoughts were more focused on what the product actually supports in terms of side-by-side and less of what MSI can do for you. Once you establish what the product does, it'll be easier to model your installer better. E.g. Visual Studio is basically sandboxed off but some features (like VS2010 compilers on VS2012) are green-lighted based on presence. -Original Message- From: Pavan Konduru [mailto:pavan.kond...@accelrys.com] Sent: Thursday, March 6, 2014 3:01 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Hi Bryan, Thank you for your inputs. The product is installed for all users(per machine). All users have access to any installed versions of the product on the machine. Am not sure if this will make life easier! The upgrade/side-by-side was being supported through Installanywhere installer(even though the product is only a Windows only deployment), which is a complete different technology. I am in the process of changing the IA installer to WIX. --Pavan -Original Message- From: Bryan Wolf [mailto:brw...@jackhenry.com] Sent: Thursday, March 06, 2014 12:07 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Another way of looking at what John is suggesting is considering that you probably want to take a step back a moment and focus more on version 3 and less on version 2. You're looking at some sort of super-linear number of installations you're going to have to support; all those permutations on top of what is already a matrix of install testing that needs to be done means you could be talking somewhere in the order of 10,000 different tests for just a couple of operating systems and configurations by versions 4 and 5. Obviously you can't test that much, so it would just be gap in the end result. Version 2 is the easy part. The hard part is asking the age-old question, What if more than 1 person did this? Specifically, the answer may lay in focusing on what the wording of the word support means. Does adding users to version 1 affect version 2? Permissions? Maybe those questions might make it easier - but I advise not going through with scenario-based installers. :-) -Original Message- From: Pavan Konduru [mailto:pavan.kond...@accelrys.com] Sent: Thursday, March 6, 2014 1:19 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Hi John, Thank you for your inputs. Looks like things would get pretty complicated when Hotfixes and patches will be involved. The problem is the product architecture supports different versions residing side-by-side. Been pulling my hair out to see how to make this work. How about creating 2 installers, one which does a side-by-side and one which would do an upgrade. The bootstrapper checks for existing product and give an option to user for upgrade/side-by-side. Call the appropriate installer based on User selection? Is this feasible? It would surely involve a lot of redundant code and maintenance. --Pavan -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Wednesday, March 05, 2014 2:48 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer No (it's not a good architecture). Major Upgrade mostly works really well and can be fully automated. Side-by-side converts it to a manual process. You're also going to have to maintain a set of patches for each release (really, each separate product, since you're going to have to have separate upgrade code GUID's to make this work). Of course, there are plenty of products out here that execute this model, including several from Microsoft. But popular doesn't mean good. With each new version that can run side-by-side with all the others, you're going to have a factorial increasing load for your QA team trying to figure out (and stamp out) all the interactions. Same goes for each installer, each patch, each upgrade, etc. -- 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: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Wednesday, March 5, 2014 4:27 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrade and side by side with the same installer Best I could think is to use Burn and make each install able to side by side install, and
Re: [WiX-users] Wix Uninstallation in Windows XP
a) Yes, that's the restart manager. Try reading up on this stuff at http://msdn.microsoft.com/en-us/library/aa372059(v=vs.85).aspx (Rob gave me this link when I was working through something else.) It's tricky and confusing, took me a day or two of reading, testing and begging for help here to get a quiet install to quietly install without killing off running programs. And I'm targeting Windows 7 only. Do you really need to target XP? It's end of life from Microsoft April 8. At that point I expect a lot of ISVs to use that as a reason to discontinue their support. Perhaps you could just punt and tell the user they have to exit the GUI app if they want the uninstall to work. On Mon, Mar 3, 2014 at 6:01 PM, ashish thomas ashishptho...@yahoo.co.inwrote: Hi All, We are using Wix MSI for doing installation/uninstallation of our application. Currently our application is supported from Windows XP and above. As a part of uninstallation, we are removing Gui application from system tray. But we are finding two different behavior for XP vs Non XPS Non XP - Vista and Above (eg: Win7) - Here ,when we remove uninstall from Add or Remove Programs, gets a pop up that Gui application needs to closed before continuing the install. I select Automatically close applications and attempt to restart them after setup is complete and uninstallation is completed successfully and everything works fine. XP - When I invoke uninstall from Add or Remove Programs, I didn't get the pop up that Gui application needs to closed. Uninstallation removes all the files from the installation directory but application is still seen in the system tray. Here are the questions a) Why the different behavior seen in Windows XP? Is it since Restart Manager is not present in XP. b) How can I get Windows 7 behavior in Windows XP (ie getting pop up that Gui application needs to closed) c) In Windows7, how can I prevent Gui application needs to be closed from not appearing. d) For XP, I have added the below code to remove Gui during uninstallation and found working. Can someone please comment if I am doing correct or something wrong with the below code. InstallExecuteSequence !--WixCloseApplications is a built in custom action that uses util:CloseApplication below -- CustomAction=WixCloseApplicationsBefore=InstallInitialize/ /InstallExecuteSequence util:CloseApplicationId=CloseGuiCloseMessage=yesDescription=Needs to close.Sorry about that ElevatedCloseMessage=noRebootPrompt=no Target=Gui.exe/ /Product What I am basically aiming is the same behavior in both XP and Windows7 operating systems. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder.
I'll have to look into SetDirectory /. That looks cleaner than my custom action route. On Fri, Feb 21, 2014 at 5:06 AM, paul.chor...@stfc.ac.uk wrote: Walt, All working for install uninstall now thanks to your prompting explanation of the directory attribute. For future reference:- I also tried using the WindowsVolume supplied property to get to the root of things in a drive letter independent way. This resulted in an error. I then saw this link by Ravikumar Gopinath:- http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Error-using-WindowsVolume-predefined-folder-td3313078.html So using this seems to provide a drive letter independent solution:- SetDirectory Id=WINDOWSVOLUME Value=[WindowsVolume]/ Directory Id=TARGETDIR Name=SourceDir Directory Id=WINDOWSVOLUME Directory Id=UsersDir Name=Users Directory Id=User1Dir Name=user1 Directory Id=AppdataDir Name=Appdata Directory Id=RoamingDir Name=Roaming Directory Id=MicrosoftDir Name=Microsoft Directory Id=WindowsDir Name=Windows Directory Id=StartmenuDir Name=Start Menu Directory Id=ProgramsDir Name=Programs Directory Id=StartupDir Name=Startup /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory DirectoryRef Id =StartupDir Component Id=CMP_MyAppStartupShortcut Guid=GUID Here KeyPath=yes Shortcut Id= MyAppStartupShortcut Name=MyApp Description=Launch MyApp Target=[ProgramDir]MyApp.exe WorkingDirectory=ProgramDir Icon=icon.ico/ /Component /DirectoryRef Cheers, Paul -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: 20 February 2014 16:16 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder. I was just coming in to correct the path... The problem you're having is that the Directory attribute is supposed to be the ID of a directory, not the path to a directory. Here's how I'm dealing with absolute paths. My standard disclaimer with WiX advice is that I first used WiX in November and I still don't feel like I know what I'm doing, so there may be a much easier way to do anything. CustomAction Id=CA_SetCDrive Directory=C_DRIVE Value=c:\ / InstallExecuteSequence Custom Action=CA_SetCDrive After=CostFinalize / /InstallExecuteSequence Directory Id=TARGETDIR Name=SourceDir Directory Id=C_DRIVE Name=CDrive Directory Id=DIR_PROGRAMDATA Name=ProgramData Directory Id=DIR_MICROSOFT Name=Microsoft Directory Id=DIR_POINTOFSERVICE Name=Point of Service Directory Id=DIR_CONFIGURATION Name=Configuration / /Directory /Directory /Directory /Directory /Directory Then, assuming you got all the rest of your values right, you would have: Shortcut Id=MYShortcut Name=MyApp Description=Launch MyApp Target=[ProgramDir]MYApp.exe WorkingDirectory=ProgramDir Icon=icon.ico Directory=DIR_CONFIGURATION/ and your shortcut would land in c:\ProgramData\Microsoft\Point of Service\Configuration. (Not a sensible place to put a shortcut, of course, but it's the snippet I could steal easily.) I assume that you have an icon / element with Id=icon.ico because I think that's an ID as well. I've never done a shortcut or icon in WiX, though. We don't even have the explorer shell running. We have a custom shell that has it's own way of doing Startup and RunOnce. Good luck- Walt On Thu, Feb 20, 2014 at 8:47 AM, paul.chor...@stfc.ac.uk wrote: Hello Ilir, Thanks for your response, how do I add a shortcut to that path in WIX (C:\Users\TheUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup)? Cheers, Paul -Original Message- From: Ilir Bekteshi [mailto:ilir...@gmail.com] Sent: 20 February 2014 13:22 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder. If you want your Shortcut to appear in Startup folder for everyone then put it in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup For a specific user then C:\Users\TheUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup On Thu, Feb 20, 2014 at 1:06 PM, paul.chor...@stfc.ac.uk wrote: Hello, I have a kiosk type PC system, that on boot up, automatically logs on a special restricted user account with a preconfigured password. My application then launches automatically using a shortcut present in only that special users Startup folder. The installation scope
Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder.
Keep in mind that some of us aren't targeting general purpose computers. Paul has kiosks, and I have cash registers and time clocks. My company will ultimately deploy 14,000 identical (in terms of directory layout at least) time clocks, and presently has roughly 70,000 identical registers. So hard coding paths does make sense sometimes On Feb 21, 2014 6:53 PM, Pavan Konduru pavan.kond...@accelrys.com wrote: Sorry Rob . I wasn't sure the solution to create a directory level structure as mentioned below could solve the issue as the directory structure is different for every OS. Directory Id=TARGETDIR Name=SourceDir Directory Id=WINDOWSVOLUME Directory Id=UsersDir Name=Users Directory Id=User1Dir Name=user1 Directory Id=AppdataDir Name=Appdata Directory Id=RoamingDir Name=Roaming Directory Id=MicrosoftDir Name=Microsoft Directory Id=WindowsDir Name=Windows Directory Id=StartmenuDir Name=Start Menu Directory Id=ProgramsDir Name=Programs Directory Id=StartupDir Name=Startup /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory /Directory -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Friday, February 21, 2014 2:04 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder. That is very much not a good design. The Windows Installer an create shortcuts just fine. And uninstall them and roll them back and handle all the other scenarios you need to think about when putting a file (like a shortcut) on disk. This is a very bad suggestion below. All you need is to set the directory for the shortcut correctly. That may (but doesn't seem like it should) a custom action to find the path... but once the directory is set, let the Windows Installer do the heavy lifting of actually creating the shortcut. -Original Message- From: Pavan Konduru [mailto:pavan.kond...@accelrys.com] Sent: Friday, February 21, 2014 12:59 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder. You can use a Custom action to set a shortcut in the user directory. I am assuming your installer is per machine, hence all shortcuts are in the general start menu but you just need one shortcut that must be created in the user profile? I see that you got the directory structure(that is for Wind 7 ) but isn't the start menu different for different windows OS flavors?Win 2003 server has this structure: C:\Documents and Settings\User\Start Menu\Programs I did something like this and it worked (but you would have to handle the deletion manually during uninstall) WshShell shell = new WshShell(); string shrtcutLnk = App.lnk; IWshShortcut MyShortcut; pathString= Environment.GetFolderPath(Environment.SpecialFolder.StartMenu); MyShortcut = (IWshShortcut)shell.CreateShortcut(pathString + shrtcutLnk); MyShortcut.TargetPath = ; MyShortcut.Arguments = ; MyShortcut.WorkingDirectory = ; MyShortcut.Description = Launch blah blah; MyShortcut.IconLocation = MyIco.ico; MyShortcut.Save(); This line of code returns the current users startmenu folder, which in mycase was: pathString= Environment.GetFolderPath(Environment.SpecialFolder.StartMenu); C:\\Users\\pavan.konduru\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu --Pavan -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Friday, February 21, 2014 9:56 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder. I'll have to look into SetDirectory /. That looks cleaner than my custom action route. On Fri, Feb 21, 2014 at 5:06 AM, paul.chor...@stfc.ac.uk wrote: Walt, All working for install uninstall now thanks to your prompting explanation of the directory attribute. For future reference:- I also tried using the WindowsVolume supplied property to get to the root of things in a drive letter independent way. This resulted in an error. I then saw this link by Ravikumar Gopinath:- http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Error-us ing-WindowsVolume-predefined-folder-td3313078.html So using this seems to provide a drive letter independent solution:- SetDirectory Id=WINDOWSVOLUME Value=[WindowsVolume]/ Directory Id=TARGETDIR Name=SourceDir Directory
Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder.
You don't say what OS, but recently in POSReady 7 I achieved this by just putting a shortcut into the specific directory for that user, which if I remember right is under c:/userdata/username/Microsoft/windows/start menu/... If you poke around you'll find it. On XP and earlier, the start menu tree is off the user home directory. I used Inno Setup at the time, but the hard part in WiX is probably specifying the full path. I haven't tried a shortcut in WiX yet. Let me know if you need help with the path issue. There may of course be a better way, and this isn't suitable for a more general use than you described. On Feb 20, 2014, at 6:06 AM, paul.chor...@stfc.ac.uk wrote: Hello, I have a kiosk type PC system, that on boot up, automatically logs on a special restricted user account with a preconfigured password. My application then launches automatically using a shortcut present in only that special users Startup folder. The installation scope is per machine as other users may need to run the application from time to time for diagnostic purposes. The application installation is always done using an admin account. In the past using VS2010:- 1. The solution MS Setup Project installed all of the common features successfully. 2. I utilized the MS Installer Class which through some c# code created an application shortcut in the special user's startup folder during installation and removed it during uninstallation. With the demise of the above VS2010 features in later VS versions I have just over the last two weeks looked at WIX as an alternative. So far the WIX project will successfully install uninstall the common features successfully, that is DLL, EXE files and some simple all user application shortcuts on the desktop and start menu. After searching for ages, I cannot determine how to set a startup shortcut in just the special user account. From my searches this does not appear to possible just using the basic WIX. I would really appreciate some directional guidance. Maybe a C# custom action project should be used? Or a batch file? Cheers, Paul -- Scanned by iCritical. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Read a value from a text file and use it in WIX source file
Chetan, It sounds like you're working in VisualmStudio or using MsBuild. I don't know anything really about either one with respect to WiX. That said, setting an environment variable from a program has usually only lasted until that program exits. I don't know where or when that C# code is running but that could be a problem. Also, running Candle as a prebuild command seems very wrong. I looked very briefly at the VS integration and decided it wasn't worth my time. Also, there are folks in my organization who do packaging but not any development, so as the WiX trailblazer around here, I didn't want to depend on stuff they don't have. On Feb 20, 2014, at 12:02 AM, Chetan Rajakumar chetan_rajaku...@infosys.com wrote: Hi Walter, I am not able to accomplish this, please help me out. I am doing the below Steps: 1. From C# code I am setting environment variable as shown below, System.Environment.SetEnvironmentVariable(DRAFTVERSION, 1.2.3.4); 2. In Installer Project's Properties under Pre-Build event Command line, I have written the below line. $(WiX)\bin\candle.exe -dSvnVersion=%DRAFTVERSION% -out $(ProjectDir)\Product.wxs 3. In Product.wxs Product Id=* Name=MyProduct Language=1033 Version=$(var.SvnVersion) Manufacturer=MyManufacturer UpgradeCode=335459EF-2345-4CD7-8EDA-59996EC3 I am getting below error. Undefined Preprocessor Variable. Please let me know if I have missed something. Thanks and Regards, Chetan. -Original Message- From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in] Sent: Friday, February 14, 2014 11:34 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Read a value from a text file and use it in WIX source file Thanks Walter, that works for me :) On 12-02-2014 21:35, Walter Dexter wrote: Sorry I forgot about this. Here's what I'm doing. I'm sure someone more experienced will have a much better way, but this works for me. First, in my build.cmd file, set svt envrironment variable to the contents of the svnversion.txt file: set /p svt=svnversion.txt Then, pass it to candle on the command line: candle -dSvnVersion=%svt% main.wxs In main.wxs you can then use it as a variable. For example: Property Id=MCO_SVNVERSION Value=$(var.SvnVersion) / On Tue, Feb 11, 2014 at 9:34 AM, Suvrajyoti Panda suvrajyo...@contata.co.in wrote: Thanks Walter, that would be really helpful if you can give me an example. Regards, Suvra Jyoti On 11-02-2014 19:53, Walter Dexter wrote: It may not be the most elegant way, but I'm doing the same thing by passing the contents of the file (first line anyway) as a command line argument to the linker. I use a .cmd file to run the WiX ci mpile and link so its just a bit of batch file processing. If you need an example I can get it for you once I get to work. Let me know. On Feb 11, 2014 12:40 AM, Suvrajyoti Panda suvrajyo...@contata.co.in wrote: Hi All, I have a requirement wherein in i need to read a value from a text file located at D:\Project\ESI\Code\trunk\lastVersion.txt. This file contains a single line as below: 6.0.0 Build 3280 This 6.0.0 is basically the version . Now i want to read this value of version and use it in the name of the product in the WIX source file as below: Product *Name**='Tort Installer 1.0'* Id='5A1581BE-27C3-46A1-8699-4F1D642C97E0' UpgradeCode='C54B7D5D-0E66-43E8-A770-C9750693F057' Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='$(var.ManufacturerName)' Instead of the 1.0 in the Name attribute i want to use the value of 6.0.0 that is there in the text file mentioned above. Please let me know how can i go about solving this issue. Regards, Suvra Jyoti - - Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg .clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg .clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder.
I was just coming in to correct the path... The problem you're having is that the Directory attribute is supposed to be the ID of a directory, not the path to a directory. Here's how I'm dealing with absolute paths. My standard disclaimer with WiX advice is that I first used WiX in November and I still don't feel like I know what I'm doing, so there may be a much easier way to do anything. CustomAction Id=CA_SetCDrive Directory=C_DRIVE Value=c:\ / InstallExecuteSequence Custom Action=CA_SetCDrive After=CostFinalize / /InstallExecuteSequence Directory Id=TARGETDIR Name=SourceDir Directory Id=C_DRIVE Name=CDrive Directory Id=DIR_PROGRAMDATA Name=ProgramData Directory Id=DIR_MICROSOFT Name=Microsoft Directory Id=DIR_POINTOFSERVICE Name=Point of Service Directory Id=DIR_CONFIGURATION Name=Configuration / /Directory /Directory /Directory /Directory /Directory Then, assuming you got all the rest of your values right, you would have: Shortcut Id=MYShortcut Name=MyApp Description=Launch MyApp Target=[ProgramDir]MYApp.exe WorkingDirectory=ProgramDir Icon=icon.ico Directory=DIR_CONFIGURATION/ and your shortcut would land in c:\ProgramData\Microsoft\Point of Service\Configuration. (Not a sensible place to put a shortcut, of course, but it's the snippet I could steal easily.) I assume that you have an icon / element with Id=icon.ico because I think that's an ID as well. I've never done a shortcut or icon in WiX, though. We don't even have the explorer shell running. We have a custom shell that has it's own way of doing Startup and RunOnce. Good luck- Walt On Thu, Feb 20, 2014 at 8:47 AM, paul.chor...@stfc.ac.uk wrote: Hello Ilir, Thanks for your response, how do I add a shortcut to that path in WIX (C:\Users\TheUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup)? Cheers, Paul -Original Message- From: Ilir Bekteshi [mailto:ilir...@gmail.com] Sent: 20 February 2014 13:22 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding Application Shortcut to Specific User's Startup Folder. If you want your Shortcut to appear in Startup folder for everyone then put it in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup For a specific user then C:\Users\TheUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup On Thu, Feb 20, 2014 at 1:06 PM, paul.chor...@stfc.ac.uk wrote: Hello, I have a kiosk type PC system, that on boot up, automatically logs on a special restricted user account with a preconfigured password. My application then launches automatically using a shortcut present in only that special users Startup folder. The installation scope is per machine as other users may need to run the application from time to time for diagnostic purposes. The application installation is always done using an admin account. In the past using VS2010:- 1. The solution MS Setup Project installed all of the common features successfully. 2. I utilized the MS Installer Class which through some c# code created an application shortcut in the special user's startup folder during installation and removed it during uninstallation. With the demise of the above VS2010 features in later VS versions I have just over the last two weeks looked at WIX as an alternative. So far the WIX project will successfully install uninstall the common features successfully, that is DLL, EXE files and some simple all user application shortcuts on the desktop and start menu. After searching for ages, I cannot determine how to set a startup shortcut in just the special user account. From my searches this does not appear to possible just using the basic WIX. I would really appreciate some directional guidance. Maybe a C# custom action project should be used? Or a batch file? Cheers, Paul -- Scanned by iCritical. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg. clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Scanned by iCritical.
Re: [WiX-users] Read a value from a text file and use it in WIX source file
Sorry I forgot about this. Here's what I'm doing. I'm sure someone more experienced will have a much better way, but this works for me. First, in my build.cmd file, set svt envrironment variable to the contents of the svnversion.txt file: set /p svt=svnversion.txt Then, pass it to candle on the command line: candle -dSvnVersion=%svt% main.wxs In main.wxs you can then use it as a variable. For example: Property Id=MCO_SVNVERSION Value=$(var.SvnVersion) / On Tue, Feb 11, 2014 at 9:34 AM, Suvrajyoti Panda suvrajyo...@contata.co.in wrote: Thanks Walter, that would be really helpful if you can give me an example. Regards, Suvra Jyoti On 11-02-2014 19:53, Walter Dexter wrote: It may not be the most elegant way, but I'm doing the same thing by passing the contents of the file (first line anyway) as a command line argument to the linker. I use a .cmd file to run the WiX ci mpile and link so its just a bit of batch file processing. If you need an example I can get it for you once I get to work. Let me know. On Feb 11, 2014 12:40 AM, Suvrajyoti Panda suvrajyo...@contata.co.in wrote: Hi All, I have a requirement wherein in i need to read a value from a text file located at D:\Project\ESI\Code\trunk\lastVersion.txt. This file contains a single line as below: 6.0.0 Build 3280 This 6.0.0 is basically the version . Now i want to read this value of version and use it in the name of the product in the WIX source file as below: Product *Name**='Tort Installer 1.0'* Id='5A1581BE-27C3-46A1-8699-4F1D642C97E0' UpgradeCode='C54B7D5D-0E66-43E8-A770-C9750693F057' Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='$(var.ManufacturerName)' Instead of the 1.0 in the Name attribute i want to use the value of 6.0.0 that is there in the text file mentioned above. Please let me know how can i go about solving this issue. Regards, Suvra Jyoti -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to pass values from command line to wix installer
If you mean when you install the resulting MSI, that would be in the Windows installer documentation. Or you can do msiexec /? and I think that's in there. On Feb 11, 2014 7:42 AM, Kiran Somisetty mr.svski...@gmail.com wrote: I have a requirement to pass values from the command line while installing the wix. I want to assign this to AnynymousAccess attribute. iis:WebDirProperties Id=webdir AnonymousAccess='value passed'/ Can you pls help me on this, I searched the documentation, but haven't got any clues. Kiran -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Read a value from a text file and use it in WIX source file
It may not be the most elegant way, but I'm doing the same thing by passing the contents of the file (first line anyway) as a command line argument to the linker. I use a .cmd file to run the WiX ci mpile and link so its just a bit of batch file processing. If you need an example I can get it for you once I get to work. Let me know. On Feb 11, 2014 12:40 AM, Suvrajyoti Panda suvrajyo...@contata.co.in wrote: Hi All, I have a requirement wherein in i need to read a value from a text file located at D:\Project\ESI\Code\trunk\lastVersion.txt. This file contains a single line as below: 6.0.0 Build 3280 This 6.0.0 is basically the version . Now i want to read this value of version and use it in the name of the product in the WIX source file as below: Product *Name**='Tort Installer 1.0'* Id='5A1581BE-27C3-46A1-8699-4F1D642C97E0' UpgradeCode='C54B7D5D-0E66-43E8-A770-C9750693F057' Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='$(var.ManufacturerName)' Instead of the 1.0 in the Name attribute i want to use the value of 6.0.0 that is there in the text file mentioned above. Please let me know how can i go about solving this issue. Regards, Suvra Jyoti -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install busy executables at reboot - Windows 7
That would be cool but I'm going to hold off until I'm fighting with the next one. This one is doing what I want. I'd say each time I make an MSI you guys teach me something else. On Jan 29, 2014, at 12:23 AM, Blair Murri os...@live.com wrote: Post a URL and we will interpret/educate on the interpretation thereof Walter Dexter wfdex...@gmail.com wrote: So far as the logs, I have yet to ever find anything I can make sense of in an MSI log. I'm well aware that's my own deficiency but those things are 99.95% unintelligible to me. On Tue, Jan 28, 2014 at 2:46 PM, Walter Dexter wfdex...@gmail.com wrote: In my case the installer is always run as quiet and there's no interactions with any user. Our goal is to slip in and deliver stuff without their noticing. I naively put everything in a single feature. it sounds like I would be better served to sort the files into features based on actual dependencies, so one feature might be a single .exe and any files it requires to run. On Tue, Jan 28, 2014 at 12:19 PM, Phil Wilson phildgwil...@gmail.comwrote: You could move files (strictly components) around, but in most installs the features are units of functionality and not random collections of assorted files. A feature is the user's unit of functionality that can be added or removed, and moving files out of one often requires other changes such as help and docs that say installing feature X gives you this functionality because it no longer does. As Blair says, look at the verbose log. In the absence of hard evidence that says what's really happening it seems premature to change feature content. --- Phil Wilson On Tue, Jan 28, 2014 at 5:44 AM, Walt Dexter wfdex...@gmail.com wrote: And there's the answer. They're all in the same feature. Can I move existing files between features in an upgrade? That would position me better the next time around. On Jan 28, 2014, at 4:36 AM, Blair Murri os...@live.com wrote: Are you doing a major upgrade or a recache/repair? Are the files it was killing off in the same feature as other files that were changed? Remember that features are installed/repaired/removed as a unit. Your verbose install logs should be telling you why it wanted to replace files that didn't change. What do your logs have to say? Blair From: Walter Dexter Sent: Monday, January 27, 2014 9:53 PM To: General discussion for Windows Installer XML toolset. I believe that is only true for versioned files, although I may be mistaken. In this particular case (properly versioned .Net 3.5 executables) they were unchanged and should not have been replaced according to my, and your, understanding of the rules. Despite that, Windows Installer was killing them off. Perhaps it just shoots first and asks questions later unless told to not terminate. I have no idea. On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: 2014-01-27 Walter Dexter wfdex...@gmail.com: Got it! I haven't worked out all the details but changing the MSIRMSHUTDOWN property to 0 makes it do what I wanted. Note that in this case the .exe files that I want to keep running aren't actually being modified. Our deployment folks just don't like to deal with distribution of patches; they'd rather send out a full MSI. Windows Installer only overwrites files that have changed; patch or no patch is irrelevant. -- Nicolás -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated
Re: [WiX-users] Install busy executables at reboot - Windows 7
And there's the answer. They're all in the same feature. Can I move existing files between features in an upgrade? That would position me better the next time around. On Jan 28, 2014, at 4:36 AM, Blair Murri os...@live.com wrote: Are you doing a major upgrade or a recache/repair? Are the files it was killing off in the same feature as other files that were changed? Remember that features are installed/repaired/removed as a unit. Your verbose install logs should be telling you why it wanted to “replace” files that “didn’t change”. What do your logs have to say? Blair From: Walter Dexter Sent: Monday, January 27, 2014 9:53 PM To: General discussion for Windows Installer XML toolset. I believe that is only true for versioned files, although I may be mistaken. In this particular case (properly versioned .Net 3.5 executables) they were unchanged and should not have been replaced according to my, and your, understanding of the rules. Despite that, Windows Installer was killing them off. Perhaps it just shoots first and asks questions later unless told to not terminate. I have no idea. On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: 2014-01-27 Walter Dexter wfdex...@gmail.com: Got it! I haven't worked out all the details but changing the MSIRMSHUTDOWN property to 0 makes it do what I wanted. Note that in this case the .exe files that I want to keep running aren't actually being modified. Our deployment folks just don't like to deal with distribution of patches; they'd rather send out a full MSI. Windows Installer only overwrites files that have changed; patch or no patch is irrelevant. -- Nicolás -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install busy executables at reboot - Windows 7
In my case the installer is always run as quiet and there's no interactions with any user. Our goal is to slip in and deliver stuff without their noticing. I naively put everything in a single feature. it sounds like I would be better served to sort the files into features based on actual dependencies, so one feature might be a single .exe and any files it requires to run. On Tue, Jan 28, 2014 at 12:19 PM, Phil Wilson phildgwil...@gmail.comwrote: You could move files (strictly components) around, but in most installs the features are units of functionality and not random collections of assorted files. A feature is the user's unit of functionality that can be added or removed, and moving files out of one often requires other changes such as help and docs that say installing feature X gives you this functionality because it no longer does. As Blair says, look at the verbose log. In the absence of hard evidence that says what's really happening it seems premature to change feature content. --- Phil Wilson On Tue, Jan 28, 2014 at 5:44 AM, Walt Dexter wfdex...@gmail.com wrote: And there's the answer. They're all in the same feature. Can I move existing files between features in an upgrade? That would position me better the next time around. On Jan 28, 2014, at 4:36 AM, Blair Murri os...@live.com wrote: Are you doing a major upgrade or a recache/repair? Are the files it was killing off in the same feature as other files that were changed? Remember that features are installed/repaired/removed as a unit. Your verbose install logs should be telling you why it wanted to replace files that didn't change. What do your logs have to say? Blair From: Walter Dexter Sent: Monday, January 27, 2014 9:53 PM To: General discussion for Windows Installer XML toolset. I believe that is only true for versioned files, although I may be mistaken. In this particular case (properly versioned .Net 3.5 executables) they were unchanged and should not have been replaced according to my, and your, understanding of the rules. Despite that, Windows Installer was killing them off. Perhaps it just shoots first and asks questions later unless told to not terminate. I have no idea. On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: 2014-01-27 Walter Dexter wfdex...@gmail.com: Got it! I haven't worked out all the details but changing the MSIRMSHUTDOWN property to 0 makes it do what I wanted. Note that in this case the .exe files that I want to keep running aren't actually being modified. Our deployment folks just don't like to deal with distribution of patches; they'd rather send out a full MSI. Windows Installer only overwrites files that have changed; patch or no patch is irrelevant. -- Nicolás -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip
Re: [WiX-users] Install busy executables at reboot - Windows 7
So far as the logs, I have yet to ever find anything I can make sense of in an MSI log. I'm well aware that's my own deficiency but those things are 99.95% unintelligible to me. On Tue, Jan 28, 2014 at 2:46 PM, Walter Dexter wfdex...@gmail.com wrote: In my case the installer is always run as quiet and there's no interactions with any user. Our goal is to slip in and deliver stuff without their noticing. I naively put everything in a single feature. it sounds like I would be better served to sort the files into features based on actual dependencies, so one feature might be a single .exe and any files it requires to run. On Tue, Jan 28, 2014 at 12:19 PM, Phil Wilson phildgwil...@gmail.comwrote: You could move files (strictly components) around, but in most installs the features are units of functionality and not random collections of assorted files. A feature is the user's unit of functionality that can be added or removed, and moving files out of one often requires other changes such as help and docs that say installing feature X gives you this functionality because it no longer does. As Blair says, look at the verbose log. In the absence of hard evidence that says what's really happening it seems premature to change feature content. --- Phil Wilson On Tue, Jan 28, 2014 at 5:44 AM, Walt Dexter wfdex...@gmail.com wrote: And there's the answer. They're all in the same feature. Can I move existing files between features in an upgrade? That would position me better the next time around. On Jan 28, 2014, at 4:36 AM, Blair Murri os...@live.com wrote: Are you doing a major upgrade or a recache/repair? Are the files it was killing off in the same feature as other files that were changed? Remember that features are installed/repaired/removed as a unit. Your verbose install logs should be telling you why it wanted to replace files that didn't change. What do your logs have to say? Blair From: Walter Dexter Sent: Monday, January 27, 2014 9:53 PM To: General discussion for Windows Installer XML toolset. I believe that is only true for versioned files, although I may be mistaken. In this particular case (properly versioned .Net 3.5 executables) they were unchanged and should not have been replaced according to my, and your, understanding of the rules. Despite that, Windows Installer was killing them off. Perhaps it just shoots first and asks questions later unless told to not terminate. I have no idea. On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: 2014-01-27 Walter Dexter wfdex...@gmail.com: Got it! I haven't worked out all the details but changing the MSIRMSHUTDOWN property to 0 makes it do what I wanted. Note that in this case the .exe files that I want to keep running aren't actually being modified. Our deployment folks just don't like to deal with distribution of patches; they'd rather send out a full MSI. Windows Installer only overwrites files that have changed; patch or no patch is irrelevant. -- Nicolás -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install busy executables at reboot - Windows 7
Got it!
I haven't worked out all the details but changing the MSIRMSHUTDOWN
property to 0 makes it do what I wanted. Note that in this case the .exe
files that I want to keep running aren't actually being modified. Our
deployment folks just don't like to deal with distribution of patches;
they'd rather send out a full MSI.
Here are the properties I have set, in case some future reader comes upon
this thread. I think it's only the last three that matter but I haven't dug
through all of the Reinstall... ones.
Property Id=REBOOT Admin=yes Secure=yesReallySuppress/Property
Property Id=ARPNOMODIFY Value=1 /
Property Id=ARPNOREPAIR Value=1 /
Property Id=DISABLEROLLBACK Value=1 /
Property Id=ReinstallFileOlderVersion Value=o /
Property Id=ReinstallFileVersion Value=o /
Property Id=ReinstallRepair Value=r /
* Property Id=MSIRESTARTMANAGERCONTROL Value=0 / *
* Property Id=MSIRMSHUTDOWN Value=2 / *
* Property Id=MSIDISABLERMRESTART Value=0 /*
On Sun, Jan 26, 2014 at 7:00 AM, Walter Dexter wfdex...@gmail.com wrote:
I tried that. Disable just makes it use the older method instead of the
restart manager. In practical terms, it's just a different dialog box if
you don't use the /quiet option, and no difference in behavior if you do.
I'm going to try actually having the restart manager restart them and see
how disruptive that is,but it wouldn't surprise me if the default quiet
behavior is to not restart.
On Jan 25, 2014 12:42 PM, Rob Mensching r...@robmensching.com wrote:
Maybe MSIRESTARTMANAGERCONTROL is the one that would actually help. Your
example shows a 0. You might use Disable. Ultimately, all this is
documented here:
http://msdn.microsoft.com/en-us/library/aa372059(v=vs.85).aspx
-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com]
Sent: Saturday, January 25, 2014 9:12 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Install busy executables at reboot - Windows 7
I tried MSIRMSHUTDOWN = 2, and REBOOT is = ReallySuppress. Behavior is
the same - with /quiet it just quietly kills the exe off, without /quiet it
asks me what to do (the Reinstall Manager prompt.)
I hate to drop a giant XML bomb on the forum, but here's a (trimmed down,
believe it or not) WXS file.
If you (Rob) or anyone has some advice, I sure appreciate it. Otherwise I
guess I'll just do the console logoff as a custom action and take some more
time to figure it out.
Walt
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=
http://schemas.microsoft.com/wix/UtilExtension;
?define ProductName=MCO e*System Integration Files ?
?define UpgradeCode={B44477EF-7487-4302-875C-DA2846EB30DA} ?
?define ProductVersion=1.0.5.0 ? !-- Product version. --
?define MaxVersion=1.0.5.0 ? !-- Highest version this should upgrade.
Most of the time, should be same as ProductVersion.--
?define MinVersion=1.0.0.0 ? !-- Lowest version this should upgrade.
--
Product
Id=*
Name=$(var.ProductName)
Language=1033
Version=$(var.ProductVersion)
Manufacturer=Our Co, LLC
UpgradeCode=$(var.UpgradeCode)
Package
InstallerVersion=300
Compressed=yes
InstallScope=perMachine
Comments=No detail.
Description=e*System Integration Programs
Manufacturer=US e*System Integration - Walt Dexter -
walter.dex...@example.com /
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion
IgnoreRemoveFailure=yes
IncludeMinimum=yes
IncludeMaximum=yes
Minimum=$(var.MinVersion)
Maximum=$(var.MaxVersion)
MigrateFeatures=yes
Property=UPGRADE_1
/UpgradeVersion
/Upgrade
MediaTemplate EmbedCab=yes CompressionLevel=high /
Feature Id=FEAT_ALLFILES Title=e*System Integration Files Level=1
ComponentGroupRef Id=CMPG_SCRIPTS /
/Feature
Property Id=REBOOT Admin=yes Secure=yesReallySuppress/Property
Property Id=ARPCOMMENTSe*System Application from
Metametrics/Property
Property Id=ARPCONTACTUS e*Restaurant Integration - Walt
Dexter/Property
Property Id=ARPNOMODIFY Value=1 /
Property Id=ARPNOREPAIR Value=1 /
Property Id=DISABLEROLLBACK Value=1 /
!-- Property Id=REINSTALLMODE Value=amus / --
Property Id=MSIRESTARTMANAGERCONTROL Value=0 /
Property Id=MSIRMSHUTDOWN Value=2 /
Property Id=ReinstallFileOlderVersion Value=o /
Property Id=ReinstallFileVersion Value=o /
Property Id=ReinstallRepair Value=r /
Property Id=MCO___APP_TYPE Value=$(var.ProductName) /
CustomAction Id=CA_SetCDrive Directory=C_DRIVE Value=c:\ /
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
Custom Action=CA_SetCDrive After=CostFinalize /
/InstallExecuteSequence
Directory Id=TARGETDIR Name=SourceDir
Directory Id=C_DRIVE Name=CDrive
Directory Id=DIR_PROGRAMDATA Name=ProgramData
Directory Id=DIR_MICROSOFT Name=Microsoft
Directory Id=DIR_POINTOFSERVICE Name=Point of Service
Directory Id=DIR_CONFIGURATION Name=Configuration /
/Directory
Re: [WiX-users] 'http://schemas.microsoft.com/wix/UtilExtension'
If you're talking about this error from candle, or a similar one from light: error CNDL0200 : The Component element contains an unhandled extension element 'Util:blahblahblah'. Please ensure that the extension for elements in the 'http://schemas.microsoft.com/wix/UtilExtension' namespace has been provided. I just hit and resolved this (about an hour ago) by adding the following to both candle and light command lines: -ext c:\Program Files (x86)\WiX Toolset v3.7\bin\WixUtilExtension.dll Obviously your path may vary. On Mon, Jan 27, 2014 at 10:25 AM, Carter Young ecyo...@grandecom.netwrote: Try this Format: ServiceInstall Id=WhateverServiceInstall Name=WhateverService DisplayName=WhateverService Type=ownProcess Start=auto ErrorControl=normal Description=WhateverService Service Vital=yes PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=Administrator ServiceChangeConfig=yes ServiceEnumerateDependents=yes ChangePermission=yes ServiceInterrogate=yes ServicePauseContinue=yes ServiceQueryConfig=yes ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / ServiceConfig xmlns=http://schemas.microsoft.com/wix/UtilExtension; RebootMessage =Problem with Service requires a reboot ResetPeriodInDays=3 RestartServiceDelayInSeconds=5 FirstFailureActionType=restart SecondFailureActionType=restart ThirdFailureActionType=reboot/ ServiceDependency Id=MSSQLServer/ /ServiceInstall ServiceControl Id=WhateverServiceServiceInstaller Name=WhateverService Start=install Stop=both Remove=uninstall Wait=no / Quoting jpalmer1...@comcast.net: Any idea how to get around the reference error to UtilExtension? Or, is there a new/different way of setting a service failure action? snip -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install busy executables at reboot - Windows 7
I believe that is only true for versioned files, although I may be mistaken. In this particular case (properly versioned .Net 3.5 executables) they were unchanged and should not have been replaced according to my, and your, understanding of the rules. Despite that, Windows Installer was killing them off. Perhaps it just shoots first and asks questions later unless told to not terminate. I have no idea. On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: 2014-01-27 Walter Dexter wfdex...@gmail.com: Got it! I haven't worked out all the details but changing the MSIRMSHUTDOWN property to 0 makes it do what I wanted. Note that in this case the .exe files that I want to keep running aren't actually being modified. Our deployment folks just don't like to deal with distribution of patches; they'd rather send out a full MSI. Windows Installer only overwrites files that have changed; patch or no patch is irrelevant. -- Nicolás -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install busy executables at reboot - Windows 7
I tried that. Disable just makes it use the older method instead of the
restart manager. In practical terms, it's just a different dialog box if
you don't use the /quiet option, and no difference in behavior if you do.
I'm going to try actually having the restart manager restart them and see
how disruptive that is,but it wouldn't surprise me if the default quiet
behavior is to not restart.
On Jan 25, 2014 12:42 PM, Rob Mensching r...@robmensching.com wrote:
Maybe MSIRESTARTMANAGERCONTROL is the one that would actually help. Your
example shows a 0. You might use Disable. Ultimately, all this is
documented here:
http://msdn.microsoft.com/en-us/library/aa372059(v=vs.85).aspx
-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com]
Sent: Saturday, January 25, 2014 9:12 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Install busy executables at reboot - Windows 7
I tried MSIRMSHUTDOWN = 2, and REBOOT is = ReallySuppress. Behavior is the
same - with /quiet it just quietly kills the exe off, without /quiet it
asks me what to do (the Reinstall Manager prompt.)
I hate to drop a giant XML bomb on the forum, but here's a (trimmed down,
believe it or not) WXS file.
If you (Rob) or anyone has some advice, I sure appreciate it. Otherwise I
guess I'll just do the console logoff as a custom action and take some more
time to figure it out.
Walt
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=
http://schemas.microsoft.com/wix/UtilExtension;
?define ProductName=MCO e*System Integration Files ?
?define UpgradeCode={B44477EF-7487-4302-875C-DA2846EB30DA} ?
?define ProductVersion=1.0.5.0 ? !-- Product version. --
?define MaxVersion=1.0.5.0 ? !-- Highest version this should upgrade.
Most of the time, should be same as ProductVersion.--
?define MinVersion=1.0.0.0 ? !-- Lowest version this should upgrade.
--
Product
Id=*
Name=$(var.ProductName)
Language=1033
Version=$(var.ProductVersion)
Manufacturer=Our Co, LLC
UpgradeCode=$(var.UpgradeCode)
Package
InstallerVersion=300
Compressed=yes
InstallScope=perMachine
Comments=No detail.
Description=e*System Integration Programs
Manufacturer=US e*System Integration - Walt Dexter -
walter.dex...@example.com /
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion
IgnoreRemoveFailure=yes
IncludeMinimum=yes
IncludeMaximum=yes
Minimum=$(var.MinVersion)
Maximum=$(var.MaxVersion)
MigrateFeatures=yes
Property=UPGRADE_1
/UpgradeVersion
/Upgrade
MediaTemplate EmbedCab=yes CompressionLevel=high /
Feature Id=FEAT_ALLFILES Title=e*System Integration Files Level=1
ComponentGroupRef Id=CMPG_SCRIPTS /
/Feature
Property Id=REBOOT Admin=yes Secure=yesReallySuppress/Property
Property Id=ARPCOMMENTSe*System Application from Metametrics/Property
Property Id=ARPCONTACTUS e*Restaurant Integration - Walt
Dexter/Property
Property Id=ARPNOMODIFY Value=1 /
Property Id=ARPNOREPAIR Value=1 /
Property Id=DISABLEROLLBACK Value=1 /
!-- Property Id=REINSTALLMODE Value=amus / --
Property Id=MSIRESTARTMANAGERCONTROL Value=0 /
Property Id=MSIRMSHUTDOWN Value=2 /
Property Id=ReinstallFileOlderVersion Value=o /
Property Id=ReinstallFileVersion Value=o /
Property Id=ReinstallRepair Value=r /
Property Id=MCO___APP_TYPE Value=$(var.ProductName) /
CustomAction Id=CA_SetCDrive Directory=C_DRIVE Value=c:\ /
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
Custom Action=CA_SetCDrive After=CostFinalize /
/InstallExecuteSequence
Directory Id=TARGETDIR Name=SourceDir
Directory Id=C_DRIVE Name=CDrive
Directory Id=DIR_PROGRAMDATA Name=ProgramData
Directory Id=DIR_MICROSOFT Name=Microsoft
Directory Id=DIR_POINTOFSERVICE Name=Point of Service
Directory Id=DIR_CONFIGURATION Name=Configuration /
/Directory
/Directory
Directory Id=DIR_EPSON Name=epson
Directory Id=DIR_PORTCOMMUNICATIONSERVICE
Name=portcommunicationservice /
/Directory
/Directory
Directory Id=DIR_MCOUSA Name=MCOUSA
Directory Id=DIR_SCRIPTS Name=Scripts /
Directory Id=DIR_CONFIG_BASE Name=config.base /
Directory Id=DIR_CONFIG Name=config /
/Directory
Directory Id=DIR_XPESTAGING Name=XPeStaging
Directory Id=DIR_APP Name=App /
/Directory
/Directory
/Directory
ComponentGroup Id=CMPG_SCRIPTS Directory=DIR_SCRIPTS
Component Id=CMP_ESCINT_EXE
Guid={E99F5E86-2CDB-4EB9-A638-54144CDD50FD}
File Source=..\..\source\MCOUSA_eSC_Int\MCOUSA_eSC_Int\bin\Release\
Id=eSCInt.exe DefaultVersion=$(var.ProductVersion) KeyPath=yes /
/Component
Component Id=CMP_MCOHTMLWATCHER_EXE
Guid={DE351116-CA6E-4A27-9351-56A3B674F536}
File Source=..\..\source\MCOUSA_eSC_Int\MCOHTMLWatcher\bin\Release\
Id=MCOHtmlWatcher.exe DefaultVersion=$(var.ProductVersion)
KeyPath=yes /
/Component
Re: [WiX-users] Install busy executables at reboot - Windows 7
I tried MSIRMSHUTDOWN = 2, and REBOOT is = ReallySuppress. Behavior is the
same - with /quiet it just quietly kills the exe off, without /quiet it
asks me what to do (the Reinstall Manager prompt.)
I hate to drop a giant XML bomb on the forum, but here's a (trimmed down,
believe it or not) WXS file.
If you (Rob) or anyone has some advice, I sure appreciate it. Otherwise I
guess I'll just do the console logoff as a custom action and take some more
time to figure it out.
Walt
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=
http://schemas.microsoft.com/wix/UtilExtension;
?define ProductName=MCO e*System Integration Files ?
?define UpgradeCode={B44477EF-7487-4302-875C-DA2846EB30DA} ?
?define ProductVersion=1.0.5.0 ? !-- Product version. --
?define MaxVersion=1.0.5.0 ? !-- Highest version this should upgrade.
Most of the time, should be same as ProductVersion.--
?define MinVersion=1.0.0.0 ? !-- Lowest version this should upgrade.
--
Product
Id=*
Name=$(var.ProductName)
Language=1033
Version=$(var.ProductVersion)
Manufacturer=Our Co, LLC
UpgradeCode=$(var.UpgradeCode)
Package
InstallerVersion=300
Compressed=yes
InstallScope=perMachine
Comments=No detail.
Description=e*System Integration Programs
Manufacturer=US e*System Integration - Walt Dexter -
walter.dex...@example.com /
Upgrade Id=$(var.UpgradeCode)
UpgradeVersion
IgnoreRemoveFailure=yes
IncludeMinimum=yes
IncludeMaximum=yes
Minimum=$(var.MinVersion)
Maximum=$(var.MaxVersion)
MigrateFeatures=yes
Property=UPGRADE_1
/UpgradeVersion
/Upgrade
MediaTemplate EmbedCab=yes CompressionLevel=high /
Feature Id=FEAT_ALLFILES Title=e*System Integration Files Level=1
ComponentGroupRef Id=CMPG_SCRIPTS /
/Feature
Property Id=REBOOT Admin=yes Secure=yesReallySuppress/Property
Property Id=ARPCOMMENTSe*System Application from Metametrics/Property
Property Id=ARPCONTACTUS e*Restaurant Integration - Walt
Dexter/Property
Property Id=ARPNOMODIFY Value=1 /
Property Id=ARPNOREPAIR Value=1 /
Property Id=DISABLEROLLBACK Value=1 /
!-- Property Id=REINSTALLMODE Value=amus / --
Property Id=MSIRESTARTMANAGERCONTROL Value=0 /
Property Id=MSIRMSHUTDOWN Value=2 /
Property Id=ReinstallFileOlderVersion Value=o /
Property Id=ReinstallFileVersion Value=o /
Property Id=ReinstallRepair Value=r /
Property Id=MCO___APP_TYPE Value=$(var.ProductName) /
CustomAction Id=CA_SetCDrive Directory=C_DRIVE Value=c:\ /
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
Custom Action=CA_SetCDrive After=CostFinalize /
/InstallExecuteSequence
Directory Id=TARGETDIR Name=SourceDir
Directory Id=C_DRIVE Name=CDrive
Directory Id=DIR_PROGRAMDATA Name=ProgramData
Directory Id=DIR_MICROSOFT Name=Microsoft
Directory Id=DIR_POINTOFSERVICE Name=Point of Service
Directory Id=DIR_CONFIGURATION Name=Configuration /
/Directory
/Directory
Directory Id=DIR_EPSON Name=epson
Directory Id=DIR_PORTCOMMUNICATIONSERVICE
Name=portcommunicationservice /
/Directory
/Directory
Directory Id=DIR_MCOUSA Name=MCOUSA
Directory Id=DIR_SCRIPTS Name=Scripts /
Directory Id=DIR_CONFIG_BASE Name=config.base /
Directory Id=DIR_CONFIG Name=config /
/Directory
Directory Id=DIR_XPESTAGING Name=XPeStaging
Directory Id=DIR_APP Name=App /
/Directory
/Directory
/Directory
ComponentGroup Id=CMPG_SCRIPTS Directory=DIR_SCRIPTS
Component Id=CMP_ESCINT_EXE
Guid={E99F5E86-2CDB-4EB9-A638-54144CDD50FD}
File Source=..\..\source\MCOUSA_eSC_Int\MCOUSA_eSC_Int\bin\Release\
Id=eSCInt.exe DefaultVersion=$(var.ProductVersion) KeyPath=yes /
/Component
Component Id=CMP_MCOHTMLWATCHER_EXE
Guid={DE351116-CA6E-4A27-9351-56A3B674F536}
File Source=..\..\source\MCOUSA_eSC_Int\MCOHTMLWatcher\bin\Release\
Id=MCOHtmlWatcher.exe DefaultVersion=$(var.ProductVersion)
KeyPath=yes /
/Component
/ComponentGroup
/Product
/Wix
On Fri, Jan 24, 2014 at 10:35 PM, Rob Mensching r...@robmensching.comwrote:
What about the MSIRMSHUTDOWN property and maybe the REBOOT property.
-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com]
Sent: Friday, January 24, 2014 8:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Install busy executables at reboot - Windows 7
I have an embedded system running Windows POSReady 7 (Windows 7 for POS
devices.)
I have an MSI that installs a collection of .Net .exe files, VBScripts,
and other stuff.
Three of the executables are always running under a user account. That's
just a normal thing on this device - it boots, automatically logs in as a
specific user, and these executables start.
I'm now trying to do a upgrade by doing a Major Upgrade of the prior MSI.
That's actually working fine. My problem is that Windows Installer seems
to be shutting down the executables that are always running to do the
install
[WiX-users] Install busy executables at reboot - Windows 7
I have an embedded system running Windows POSReady 7 (Windows 7 for POS devices.) I have an MSI that installs a collection of .Net .exe files, VBScripts, and other stuff. Three of the executables are always running under a user account. That's just a normal thing on this device - it boots, automatically logs in as a specific user, and these executables start. I'm now trying to do a upgrade by doing a Major Upgrade of the prior MSI. That's actually working fine. My problem is that Windows Installer seems to be shutting down the executables that are always running to do the install. I've read a bit about the restart manager, and other things, but all I really want it to do is make a note that these files are to be replaced at the next reboot (which happens at 4:00 AM every day) and leave the executables running. We run the MSIs out of the usual set of Microsoft system management tools (SCCM? SCOM? It isn't my area so I don't real know) so there's no UI, and no user to say shut them down and restart them. Honestly I haven't tried this out of the Microsoft infrastructure; I'm just firing up a runas /user:administrator cmd.exe and running the MSI with the /quiet flag. I guess it's possible that it will behave differently there but it seems unlikely. So is there a way to get it to do this? I've read a bit about the restart manager and messed about with various property values but none of it seemed to have any impact. If I run without /quiet it presented a variety of different dialogs telling me the programs needed to be stopped, sometimes offering to do it and restart them later. If I run with /quiet, it always quietly kills them and doesn't restart them. My fallback position is to have the MSI logoff the console - whiich is trivial to do - because it will then autolog back on and start all the programs up. It's a lot easier politically if I can hand off an MSI that the users don't notice installing. If they notice it - if the programs stop and restart, or if it logs off and back on - then we've got a lot of communication that needs to happen. Thanks for any advice! Walt -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with installer admin privileges
So your entire target machine population has had that done? On Nov 22, 2013, at 9:43 AM, RussellResthaven russellrestha...@gmail.com wrote: Never mind, looks like I found the answer. I've always disliked Windows 7 UAC security where it gives a pop-up every time anything wants to change my system, which is often (java, flash, etc). So the first thing I do whenever I setup a machine is slide the slider down to the bottom to select never warn me. This has the benefit of never bothering me, but the downside is that it suppresses any login dialogs needed to elevate a process. It turns out Wix is no exception, the installer will not ask you for credentials on a perMachine install if all UAC warnings are turned off. My workaround is just do a perUser install and install the files to AppData. I know it's not the suggested way of doing things, but I have no choice. Thanks. On Fri, Nov 22, 2013 at 6:23 AM, Blair Murri os...@live.com wrote: If you open up the MSI in Orca and View → Summary Information, you should see a checkbox near the bottom (in the Source Image box) of the dialog: UAC Compliant. It should be “not checked”. Then look in the Property table. You should find a property named ALLUSERS that is set to the value of 1. If either of those isn’t the case, tell us exactly what combination you see. If both of those are the case, what do other MSIs do on that box? -Blair From: RussellResthaven Sent: Thursday, November 21, 2013 9:36 PM To: General discussion for Windows Installer XML toolset. I need to have a very simple installer do a perMachine install where the program is installed to the program files folder, shortcuts created on the desktop and start menu, and basic registry settings created to record the install for the uninstall. I am running Windows 7, x64 and am working in Visual Studio 2010 with Wix 3.7. My project and the installer target x64 platforms only. The problem: This works perfectly fine on an admin account, however most people are not admins on their machines. What I need is for a non-admin user to be presented with the admin prompt when installing to allow them to enter admin credentials, or at least a user with admin privileges. Currently, no matter what I do, the prompt *never* comes up and the installation *always* fails. I have tried all of the following: -MSI Setup Project: Package: Keywords=InstallerPlatform=x64Description=MyProductComments=MyProductManufacturer=MyProductInstallScope=perMachineInstallerVersion=400InstallPrivileges=elevatedCompressed=yesLanguages=1033SummaryCodepage=1252 Changing between perMachine and perUser makes no difference, ditto that for elevated vs. limited. Next, every combination of none, one, some, or all of these makes no difference: Property Id=ALLUSERS Value=2 /Property Id=MSIUSEREALADMINDETECTION Value=1 /Property Id=MSIFASTINSTALL Value=1 / At this point, I tried playing with a bootstrapper, following those instructions and that too provides nothing helpful. ChainMsiPackage DisplayInternalUI=yes SourceFile=$(var.SolutionDir)..\..\..\Bin\$(var.Platform)\$(var.Configuration)\MyProductSetup.msi //Chain First, the bootstrapper gives a generic UI that is not what is specified in my MSI. I've tried adding the DisplayInternalUI=yes value and it doesn't display the MSI UI. Further, the same exact problem happens where it fails due to lack of privileges. I also read that it might have the intended behavior if the filenames have the word setup in them. I tried that too, to no avail. So that sent me off in the direction of trying to change the manifest. Using the command suggested by various folks on different boards and mailing lists has the unfortunate effect of stripping the entire MSI out of the boostrapper exe. Whereas before I run mt.exe, it's about 10MB. After I run it, it's stripped down to about 300k and is ruined. Next I tried a program called ResourceHacker to manually edit the manifest in place to be: requestedExecutionLevel level=requireAdministrator uiAccess=true / While this did not cripple the file, like all other attempts it did nothing. At this point I'm completely out of ideas, hence this email. I am starting to think there might be something wrong with my machine. I am testing with a basic user account that I made specifically for testing this scenario. Again, when running as a user with admin privileges, everything works fine either when running the MSI directly or through the bootstrapper.exe. When running with the basic account, both fail. I'm two weeks into it and am totally out of ideas and time. Any help would be greatly appreciated. Thanks. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech
Re: [WiX-users] Microsoft Reciprocal License explaination
Considering local internal changes to WiX a competitive advantage seems indicative of a marginal business plan at best. More likely is the opposite. If I were to modify it for internal use I would have no idea how to get authorization to do so, and nobody would be willing to figure it out. On Nov 20, 2013, at 3:36 AM, Bruce Cran br...@cran.org.uk wrote: On 11/20/2013 8:52 AM, John Ludlow wrote: The only reason I can see not to do this is because it depends on proprietary code, which either has no use outside your environment, or is considered part of your own product and can't be distributed. Or if you think the changes are so awesome you want to prevent your competitors from getting the improvements :) -- Bruce Cran -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where the msi file resides while setup installation created by wix burn bootstrapper
Is the problem that you no longer have the MSI except as it exists in the .exe and you need it? On Saturday, November 9, 2013, Periyasamy wrote: Hi Rob, Here is the requirement: I have developed the installers using WIX Burn, one of our developer now wants to extract the msi file from that BURN generated exe. Then he wants to add some other preprequisites files and recreate the exe using his Wix Burn (Bundle). Is there a way to extract the msi file for the above mentioned scenario ? Thanks, -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-the-msi-file-resides-while-setup-installation-created-by-wix-burn-bootstrapper-tp7590453p7590496.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/wix-users -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File version
Thanks a lot, Chris. I was 99.9% sure that was the case. It's a Java program. They haven't said, but based on strings in the executable, they're Ej-technologies' exe4j to make an EXE. Based on the exe4j documentation, one step on the way through the wizard is to set the version resource values, so it doesn't seem like it should be hard. What they said was their developers had a meeting and decided to do this when I asked them to put in version resources. So 0.0.0.0 as a file version is a conscious decision! These guys are interesting to work with sometimes. On Thu, Oct 31, 2013 at 7:20 AM, Christopher Painter chr...@iswix.comwrote: Yes, that's going to be a problem. There are ways to mitigate it but is there any chance they can fix this? What tool are they using to make the EXE? From: Walter Dexter wfdex...@gmail.com Sent: Thursday, October 31, 2013 12:17 AM To: General discussion for Windows Installer XML toolset. WiX-users@lists.sourceforge.net Subject: [WiX-users] File version Hi, folks. Sorry to ask such naive (and honestly, non-WiX) questions, but... when installing from an MSI, Windows Installer makes decisions on EXE files based on the file version resource in the file, right? I have a vendor releasing software to me where they've set the Product version in their EXE and intend to increment it as versions change, but they have set the File version to 0.0.0.0 and don't intend to ever change it. I have no idea why they think this is sensible behavior, but it's what they intend to do. I get the joy of packaging their stuff into MSI, so I'm hoping someone can tell me if this is going to be a problem when upgrading. Thanks! Walt -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File version
The developers are a vendor to whom we pay an astonishing amount of money. I'm just opening a defect and telling them it's stupid. I'm sure someone at some level (even if I have to make it up to my Senior Director talking to their CTO) will make them see the light. On Thu, Oct 31, 2013 at 12:03 PM, Phil Wilson phildgwil...@gmail.comwrote: Sometimes, if you explain to them that the entire Windows update method for everything (their updates, Windows hotfixes, patches, service packs etc) is based on file versions they might come around. If not, make the caveat that everything they attempt will be more work and more unreliable. Phil Wilson On Thu, Oct 31, 2013 at 8:25 AM, Christopher Painter chr...@iswix.com wrote: Understood. I've dealt with these types over the years. I don't have much patience for it and can usually things done the right way. But when it becomes obvious that the mountain will not move, I break out my bag of tricks to keep the train moving. I prefer not to though. From: Walter Dexter wfdex...@gmail.com Sent: Thursday, October 31, 2013 10:18 AM To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] File version Thanks a lot, Chris. I was 99.9% sure that was the case. It's a Java program. They haven't said, but based on strings in the executable, they're Ej-technologies' exe4j to make an EXE. Based on the exe4j documentation, one step on the way through the wizard is to set the version resource values, so it doesn't seem like it should be hard. What they said was their developers had a meeting and decided to do this when I asked them to put in version resources. So 0.0.0.0 as a file version is a conscious decision! These guys are interesting to work with sometimes. On Thu, Oct 31, 2013 at 7:20 AM, Christopher Painter chr...@iswix.comwrote: Yes, that's going to be a problem. There are ways to mitigate it but is there any chance they can fix this? What tool are they using to make the EXE? From: Walter Dexter wfdex...@gmail.com Sent: Thursday, October 31, 2013 12:17 AM To: General discussion for Windows Installer XML toolset. WiX-users@lists.sourceforge.net Subject: [WiX-users] File version Hi, folks. Sorry to ask such naive (and honestly, non-WiX) questions, but... when installing from an MSI, Windows Installer makes decisions on EXE files based on the file version resource in the file, right? I have a vendor releasing software to me where they've set the Product version in their EXE and intend to increment it as versions change, but they have set the File version to 0.0.0.0 and don't intend to ever change it. I have no idea why they think this is sensible behavior, but it's what they intend to do. I get the joy of packaging their stuff into MSI, so I'm hoping someone can tell me if this is going to be a problem when upgrading. Thanks! Walt -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] File version
Hi, folks. Sorry to ask such naive (and honestly, non-WiX) questions, but... when installing from an MSI, Windows Installer makes decisions on EXE files based on the file version resource in the file, right? I have a vendor releasing software to me where they've set the Product version in their EXE and intend to increment it as versions change, but they have set the File version to 0.0.0.0 and don't intend to ever change it. I have no idea why they think this is sensible behavior, but it's what they intend to do. I get the joy of packaging their stuff into MSI, so I'm hoping someone can tell me if this is going to be a problem when upgrading. Thanks! Walt -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Always install
Hi, all. My install environment is our various retail systems scattered around the country. Because of the nature of retail systems, we have a LOT of drive corruption, so one of the unofficial rules is to have an installer always install files, even if they're already there and modified, even if the installer is showing as already installed. We usually create MSI files with the WISE toolset, and there it's a matter of a few drop downs and check boxes to do some of it, then they put the package's upgrade code in the upgrade table and it somehow accomplishes it. I went rebel and am trying to use WiX, but I sure can't figure out how to accomplish that. To summarize, goals are: 1. If you run the MSI, install the files, whether or not it's already installed. 2. If the file is newer, overwrite it with the one out of the MSI. I've found a bunch of different things via Google but none of them seem to be getting me there. Any advice? Thanks! -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
I think I need to better understand how custom actions really work before I'll understand why it's a bad idea. Based on what i know now, I don't understand how you get all five things if its a truly custom custom action. Guess I'll work on doing that. On Oct 15, 2013, at 6:35 AM, Christopher Painter chr...@iswix.com wrote: Walter, In reply to your yes, but.. comment earlier. No, sorry, no buts. I've worked at a number of places over the years both on the ISV side and the Enterprise side. I'm currently the deployment architect for a certain well known big box retailer that loves the color orange. We probably have more then a few stores where you live and see our commercials all day long while watching football. :-) On the store side we have somewhere around 130,000 desktops and in the total enterprise around 300,000 instances of windows. We have countless applications and for each of those we require 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all 4 actually ) to be fully supported and tested before handing off to operations for deployment. There is very little tolerance for failure from the business because a screw up results in lost sales. We don't achieve this level of excellence using Wise, InstallScript, NSIS, InnoSetup or others. We achieve it using properly designed MSIs and occasionally AppV packages. A lot of our working is spent fixing what other vendors send us as what they think are passable installer experiences. Yes, sorry, it is a lot of work to learn MSI. I was writing InstallScript installers for 7 years and was not initially impressed with MSI. In fact, you could say I was a late adopter since I didn't pick it up until 2003. It took me 6 months of banging my head against the wall trying to get it to do what I wanted before I felt comfortable. It was another 6 months before I had that been there done that feeling. Regards, Chris From: Walter Dexter wfdex...@gmail.com Sent: Tuesday, October 15, 2013 12:51 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] What is the downside to this? Rob- Thanks for the lengthy reply. I feel like I need to read it about a dozen times more to have a chance of getting everything in there. Not tonight, though. On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching r...@robmensching.comwrote: If all you're going to do is exec a bunch of batch files and vbscripts then the InnoSetup executable is probably a *far* better idea. Those scripting platforms are not the way to go to create a robust installation. However, if you were to integrate fully with the Windows Installer (which is admittedly more work and requires a lot more understanding) then you'd get functionality like rollback, error reporting, patching, resource sharing, publishing/assigning. You'd also end up with a far less complex installer... once you got the declarative parts all in place. It is too bad that the WiX toolset doesn't come with Ini file manipulation extension already. I think many people must create private one off solutions and never consider contributing back to the WiX toolset so no one ever has to implement that again. Back in 2001 I wrote custom actions for configuring IIS, SQL, users, file shares. I contributed them to the WiX toolset and for over a decade others have benefited with all the functionality I described above (rollback, patching, resource sharing, etc) by just adding a few lines of XML. We've had some contributions since (Bob did gaming extension and internet shortcut, and Fredrik gave us COM+ and MSMQ) but there are many more opportunities for people to contribute and make each other's future lives much better. So, anyway, the answer is you'd end up with a far more robust installer by doing as the others suggested. It will take more work up front because no one has contributed the Ini custom actions already. If you wanted to do the work and get Ini custom actions created, feel free to jump on the wix-d...@lists.sourceforge.net mailing list. That's where people the below were pointing you. Or you could just hack it and deal with the issues you'll probably see. In that case, I encourage you to test install, install rollback, uninstall, uninstall rollback, repair, repair rollback, and major upgrade. There are probably more scenarios to think about but I don't tend to remember them all since I try to write the custom actions as the Windows Installer SDK recommends and then it all just works together. By the way, these recommendations aren't unique to the Windows Installer. They're applicable to any installation technology you use. It's just people using the Windows Installer tend to expect all those fundamental scenarios to work so the bar is a bit higher. That's
Re: [WiX-users] What is the downside to this?
Oh, thanks. More reading. :) In a quick skim of them, I realize that most of my custom actions would be what he calls System modification custom actions. I'm not doing software that we release to the public; I'm doing packages that will ultimately get installed onto 14,000 identical systems, and some of my actions are things like create user escschd as an administrator, then create six scheduled tasks to be run by escschd or create these three network shares. The more I gaze into the MSI pond, the deeper I realize the water to be. On Tue, Oct 15, 2013 at 8:59 AM, Pally Sandher pally.sand...@iesve.comwrote: Rob M. wrote some articles on the subject a few years ago: http://robmensching.com/blog/posts/2007/8/3/zen-and-the-art-of-custom-actions http://robmensching.com/blog/posts/2007/8/10/zataoca-classes-of-custom-actions http://robmensching.com/blog/posts/2007/8/17/zataoca-custom-actions-are-generally-an-admission-of-failure http://robmensching.com/blog/posts/2007/9/13/zataoca-custom-actions-should-be-data-driven Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Walt Dexter [mailto:wfdex...@gmail.com] Sent: 15 October 2013 14:20 To: chr...@iswix.com; General discussion for Windows Installer XMLtoolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] What is the downside to this? I think I need to better understand how custom actions really work before I'll understand why it's a bad idea. Based on what i know now, I don't understand how you get all five things if its a truly custom custom action. Guess I'll work on doing that. On Oct 15, 2013, at 6:35 AM, Christopher Painter chr...@iswix.com wrote: Walter, In reply to your yes, but.. comment earlier. No, sorry, no buts. I've worked at a number of places over the years both on the ISV side and the Enterprise side. I'm currently the deployment architect for a certain well known big box retailer that loves the color orange. We probably have more then a few stores where you live and see our commercials all day long while watching football. :-) On the store side we have somewhere around 130,000 desktops and in the total enterprise around 300,000 instances of windows. We have countless applications and for each of those we require 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all 4 actually ) to be fully supported and tested before handing off to operations for deployment. There is very little tolerance for failure from the business because a screw up results in lost sales. We don't achieve this level of excellence using Wise, InstallScript, NSIS, InnoSetup or others. We achieve it using properly designed MSIs and occasionally AppV packages. A lot of our working is spent fixing what other vendors send us as what they think are passable installer experiences. Yes, sorry, it is a lot of work to learn MSI. I was writing InstallScript installers for 7 years and was not initially impressed with MSI. In fact, you could say I was a late adopter since I didn't pick it up until 2003. It took me 6 months of banging my head against the wall trying to get it to do what I wanted before I felt comfortable. It was another 6 months before I had that been there done that feeling. Regards, Chris From: Walter Dexter wfdex...@gmail.com Sent: Tuesday, October 15, 2013 12:51 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] What is the downside to this? Rob- Thanks for the lengthy reply. I feel like I need to read it about a dozen times more to have a chance of getting everything in there. Not tonight, though. On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching r...@robmensching.comwrote: If all you're going to do is exec a bunch of batch files and vbscripts then the InnoSetup executable is probably a *far* better idea. Those scripting platforms are not the way to go to create a robust installation. However, if you were to integrate fully with the Windows Installer (which is admittedly more work and requires a lot more understanding) then you'd get functionality like rollback, error reporting, patching, resource sharing, publishing/assigning. You'd also end up with a far less complex installer... once you got the declarative parts all in place. It is too bad that the WiX toolset doesn't come with Ini file manipulation extension already. I think many people must create private one off solutions
[WiX-users] What is the downside to this?
I'm working on transitioning from Inno Setup to WiX due to corporate standards. I have some Inno that are fairly complex, running programs, setting INI values, registry settings, etc. If I set the Inno to not make itself uninstallable, I could just move the files out of it to an MSI, include the action-only Inno in the MSI, and run it as a custom action. The MSI would install files and the embedded Inno would do the other stuff. Does that make any sense at all? Is it inspired or crazy? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
I totally understand what you're saying. But... As far as I can tell, I'm going to have to do custom actions to do a bunch of the stuff that Inno does easily. Like updating an INI file or running a program. If I move everything out of Inno to WiX that an MSI can do natively - which appears to really just be registry settings, files and directories - what do I lose by keeping the stuff that has to be a custom action inside an Inno and treating that Inno as a single custom action? What I gain is that I have an Inno setup that I know already works, and when it gives troubles, I have an environment that lets me do some interactive debugging. If I write a C# custom action DLL (which seems like a lot of work) all it's going to do is a bunch of Exec commands to run other installers, batch files and VBScripts. I'm fairly MSI and WiX naive. That's why I'm asking - I just totally don't understand what I gain by doing it right with a DLL for custom actions versus delivering an executable that does the stuff I want to do that happens to have been created with Inno Setup. Honestly, your response didn't add much to my understanding, but I'm sure it's more me than you. On Mon, Oct 14, 2013 at 7:36 PM, Christopher Painter chr...@iswix.comwrote: IMO it's crazy. You have to ask yourself WHY Windows Installer is the corporate standard in the first place. MSI is transactional, declarative, rich in meta data and transformable with standardized behaviors. You lose all of that when you choose to use it merely as a glorified ZIP and do everything else out of process. From: Walter Dexter wfdex...@gmail.com Sent: Monday, October 14, 2013 7:21 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: [WiX-users] What is the downside to this? I'm working on transitioning from Inno Setup to WiX due to corporate standards. I have some Inno that are fairly complex, running programs, setting INI values, registry settings, etc. If I set the Inno to not make itself uninstallable, I could just move the files out of it to an MSI, include the action-only Inno in the MSI, and run it as a custom action. The MSI would install files and the embedded Inno would do the other stuff. Does that make any sense at all? Is it inspired or crazy? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
Rob- Thanks for the lengthy reply. I feel like I need to read it about a dozen times more to have a chance of getting everything in there. Not tonight, though. On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching r...@robmensching.comwrote: If all you're going to do is exec a bunch of batch files and vbscripts then the InnoSetup executable is probably a *far* better idea. Those scripting platforms are not the way to go to create a robust installation. However, if you were to integrate fully with the Windows Installer (which is admittedly more work and requires a lot more understanding) then you'd get functionality like rollback, error reporting, patching, resource sharing, publishing/assigning. You'd also end up with a far less complex installer... once you got the declarative parts all in place. It is too bad that the WiX toolset doesn't come with Ini file manipulation extension already. I think many people must create private one off solutions and never consider contributing back to the WiX toolset so no one ever has to implement that again. Back in 2001 I wrote custom actions for configuring IIS, SQL, users, file shares. I contributed them to the WiX toolset and for over a decade others have benefited with all the functionality I described above (rollback, patching, resource sharing, etc) by just adding a few lines of XML. We've had some contributions since (Bob did gaming extension and internet shortcut, and Fredrik gave us COM+ and MSMQ) but there are many more opportunities for people to contribute and make each other's future lives much better. So, anyway, the answer is you'd end up with a far more robust installer by doing as the others suggested. It will take more work up front because no one has contributed the Ini custom actions already. If you wanted to do the work and get Ini custom actions created, feel free to jump on the wix-d...@lists.sourceforge.net mailing list. That's where people the below were pointing you. Or you could just hack it and deal with the issues you'll probably see. In that case, I encourage you to test install, install rollback, uninstall, uninstall rollback, repair, repair rollback, and major upgrade. There are probably more scenarios to think about but I don't tend to remember them all since I try to write the custom actions as the Windows Installer SDK recommends and then it all just works together. By the way, these recommendations aren't unique to the Windows Installer. They're applicable to any installation technology you use. It's just people using the Windows Installer tend to expect all those fundamental scenarios to work so the bar is a bit higher. That's why corporations tend to standardize on the Windows Installer. The Windows Installer makes their life easier. That seems fair to me. Hopefully, there are (many, manymore people installing your software than there are building it... which means saving the customer problems by taking on the work in development is a good trade (economically speaking). On Mon, Oct 14, 2013 at 9:59 PM, Walter Dexter wfdex...@gmail.com wrote: I totally understand what you're saying. But... As far as I can tell, I'm going to have to do custom actions to do a bunch of the stuff that Inno does easily. Like updating an INI file or running a program. If I move everything out of Inno to WiX that an MSI can do natively - which appears to really just be registry settings, files and directories - what do I lose by keeping the stuff that has to be a custom action inside an Inno and treating that Inno as a single custom action? What I gain is that I have an Inno setup that I know already works, and when it gives troubles, I have an environment that lets me do some interactive debugging. If I write a C# custom action DLL (which seems like a lot of work) all it's going to do is a bunch of Exec commands to run other installers, batch files and VBScripts. I'm fairly MSI and WiX naive. That's why I'm asking - I just totally don't understand what I gain by doing it right with a DLL for custom actions versus delivering an executable that does the stuff I want to do that happens to have been created with Inno Setup. Honestly, your response didn't add much to my understanding, but I'm sure it's more me than you. On Mon, Oct 14, 2013 at 7:36 PM, Christopher Painter chr...@iswix.com wrote: IMO it's crazy. You have to ask yourself WHY Windows Installer is the corporate standard in the first place. MSI is transactional, declarative, rich in meta data and transformable with standardized behaviors. You lose all of that when you choose to use it merely as a glorified ZIP and do everything else out of process. From: Walter Dexter wfdex...@gmail.com Sent: Monday, October 14, 2013 7:21 PM To: General discussion for Windows Installer XML toolset. wix-users
Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled
Yes, I saw that. The logs seemed to me to say they were removed, but the
files are in fact still there.
Any ideas?
I took the Chapter 1 example out of the WiX 3.6 Developer's Guide book,
built it and ran it on the same system and it installed and uninstalled
properly, so the system isn't fundamentally broken. If nothing uninstalled
I would have no problem believing the system is broken - they've been
hacked on for years by people who are more comfortable with Unix - but that
isn't the case here.
On Thu, Oct 10, 2013 at 3:38 AM, Rob Mensching r...@robmensching.com wrote:
Log file suggests the files were removed:
MSI (s) (60:6C) [16:04:58:163]: Executing op:
ActionStart(Name=RemoveFiles,Description=Removing files,Template=File: [1],
Directory: [9])
MSI (s) (60:6C) [16:04:58:163]: Executing op:
ProgressTotal(Total=10,Type=1,ByteEquivalent=175000)
MSI (s) (60:6C) [16:04:58:179]: Executing op:
SetTargetFolder(Folder=C:\CDrive\POS_BACKUP\SCRIPT\copy\Installers\)
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=1_eSC_MCDUSA_image.exe,,ComponentId={03D049A5-E608-4957-A8EE-8580775EF417})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=2_eSC_USA_integrations.exe,,ComponentId={A370D6C0-AED5-480D-99F2-E750FEBCCD7B})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=3_eSC_USA_programs.exe,,ComponentId={46935DA8-6E5F-45E7-8DC2-6F6C3222BB52})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
SetTargetFolder(Folder=C:\CDrive\POS_BACKUP\SCRIPT\copy\)
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=roles001.ini,,ComponentId={CAC927EC-DAB0-43D2-9336-AF0348B8EF53})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=STCReImage.cpy,,ComponentId={5D944DD7-F34C-40A7-B1AB-1B65BA4C2143})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=STCReStage.cpy,,ComponentId={20136940-8B88-420C-A621-229C4CE5AA1D})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=STCScript.cpy,,ComponentId={D064E2E4-52AF-49AB-889B-F1E35F7BF491})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=STCStaging.cpy,,ComponentId={2155BD67-8B43-4BBA-84B6-3B358FCA77F7})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=STCStartup.cpy,,ComponentId={2EEED5D1-D21F-4223-8A10-0AE1BC87B08B})
MSI (s) (60:6C) [16:04:58:179]: Executing op:
SetTargetFolder(Folder=C:\CDrive\POS_BACKUP\gum\)
MSI (s) (60:6C) [16:04:58:179]: Executing op:
FileRemove(,FileName=20130909USSTC001_PasswordChange.gum,,ComponentId={E387FF1C-6976-4F3D-80A3-A4CF2F79BC68})
On Wed, Oct 9, 2013 at 11:05 PM, Peng Lv penn...@gmail.com wrote:
I met with this issue either, my solution is adding a custom action dll
to
delete all files while uninstall, but this is way too naive.
2013/10/10 Walter Dexter wfdex...@gmail.com
I posted this at Stackoverflow as well, but I'm just at a loss for what
to
even look at, so I'm hoping someone can point me in a good direction.
I have been using WiX to create an installer for my project. It's
fairly
simple, just drop some files in three different directories and run a
VBScript to generate one last file.
I'm a total WiX and MSI noob. The standard thing to use at work is
WISE
but I just can't figure out what to do with that at all, so I gave WiX
a
try.
After some difficulties with the VBS I got the install working. When I
uninstall the package disappears out of Control Panel but the files
that
were installed are still there. I know the one I generated on the fly
is
going to be unless I do something special to remove it, but the others
should just go away, right?
I have install and uninstall logs, and also have posted the WiX source
file. Links are below.
Any help is much appreciated!
install log
https://docs.google.com/file/d/0B0qy0SfToYUzMUJYMk00UjhreDg/edit?usp=sharing
(
https://docs.google.com/file/d/0B0qy0SfToYUzUUtXVUxpQ0lESm8/edit?usp=sharing
)
WiX source
https://docs.google.com/file/d/0B0qy0SfToYUzR0FDMXc2cXhvMDQ/edit?usp=sharing
(
https://docs.google.com/file/d/0B0qy0SfToYUzR0FDMXc2cXhvMDQ/edit?usp=sharing
)
uninstall log
https://docs.google.com/file/d/0B0qy0SfToYUzUUtXVUxpQ0lESm8/edit?usp=sharing
(
https://docs.google.com/file/d/0B0qy0SfToYUzMUJYMk00UjhreDg/edit?usp=sharing
)
Note that this is being installed on Server 2003.
The package is using explicit paths and drive letters. I know that
isn't
considered best practice, but that's where the files need to go. This
doesn't go to a variety of computer types and configurations; there are
over ten thousand of these systems in our retail locations and they're
all
identical.
--
October Webinars: Code for Performance
Free Intel
Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled
It was my understanding that putting full path into Name wouldn't work. Everything I found online said what I did is the way to do it. I had a similar thought about an hour ago while driving about c_drive not getting redefined properly for the uninstall and will try to validate if that's the problem later this afternoon. I do see it and all the directories getting property changed to the right path prior to the FileRemove entries in the uninstall log, though. On Oct 10, 2013 12:47 PM, Nicolás Alvarez nicolas.alva...@gmail.com wrote: Your CA_SetCDrive is not being run during uninstallation. You'll notice the uninstall log refers to C:\CDrive\ all over the place. I don't understand why you need that custom action at all. Can't you hardcode C:\ into the Name attribute? -- Nicolás 2013/10/10 Walter Dexter wfdex...@gmail.com: I posted this at Stackoverflow as well, but I'm just at a loss for what to even look at, so I'm hoping someone can point me in a good direction. I have been using WiX to create an installer for my project. It's fairly simple, just drop some files in three different directories and run a VBScript to generate one last file. I'm a total WiX and MSI noob. The standard thing to use at work is WISE but I just can't figure out what to do with that at all, so I gave WiX a try. After some difficulties with the VBS I got the install working. When I uninstall the package disappears out of Control Panel but the files that were installed are still there. I know the one I generated on the fly is going to be unless I do something special to remove it, but the others should just go away, right? I have install and uninstall logs, and also have posted the WiX source file. Links are below. Any help is much appreciated! install log https://docs.google.com/file/d/0B0qy0SfToYUzMUJYMk00UjhreDg/edit?usp=sharing ( https://docs.google.com/file/d/0B0qy0SfToYUzUUtXVUxpQ0lESm8/edit?usp=sharing ) WiX source https://docs.google.com/file/d/0B0qy0SfToYUzR0FDMXc2cXhvMDQ/edit?usp=sharing ( https://docs.google.com/file/d/0B0qy0SfToYUzR0FDMXc2cXhvMDQ/edit?usp=sharing ) uninstall log https://docs.google.com/file/d/0B0qy0SfToYUzUUtXVUxpQ0lESm8/edit?usp=sharing ( https://docs.google.com/file/d/0B0qy0SfToYUzMUJYMk00UjhreDg/edit?usp=sharing ) Note that this is being installed on Server 2003. The package is using explicit paths and drive letters. I know that isn't considered best practice, but that's where the files need to go. This doesn't go to a variety of computer types and configurations; there are over ten thousand of these systems in our retail locations and they're all identical. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled
I just tested by copying the installed files to where the log say C_DRIVE would be prior to the redefine (in my case, e:\cdrive) and then ran the uninstall. The installed files were deleted from e:\... rather than c:\... proving this theory. Looks like I need to change when the custom action triggers. I'll try before CostInitialize and see what happens since you like it. I'm very new to both MSI and WiX. (I'm really good at Inno Setup but our corporate standard says make MSIs. It also says to use WISE which is even more confusing than WiX for me and my developer brain.) Thanks a lot! On Thu, Oct 10, 2013 at 1:33 PM, Edwin Castro 0ptikgh...@gmx.us wrote: On 10/10/13 11:08 AM, Walter Dexter wrote: I had a similar thought about an hour ago while driving about c_drive not getting redefined properly for the uninstall and will try to validate if that's the problem later this afternoon. I do see it and all the directories getting property changed to the right path prior to the FileRemove entries in the uninstall log, though. I think your CA_SetCDrive custom action is scheduled too late. I thought directories needed to be set prior to CostInitialize. -- Edwin Castro -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled
Moving the custom actions for setting the C Drive to be After CostFinalized resolved the problem. WiX threw an error when I tried before CostInitialize. Thanks! On Thu, Oct 10, 2013 at 2:20 PM, Walter Dexter wfdex...@gmail.com wrote: I just tested by copying the installed files to where the log say C_DRIVE would be prior to the redefine (in my case, e:\cdrive) and then ran the uninstall. The installed files were deleted from e:\... rather than c:\... proving this theory. Looks like I need to change when the custom action triggers. I'll try before CostInitialize and see what happens since you like it. I'm very new to both MSI and WiX. (I'm really good at Inno Setup but our corporate standard says make MSIs. It also says to use WISE which is even more confusing than WiX for me and my developer brain.) Thanks a lot! On Thu, Oct 10, 2013 at 1:33 PM, Edwin Castro 0ptikgh...@gmx.us wrote: On 10/10/13 11:08 AM, Walter Dexter wrote: I had a similar thought about an hour ago while driving about c_drive not getting redefined properly for the uninstall and will try to validate if that's the problem later this afternoon. I do see it and all the directories getting property changed to the right path prior to the FileRemove entries in the uninstall log, though. I think your CA_SetCDrive custom action is scheduled too late. I thought directories needed to be set prior to CostInitialize. -- Edwin Castro -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled
Thanks for the suggestion, but our partition layout is wacky and we need to specify what drive for sure stuff goes on. This isn't Windows workstation or server as much as it is embedded system that happens to run Windows. This appears to be working, now that I changed when the custom action runs. (In reality of course I have more Directorys under the C_DRIVE one and files and so forth.) CustomAction Id=CA_SetCDrive Directory=C_DRIVE Value=c:\ / InstallExecuteSequence Custom Action=CA_SetCDrive After=CostFinalize / /InstallExecuteSequence Directory Id=TARGETDIR Name=SourceDir Directory Id=C_DRIVE Name=CDrive / /Directory Walt On Thu, Oct 10, 2013 at 4:12 PM, Wheeler, Blaine (DSHS/DCS) bwhee...@dshs.wa.gov wrote: After fighting the default OS locations I finally convinced others around here that going with what the OS wants for directory structure is much simpler to do and more stable and takes fewer steps of code. I have a suggestion that may help and is more stable than a custom action. Set a property that is whatyou want for the root of your folder structure. In this example I use the Set WINDOWSVOLUME = [WindowsVolume] - it's always available and it is usually C: !-- WINDOWSVOLUME is the root above the Windows folder. This forces the install out of PrograFiles-- SetDirectory Id=WINDOWSVOLUME Value=[WindowsVolume]/ Directory Id=TARGETDIR Name=SourceDir Directory Id=WINDOWSVOLUME Directory Id=TopDir Name=TopDir Directory Id=SecondDir Name=SecondDir / /Directory /Directory /Directory -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Thursday, October 10, 2013 1:53 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled Moving the custom actions for setting the C Drive to be After CostFinalized resolved the problem. WiX threw an error when I tried before CostInitialize. Thanks! On Thu, Oct 10, 2013 at 2:20 PM, Walter Dexter wfdex...@gmail.com wrote: I just tested by copying the installed files to where the log say C_DRIVE would be prior to the redefine (in my case, e:\cdrive) and then ran the uninstall. The installed files were deleted from e:\... rather than c:\... proving this theory. Looks like I need to change when the custom action triggers. I'll try before CostInitialize and see what happens since you like it. I'm very new to both MSI and WiX. (I'm really good at Inno Setup but our corporate standard says make MSIs. It also says to use WISE which is even more confusing than WiX for me and my developer brain.) Thanks a lot! On Thu, Oct 10, 2013 at 1:33 PM, Edwin Castro 0ptikgh...@gmx.us wrote: On 10/10/13 11:08 AM, Walter Dexter wrote: I had a similar thought about an hour ago while driving about c_drive not getting redefined properly for the uninstall and will try to validate if that's the problem later this afternoon. I do see it and all the directories getting property changed to the right path prior to the FileRemove entries in the uninstall log, though. I think your CA_SetCDrive custom action is scheduled too late. I thought directories needed to be set prior to CostInitialize. -- Edwin Castro - - October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg. clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140
[WiX-users] Wix MSI not uninstalling files when package uninstalled
I posted this at Stackoverflow as well, but I'm just at a loss for what to even look at, so I'm hoping someone can point me in a good direction. I have been using WiX to create an installer for my project. It's fairly simple, just drop some files in three different directories and run a VBScript to generate one last file. I'm a total WiX and MSI noob. The standard thing to use at work is WISE but I just can't figure out what to do with that at all, so I gave WiX a try. After some difficulties with the VBS I got the install working. When I uninstall the package disappears out of Control Panel but the files that were installed are still there. I know the one I generated on the fly is going to be unless I do something special to remove it, but the others should just go away, right? I have install and uninstall logs, and also have posted the WiX source file. Links are below. Any help is much appreciated! install loghttps://docs.google.com/file/d/0B0qy0SfToYUzMUJYMk00UjhreDg/edit?usp=sharing ( https://docs.google.com/file/d/0B0qy0SfToYUzUUtXVUxpQ0lESm8/edit?usp=sharing ) WiX sourcehttps://docs.google.com/file/d/0B0qy0SfToYUzR0FDMXc2cXhvMDQ/edit?usp=sharing ( https://docs.google.com/file/d/0B0qy0SfToYUzR0FDMXc2cXhvMDQ/edit?usp=sharing ) uninstall loghttps://docs.google.com/file/d/0B0qy0SfToYUzUUtXVUxpQ0lESm8/edit?usp=sharing ( https://docs.google.com/file/d/0B0qy0SfToYUzMUJYMk00UjhreDg/edit?usp=sharing ) Note that this is being installed on Server 2003. The package is using explicit paths and drive letters. I know that isn't considered best practice, but that's where the files need to go. This doesn't go to a variety of computer types and configurations; there are over ten thousand of these systems in our retail locations and they're all identical. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Service Install Password not sent correctly to Windows Service
Use the User Element from the Util Extension to grant the user LogonAsService permission. If you only want to grant permission to an existing user the section would look something like this: util:User Id=ServiceUser Name=[SERVICE_USERNAME] Domain=[SERVICE_USERDOMAIN] Password=[SERVICE_USERPASSWORD] LogonAsService=yes FailIfExists=no CreateUser=no RemoveOnUninstall=no/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Service-Install-Password-not-sent-correctly-to-Windows-Service-tp754p7588892.html Sent from the wix-users mailing list archive at Nabble.com. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Slow Installs
In order to bring closure I thought I would post my resolution. I was able to 'fix' the issue by installing as another user on the system. Same machine, same install, same running apps, just a different logged on user...guessing a messed up registry but I cannot say for sure. Thank you, Dex -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Slow-Installs-tp7585123p7588893.html Sent from the wix-users mailing list archive at Nabble.com. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Slow Installs
Thank your for all the suggestions. I had already included many of the suggestions into the original installation. I am now in the process of determining why this occurs on only a few machines while others work fine. I just don't know what environmental settings could be causing such a drastic reduction in installation time. Thank you, Dex. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Slow-Installs-tp7585123p7585153.html Sent from the wix-users mailing list archive at Nabble.com. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install multiple services using single ServiceHost.exe?
It appears we are going down the right path. Thank you. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-multiple-services-using-single-ServiceHost-exe-tp7579407p7579449.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
