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] 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] 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 this
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] 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] 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] 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
