[WiX-users] Determining database permissions from custom bootstrapper / UAC issue
Hi, I've created a custom managed bootstrapper using Burn which executes an MSI during the install phase. This MSI installs/configures a database. During the UI phase I'm currently using this SQL statement to determine whether I'm allowed to create a database: SELECT COUNT(*) FROM fn_my_permissions(NULL, 'SERVER') WHERE permission_name = N'CREATE ANY DATABASE' OR permission_name = 'ALTER ANY LOGIN' This works most of the time. However, there is a scenario where this fails: The user running the setup has the required permissions on the database by means of being a member of the Builtin\Administrators group. This only gives the user the required permissions when running UAC elevated. In this case, the UI portion is run non-elevated and thus the user does not have the permissions to create databases. However, the setup would be able to create the database during the InstallExecute portion, because that part runs elevated. Is there a way to work around this issue? Or should I just ask the user whether he wants to continue with the setup despite it being unable to determine whether he has sufficient privileges? Thanks in advance, Henning -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Determining database permissions from custom bootstrapper / UAC issue
Hi, I've created a custom managed bootstrapper using Burn which executes an MSI during the install phase. This MSI installs/configures a database. During the UI phase I'm currently using this SQL statement to determine whether I'm allowed to create a database: SELECT COUNT(*) FROM fn_my_permissions(NULL, 'SERVER') WHERE permission_name = N'CREATE ANY DATABASE' OR permission_name = 'ALTER ANY LOGIN' This works most of the time. However, there is a scenario where this fails: The user running the setup has the required permissions on the database by means of being a member of the Builtin\Administrators group. This only gives the user the required permissions when running UAC elevated. In this case, the UI portion is run non-elevated and thus the user does not have the permissions to create databases. However, the setup would be able to create the database during the InstallExecute portion, because that part runs elevated. Is there a way to work around this issue? Or should I just ask the user whether he wants to continue with the setup despite it being unable to determine whether he has sufficient privileges? Thanks in advance, Henning -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition on service permissions
Ok, I implemented it via a C# Custom action. Just a handful of lines... I also thought about extending the PermissionEx element by adding a Condition property. I briefly looked at the WIX source and it doesn't look that hard. Much harder is getting the WIX source to build. Is there any documentation on this? I only need to compile the WixUtil extension, not the whole thing. @Rob: Do you see this extension as a probably feature for WIX? If I get the build process to work, I could implement the feature and create a pull request from it. Kind regards, Henning -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Mittwoch, 3. Juli 2013 10:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Condition on service permissions Unfortunately, no. From: m...@henningkrause.eu To: wix-users@lists.sourceforge.net Date: Tue, 2 Jul 2013 15:37:52 + Subject: Re: [WiX-users] Condition on service permissions Ok, an immediate custom action would do the trick. Is there anything out-of-the-box that I missed? I'd really like to avoid custom actions if I can... Kind regards, Henning Krause -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Dienstag, 2. Juli 2013 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Condition on service permissions http://www.joyofsetup.com/2007/07/01/semi-custom-actions/ From: m...@henningkrause.eu To: wix-users@lists.sourceforge.net Date: Tue, 2 Jul 2013 13:32:26 + Subject: [WiX-users] Condition on service permissions Hi all, I have a setup which installs three services: ServiceA, ServiceB and ManagementService. ServiceA and ServiceB are in different features but have a dependency on ManagementService, which lives in its own feature. SerivceA and ServiceB should be able to start/stop the ManagementService. So I use this snippet to install the service: Component Id=ManagementService Guid=... File Source=PathToFile KeyPath=yes / ServiceInstall Account=LOCALSYSTEM Id=ManagementService DisplayName=ManagementService Name=ManagementService Start=demand Type=ownProcess Description=... PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=[SERVICEAPERMISSIONACCOUNT] ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=[SERVICEBPERMISSIONACCOUNT] ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / /ServiceInstall ServiceControl Id=ManagementServiceControl Name=ManagementService Remove=uninstall Stop=both Wait=no / /Component Both services use service sids in the form NT Service\ServiceName. If I install both features, all is well and the setup succeeds. But if I don't install ServiceB, the setup fails, because the SERVICEBPERMISSIONACCOUNT resolves to a principal which does not exist. So I need to put a condition on the PermissionEx tag. Unfortunately, the PermissionEx can only be put on a ServiceInstall element. What would be the correct way to solve this? I didn't find anything on Google about this. Kind regards, Henning -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Condition on service permissions
Hi all, I have a setup which installs three services: ServiceA, ServiceB and ManagementService. ServiceA and ServiceB are in different features but have a dependency on ManagementService, which lives in its own feature. SerivceA and ServiceB should be able to start/stop the ManagementService. So I use this snippet to install the service: Component Id=ManagementService Guid=... File Source=PathToFile KeyPath=yes / ServiceInstall Account=LOCALSYSTEM Id=ManagementService DisplayName=ManagementService Name=ManagementService Start=demand Type=ownProcess Description=... PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=[SERVICEAPERMISSIONACCOUNT] ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=[SERVICEBPERMISSIONACCOUNT] ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / /ServiceInstall ServiceControl Id=ManagementServiceControl Name=ManagementService Remove=uninstall Stop=both Wait=no / /Component Both services use service sids in the form NT Service\ServiceName. If I install both features, all is well and the setup succeeds. But if I don't install ServiceB, the setup fails, because the SERVICEBPERMISSIONACCOUNT resolves to a principal which does not exist. So I need to put a condition on the PermissionEx tag. Unfortunately, the PermissionEx can only be put on a ServiceInstall element. What would be the correct way to solve this? I didn't find anything on Google about this. Kind regards, Henning -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition on service permissions
Ok, an immediate custom action would do the trick. Is there anything out-of-the-box that I missed? I'd really like to avoid custom actions if I can... Kind regards, Henning Krause -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Dienstag, 2. Juli 2013 17:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Condition on service permissions http://www.joyofsetup.com/2007/07/01/semi-custom-actions/ From: m...@henningkrause.eu To: wix-users@lists.sourceforge.net Date: Tue, 2 Jul 2013 13:32:26 + Subject: [WiX-users] Condition on service permissions Hi all, I have a setup which installs three services: ServiceA, ServiceB and ManagementService. ServiceA and ServiceB are in different features but have a dependency on ManagementService, which lives in its own feature. SerivceA and ServiceB should be able to start/stop the ManagementService. So I use this snippet to install the service: Component Id=ManagementService Guid=... File Source=PathToFile KeyPath=yes / ServiceInstall Account=LOCALSYSTEM Id=ManagementService DisplayName=ManagementService Name=ManagementService Start=demand Type=ownProcess Description=... PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=[SERVICEAPERMISSIONACCOUNT] ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / PermissionEx xmlns=http://schemas.microsoft.com/wix/UtilExtension; User=[SERVICEBPERMISSIONACCOUNT] ServiceQueryStatus=yes ServiceStart=yes ServiceStop=yes / /ServiceInstall ServiceControl Id=ManagementServiceControl Name=ManagementService Remove=uninstall Stop=both Wait=no / /Component Both services use service sids in the form NT Service\ServiceName. If I install both features, all is well and the setup succeeds. But if I don't install ServiceB, the setup fails, because the SERVICEBPERMISSIONACCOUNT resolves to a principal which does not exist. So I need to put a condition on the PermissionEx tag. Unfortunately, the PermissionEx can only be put on a ServiceInstall element. What would be the correct way to solve this? I didn't find anything on Google about this. Kind regards, Henning -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn mangaged installer and IIS Administration
Hi, using PowerShell you won't need admin permissions to enumerate this. In my installer I start a new process which hosts a PowerShell runspace. The new process is required because the Burn bootstrapper does not run as X64 process. However, this is required for the ServerManager snapin. The process just enumerates the features and writes them to stdout. This response is then collected by the bootstrapper. Kind regards, Henning Krause -Original Message- From: Igor Paniushkin [mailto:ipaniush...@sdl.com] Sent: Dienstag, 9. Oktober 2012 13:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn mangaged installer and IIS Administration It seems that I found another thing which has the same problem: DISM API (http://msdn.microsoft.com/en- us/library/windows/desktop/hh824790.aspx). It also requires elevated permissions (even to get info about installed windows features). Best Regards, Igor -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Friday, September 21, 2012 10:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn mangaged installer and IIS Administration 1. Today, yes. Fixing the engine to help would be interesting. Funny thing is that it is only IIS that seems to have this problem. 2. Not going to help fix the Burn engine with managed code, no. smile/ On Fri, Sep 21, 2012 at 11:07 AM, Henning Krause m...@henningkrause.euwrote: Hi Rob, You'd have to spin of a separate process that can elevate. We've talked about adding somethig like this to Burn for IIS because they made a huge API blunder and required read operations to be elevated. sigh/ But with an additional elevated process the use would have to go through the elevation process two times - once for the detection and once for the installation, or am I wrong? Of course, that thing hasn't been implemented yet. Maybe you'd like to contribute it? I only do managed development - so, I think this would be a problem, wouldn't it? Kind regards, Henning -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC - - Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn restart behavior
Hi,
I have created a managed bootstrapper using burn which installs one to three
MSIs. One of the packages might require a restart of the system.
What I now do is this:
private void ApplyComplete(object sender, ApplyCompleteEventArgs e)
{
// ..
if (e.Restart == ApplyRestart.RestartInitiated ||
e.Restart == ApplyRestart.RestartRequired)
{
IsRebootRequired = true;
e.Result = Result.Restart;
}
// ...
}
So, in the OnApplyComplete event I basically tell Burn to restart.
However, this is not very user friendly, as the user might want to delay the
restart.
One solution would be to pop up a message box asking the user whether he wants
to restart the computer now or later. But I find that this is not the optimal
solution.
Ideally, main window of the installer should just state that the installation
was successful but a restart is required. It would contain a checkbox, which
the user could check to indicate that he wants to restart the computer
immediately.
The problem is, that I can't tell burn to restart the computer. The only way I
know is the Result property in the OnApplyComplete handler. But that method is
long gone...
Is there another way to tell burn to restart the computer? Or do I have to
implement that on my own?
Kind regards,
Henning Krause
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn mangaged installer and IIS Administration
Hi, I'm working on an installer which creates a virtual directory in IIS. The installer has a managed bootstrapper application (Burn) and lets the user select the website to which install the virtual application to. For the selection process, I enumerate all installed websites on the local IIS using the Managed API for IIS. However, it seems that even reading the current IIS configuration required elevation. So it would seem the entire Bootstrapper has to be elevated, which has some smell IMHO. What is the best practice in this scenario? Kind regards, Henning Krause -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn mangaged installer and IIS Administration
Hi Rob, You'd have to spin of a separate process that can elevate. We've talked about adding somethig like this to Burn for IIS because they made a huge API blunder and required read operations to be elevated. sigh/ But with an additional elevated process the use would have to go through the elevation process two times - once for the detection and once for the installation, or am I wrong? Of course, that thing hasn't been implemented yet. Maybe you'd like to contribute it? I only do managed development - so, I think this would be a problem, wouldn't it? Kind regards, Henning -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn custom managed UI not starting
Hi,
0x80070002 means file not found. Make sure you have your file references in the
bundle correct. You can also use Sysinternals ProcMon to see where the bundle
tries to locate your bootstrapper.
Kind regards,
Henning
-Original Message-
From: Adkins, Christopher [mailto:christopher.adk...@docuware.com]
Sent: Donnerstag, 23. August 2012 13:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn custom managed UI not starting
Sorry, I forgot to mention that I also included that. I am not sure what else
I
can try and sadly I haven't found any information about that error number
either.
Best regards,
Christopher Adkins
Manager Research and Development
-Original Message-
From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com]
Sent: Donnerstag, 23. August 2012 12:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn custom managed UI not starting
Hi, I think you mabe need the following in your Assembly.cs
[assembly: BootstrapperApplication(typeof(Bootstrap))]
Kind regards,
Christoffel le Roux
Software Development Engineer
Finalist: 2011 Microsoft Customer Experience Partner of Year
www.flowcentric.com | Email: christoffe...@flowcentric.com| Mobile: +27
23733 752 | MSN: christoffler...@hotmail.com
FlowCentric UK/Europe
SoanePoint, 6-8 Market Place
Reading, Berkshire, RG1 2EG
Tel: +44(0) 1189 255 890
FlowCentric Africa/Asia
Fountain Square, 78 Kalkoen Street
Monument Park, 0181
Tel: +27 (0)12 347 4488
FlowCentric Australia/Pacific
Level 18, 333 Ann Street
Brisbane, Qld 4000
Tel: +61(0)7 3232 1277
This information is intended only for the person or entity to which it is
addressed and may contain private, confidential, proprietary and/or privileged
material and may be subject to confidentiality agreements. Any review,
retransmission, dissemination, or any other use of or taking of any action in
reliance upon this information, by persons or entities other than the intended
recipient, is prohibited. If you received this in error, please contact the
sender
and delete the material from all storage media. FlowCentric is neither liable
for
proper, complete transmission of the information contained in this
communication, any delay in its receipt or that the mail is virus-free.
-Original Message-
From: Adkins, Christopher [mailto:christopher.adk...@docuware.com]
Sent: Thursday, August 23, 2012 12:11 PM
To: General discussion for Windows Installer XML toolset. (wix-
us...@lists.sourceforge.net)
Subject: [WiX-users] Burn custom managed UI not starting
Hi everyone,
I am trying to get a custom burn UI working, but I can't even get it to
start. I
have looked at the WiXUX project as an example, but I am stuck on what I am
doing wrong. The log tells me:
[0428:0BC8][2012-08-23T12:04:17]: Burn v3.6.2928.0, Windows v6.1
(Build 7600: Service Pack 0), path:
C:\Users\Administrator\Desktop\WebSetup.exe, cmdline: '-burn.unelevated
BurnPipe.{6CBBF06B-E4A0-46FA-9AAA-7375658D17A8} {E0D4EE1A-96F0-
4E5C-B8FF-38EF4623E92D} 2064'
[0428:0BC8][2012-08-23T12:04:17]: Setting string variable 'WixBundleLog'
to value 'C:\Temp\WebSetup.Bootstrapper_20120823120417.log'
[0428:0BC8][2012-08-23T12:04:17]: Setting string variable
'WixBundleOriginalSource' to value
'C:\Users\Administrator\Desktop\WebSetup.exe'
[0428:0BC8][2012-08-23T12:04:18]: Setting string variable 'WixBundleName'
to value 'WebSetup.Bootstrapper'
[0428:0BC8][2012-08-23T12:04:18]: Loading managed bootstrapper
application.
[0428:0BC8][2012-08-23T12:04:18]: Error 0x80070002: Failed to create the
managed bootstrapper application.
[0428:0BC8][2012-08-23T12:04:18]: Error 0x80070002: Failed to create UX.
[0428:0BC8][2012-08-23T12:04:18]: Error 0x80070002: Failed to load UX.
[0428:0BC8][2012-08-23T12:04:18]: Error 0x80070002: Failed while running
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleAction = 4
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleElevated = 1
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleLog =
C:\Temp\WebSetup.Bootstrapper_20120823120417.log
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleName =
WebSetup.Bootstrapper
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleOriginalSource =
C:\Users\Administrator\Desktop\WebSetup.exe
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleProviderKey =
{a153399e-410b-41a3-aa5c-d6391841f7f7}
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleTag =
[0428:0BC8][2012-08-23T12:04:18]: Variable: WixBundleVersion = 1.0.0.0
[0428:0BC8][2012-08-23T12:04:18]: Error 0x80070002: Failed to run per-
user mode.
[0428:0BC8][2012-08-23T12:04:18]: Exit code: 0x80070002, restarting: No
The call to the bootstrapper looks like this:
BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost'
Payload Name='BootstrapperCore.config' SourceFile='C:\tfs
Re: [WiX-users] crc error on wix 3.7 aditional downloads
Seems to be a bug in PowerArchiver. I had the same issue and reverted to Windows Explorer to extract the files... Kind regards, Henning -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Mittwoch, 22. August 2012 06:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] crc error on wix 3.7 aditional downloads Hi: I've just tried downloading the first build of wix 3.7-3.7.8.21.0. The exe downloads fine but I'm getting crc errors on the additional downloads. I've tried with ie9 and firefox. I'm using power archiver 2012 as my unzipper-I don't think this should make a difference. Any help appreciated. Cheers Sean. -- 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 -- 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
Re: [WiX-users] [Burn] Start IIS Manager after installation
Hi Rob, thanks for that hint - it is indeed the correct solution. While I could work around the file redirection issue (x86/x64 issue), I couldn't start the ServerManager due to elevation problems. Now, from within my X64 proxy process I can use ShellExecute which allows elevation. Kind regards, Henning -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Sunday, August 12, 2012 11:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] [Burn] Start IIS Manager after installation I haven't played with this much but a workaround would be to carry a 64-bit executable in your BootstrapperApplication payloads and launch that on 64-bit Windows to launch IIS Manager. Essentially a 64-bit proxy. On Fri, Aug 10, 2012 at 4:15 AM, Henning Krause m...@henningkrause.euwrote: I have created a managed bootstrapper using burn. At the end of the installation I want to provide the user with the option to start the IIS manager. For that I have a link on my UI. Problem 1: If I just call Process.Start(@%windir%\system32\inetsrv\InetMgr.exe), it fails because it cannot find the file. Since the bootstrapper is running as an x86 program, the File redirection kicking in, rerouting the call to %windir%\syswow64\inetsrv\InetMgr.exe. Solution: Either call %windir%\sysnative\inetsrv\InetMgr.exe or use Wow64DisableWow64FsRedirection. Though this works, it raises problem 2. Problem 2: If I bypass the file redirection and call inetmgr.exe without using ShellExecute, the process fails stating that it requires elevation. I have also tried to start the process with ShellExecute or ShellExecute and the verb runas. Nothing has worked so far. Has anybody a solution for this? Kind regards, Henning Krause -- 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 -- virtually, Rob Mensching http://RobMensching.com LLC -- 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 -- 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
Re: [WiX-users] Burn: WixStdBA crashes wih Access violation
Hi Bob, thanks for the quick resolution of the issue. Kind regards, Henning -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, August 09, 2012 11:04 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation On 09-Aug-12 09:02, Henning Krause wrote: I have investigated the issue further and come to the conclusion that it happens during an upgrade of an existing installation. It tries to do something to the existing pacakage and looks up the package in the current bundle using its id. When it does not find it, it fails with the access violation. Upgrading was the key. This is now fixed for the next build. For posterity, here's the comment I added when I resolved the bug: At the end of an upgrade, the new bundle tells the old bundle to go away, like a post-InstallFinalize major upgrade. That's the GUID package id. The new bundle doesn't have a record of the old bundle id, so it blows up when it's not found. -- sig://boB http://joyofsetup.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 -- 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
[WiX-users] [Burn] Start IIS Manager after installation
I have created a managed bootstrapper using burn. At the end of the installation I want to provide the user with the option to start the IIS manager. For that I have a link on my UI. Problem 1: If I just call Process.Start(@%windir%\system32\inetsrv\InetMgr.exe), it fails because it cannot find the file. Since the bootstrapper is running as an x86 program, the File redirection kicking in, rerouting the call to %windir%\syswow64\inetsrv\InetMgr.exe. Solution: Either call %windir%\sysnative\inetsrv\InetMgr.exe or use Wow64DisableWow64FsRedirection. Though this works, it raises problem 2. Problem 2: If I bypass the file redirection and call inetmgr.exe without using ShellExecute, the process fails stating that it requires elevation. I have also tried to start the process with ShellExecute or ShellExecute and the verb runas. Nothing has worked so far. Has anybody a solution for this? Kind regards, Henning Krause -- 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
Re: [WiX-users] Burn: WixStdBA crashes wih Access violation
Hi Neil, Bob asked me to add my bundle authoring to it. As it's full of work stuff I had to mark it private. I have investigated the issue further and come to the conclusion that it happens during an upgrade of an existing installation. It tries to do something to the existing pacakage and looks up the package in the current bundle using its id. When it does not find it, it fails with the access violation. Kind regards, Henning -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Thursday, August 09, 2012 2:27 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation I want to supply some extra information on this defect as requested but it seems to have gone missing. Anyone know what has happened to it? Neil -Original Message- From: Henning Krause [mailto:m...@henningkrause.eu] Sent: 08 August 2012 5:49 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation Hi Bob, done: https://sourceforge.net/tracker/index.php?func=detailaid=3555380grou p_id=105970atid=642714 Kind regards, Henning -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, August 08, 2012 6:32 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation On 08-Aug-12 12:00, Henning Krause wrote: Unhandled exception at 0x0FF45EE6 (wixstdba.dll) Setup.exe: 0xC005: Access violation reading location 0x0018. Please file a bug so it doesn't get lost in e-mail. -- sig://boB http://joyofsetup.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 -- 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 -- 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 -- 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
[WiX-users] Burn: WixStdBA crashes wih Access violation
Hi,
I'm working with the latest WIX version (v3.6.3206.0).
Unhandled exception at 0x0FF45EE6 (wixstdba.dll) Setup.exe: 0xC005:
Access violation reading location 0x0018.
After downloading the symbols from Wixtoolset.org, Visual Studio pinpointed
the exception to WixStandardBootstrapperApplication.cpp, line 558:
virtual STDMETHODIMP_(int) OnExecutePackageBegin(
__in_z LPCWSTR wzPackageId,
__in BOOL fExecute
)
{
if (wzPackageId *wzPackageId)
{
BAL_INFO_PACKAGE* pPackage = NULL;
HRESULT hr = BalInfoFindPackageById(m_Bundle.packages,
wzPackageId, pPackage);
LPCWSTR wz = (SUCCEEDED(hr) pPackage-sczDisplayName) ?
pPackage-sczDisplayName : wzPackageId;
m_fShowingInternalUiThisPackage = pPackage-fDisplayInternalUI;
// Error occurs in this line
ThemeSetTextControl(m_pTheme,
WIXSTDBA_CONTROL_EXECUTE_PROGRESS_PACKAGE_TEXT, wz);
ThemeSetTextControl(m_pTheme,
WIXSTDBA_CONTROL_OVERALL_PROGRESS_PACKAGE_TEXT, wz);
}
else
{
m_fShowingInternalUiThisPackage = FALSE;
}
return __super::OnExecutePackageBegin(wzPackageId, fExecute);
}
When I try to peek into the members of pPackage, the debugger says Unable
to read memory. I can peek into other objects without problems.
The line in question was introduced in version v3.6.3130.0, and I guess it's
missing a guard condition. If hr is E_NOTFOUND, pPackage will be null and
the whole thing crashes.
Kind regards,
Henning
--
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
Re: [WiX-users] Burn: WixStdBA crashes wih Access violation
Hi Bob, done: https://sourceforge.net/tracker/index.php?func=detailaid=3555380group_id=105970atid=642714 Kind regards, Henning -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, August 08, 2012 6:32 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation On 08-Aug-12 12:00, Henning Krause wrote: Unhandled exception at 0x0FF45EE6 (wixstdba.dll) Setup.exe: 0xC005: Access violation reading location 0x0018. Please file a bug so it doesn't get lost in e-mail. -- sig://boB http://joyofsetup.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 -- 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
Re: [WiX-users] Burn: WixStdBA crashes wih Access violation
Hi Neil,
no, it happens rather in the middle of it...
Kind regards,
Henning
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Wednesday, August 08, 2012 7:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn: WixStdBA crashes wih Access violation
Does this crash happen at the end of the install? My users have reported a
problem when upgrading today and I updated the build to 3.6.3206 yesterday
and wonder if this is the same issue.
Neil
-Original Message-
From: Henning Krause [mailto:m...@henningkrause.eu]
Sent: 08 August 2012 17:00
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Burn: WixStdBA crashes wih Access violation
Hi,
I'm working with the latest WIX version (v3.6.3206.0).
Unhandled exception at 0x0FF45EE6 (wixstdba.dll) Setup.exe: 0xC005:
Access violation reading location 0x0018.
After downloading the symbols from Wixtoolset.org, Visual Studio
pinpointed the exception to WixStandardBootstrapperApplication.cpp, line
558:
virtual STDMETHODIMP_(int) OnExecutePackageBegin(
__in_z LPCWSTR wzPackageId,
__in BOOL fExecute
)
{
if (wzPackageId *wzPackageId)
{
BAL_INFO_PACKAGE* pPackage = NULL;
HRESULT hr = BalInfoFindPackageById(m_Bundle.packages,
wzPackageId, pPackage);
LPCWSTR wz = (SUCCEEDED(hr) pPackage-sczDisplayName) ?
pPackage-sczDisplayName : wzPackageId;
m_fShowingInternalUiThisPackage =
pPackage-fDisplayInternalUI; //
Error occurs in this line
ThemeSetTextControl(m_pTheme,
WIXSTDBA_CONTROL_EXECUTE_PROGRESS_PACKAGE_TEXT, wz);
ThemeSetTextControl(m_pTheme,
WIXSTDBA_CONTROL_OVERALL_PROGRESS_PACKAGE_TEXT, wz);
}
else
{
m_fShowingInternalUiThisPackage = FALSE;
}
return __super::OnExecutePackageBegin(wzPackageId, fExecute);
}
When I try to peek into the members of pPackage, the debugger says
Unable to read memory. I can peek into other objects without problems.
The line in question was introduced in version v3.6.3130.0, and I guess
it's
missing a guard condition. If hr is E_NOTFOUND, pPackage will be null and
the
whole thing crashes.
Kind regards,
Henning
--
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
--
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
--
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
[WiX-users] X64 Burn Bootstrapper
Hi, as part of my managed bundle, I may need to activate certain Windows Features. Since I'm targeting Windows 2008 R2 or later, I can safely use the Add-WindowsFeature and Get-WindowsFeature cmdlets. The Add-WindowsFeature would be called from a custom action. However, I want to display a list of missing features to the user during the UI part of the Setup. For this I call the Get-WindowsFeature cmdlet in my managed bootstrapper. However, this fails, because the custom Bootstrapper application always seems to be 32bit. Unfortunately, the ServerManager PowerShell module is only available as 64bit. I've already tried to compile the whole setup solution as 64, but no avail. Is this scenario simply not possible or am I missing something? Kind regards, Henning -- 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
Re: [WiX-users] X64 Burn Bootstrapper
Maybe my question was poorly phrased. I'm not running a custom action. My call to Get-WindowsFeature resides in a Managed Bootstrapper application (aka Burn). I haven't found a way to start the Bundle process as x64. Kind regards, Henning -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Wednesday, June 27, 2012 3:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] X64 Burn Bootstrapper You have to call with a 64-bit entry point. If you're using CAQuietExec, you need to be using CAQuietExec64 to execute in a 64-bit process. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Henning Krause [mailto:m...@henningkrause.eu] Sent: Wednesday, June 27, 2012 4:46 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] X64 Burn Bootstrapper Hi, as part of my managed bundle, I may need to activate certain Windows Features. Since I'm targeting Windows 2008 R2 or later, I can safely use the Add-WindowsFeature and Get-WindowsFeature cmdlets. The Add-WindowsFeature would be called from a custom action. However, I want to display a list of missing features to the user during the UI part of the Setup. For this I call the Get-WindowsFeature cmdlet in my managed bootstrapper. However, this fails, because the custom Bootstrapper application always seems to be 32bit. Unfortunately, the ServerManager PowerShell module is only available as 64bit. I've already tried to compile the whole setup solution as 64, but no avail. Is this scenario simply not possible or am I missing something? Kind regards, Henning -- 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 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. -- 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 -- 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
Re: [WiX-users] X64 Burn Bootstrapper
Since I'm in the context of Burn, I can't call CAQuietExec. I'm not running in any MSI context. That comes later... Henning -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Wednesday, June 27, 2012 3:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] X64 Burn Bootstrapper Hmmm. Generally, when I call applets I wrap them in C# or call them with CAQuietExec[64] because of this issue. The trick is that there are two powershell.exe's on a 64-bit system, and you get the 32-bit one by default. You're probably going to have to find a way to force the 64-bit powershell to be called or your context will be wrong. -- John M. Cooper -Original Message- From: Henning Krause [mailto:m...@henningkrause.eu] Sent: Wednesday, June 27, 2012 8:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] X64 Burn Bootstrapper Maybe my question was poorly phrased. I'm not running a custom action. My call to Get-WindowsFeature resides in a Managed Bootstrapper application (aka Burn). I haven't found a way to start the Bundle process as x64. Kind regards, Henning -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Wednesday, June 27, 2012 3:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] X64 Burn Bootstrapper You have to call with a 64-bit entry point. If you're using CAQuietExec, you need to be using CAQuietExec64 to execute in a 64-bit process. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Henning Krause [mailto:m...@henningkrause.eu] Sent: Wednesday, June 27, 2012 4:46 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] X64 Burn Bootstrapper Hi, as part of my managed bundle, I may need to activate certain Windows Features. Since I'm targeting Windows 2008 R2 or later, I can safely use the Add-WindowsFeature and Get-WindowsFeature cmdlets. The Add-WindowsFeature would be called from a custom action. However, I want to display a list of missing features to the user during the UI part of the Setup. For this I call the Get-WindowsFeature cmdlet in my managed bootstrapper. However, this fails, because the custom Bootstrapper application always seems to be 32bit. Unfortunately, the ServerManager PowerShell module is only available as 64bit. I've already tried to compile the whole setup solution as 64, but no avail. Is this scenario simply not possible or am I missing something? Kind regards, Henning -- 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 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. -- 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 -- 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
[WiX-users] Guidance needed on installing Windows features with Burn
Hi, I've created a managed bootstrapper application with burn which installs a web application packaged as an MSI. This works great so far. Now I need to ensure that certain server roles and features are installed. Since we target only Windows 2008 R2, I can use the ServerManager Cmdlets for this. Question: Where is the best place to put this stuff? I think I need to warn the administrator if certain server features are missing in the UI portion of the setup. Thus, I would extend my managed bootstrapper. But it would also be nice if I could add the required features on behalf of the administrator. Now, should I put this stuff in a custom action in my setup? Or should I do this right from the managed bootstrapper? Are there any other options I have missed? Kind regards, Henning Krause -- 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
Re: [WiX-users] WiX CustomBA Debuging
Just working on a managed bootstrapper myself...
Using
Debugger.Break()
I can successfully attach Visual Studio to the bootstrapper application. No
problem stepping through the code from there.
Kind regards,
Henning
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Thursday, June 14, 2012 4:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX CustomBA Debuging
1. No.
2. As long as the name of the .pdb file does not change, the debugger will
be able to find the .pdb if you put it in your symbol path. Try right
clicking on your BA .dll and there should be an option to modify the
debugging symbol paths. You can also find it in Tools - Options.
On Mon, Jun 11, 2012 at 9:30 AM, lily@us.7layers.com wrote:
Hi All,
I am using Burn for MSIs package. I am using Votive (Visual Studio) my
own custom BA instead of WiXBA. I tried to debug custom BA using
Debugger.Launch(). But when I start debugging, error messages occur.
No symbols are loaded for any call stack frame. The source code cannot
be displayed
I realized that package.exe links CustomBA dll which located at
C:\Documents and Settings\ user \Local Settings\Temp\{GUID}\. {GUID}
is always changed. So, whenever I run package.exe, always directory is
changed.
I think that is the reason to occur errors.
In Visual Studio, When I started package.exe with CustomBA dll which
located at absolute path (.../Debug/bin/CustomBA.dll). But after execute
the package.exe, it links to Local Settings\Temp\{GUID} directory. So,
when we start debugging and attached to CustomBA dll, CustomBA dll's
directory is dynamically changed and No symbols are loaded error
occurs.
1. Why package.exe links dll which located at C:\Documents and
Settings\user\Local Settings\Temp\{GUID}\? Can we choose the path for
dll statically?
2. If we can't choose the dll path statically, how can I use
debugging functions for CustomBA?
Please let me know.
Have a nice day.
This e-mail and any attachments are intended solely for the use of the
individual or entity to whom it is addressed. It may contain information
that is privileged, confidential and exempt, or protected from disclosure
under applicable law. If the reader of this message is not the intended
recipient or the employee or agent responsible for delivering it to the
intended recipient, you are hereby notified that any review, use,
disclosure, distribution, or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify
the sender immediately and destroy all copies and attachments. No
liability will be accepted for any damage caused by any virus transmitted
by this e-mail. Your assistance in maintaining the integrity of e-mail
communications is appreciated. Thank you.
--
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
--
virtually, Rob Mensching - http://RobMensching.com LLC
--
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
--
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
[WiX-users] Possible bug with Burn in perUser upgrade scenario?
Hi,
I've probably run into a bug with the latest WIX 3.6 build (see issue
https://sourceforge.net/tracker/?func=detailaid=3521939group_id=105970atid=642714)
on SourceForge.
Basically, I've an MSI which installs a file in a per-user scenario:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=* Name=Test Language=1033 Version=1.0.0.0
Manufacturer=Someone UpgradeCode=d7aea251-6b1e-4f16-80a5-67d2f1d524d3
Package InstallerVersion=200 Compressed=yes
InstallScope=perUser /
Property Id=ALLUSERS Secure=yes /
MajorUpgrade DowngradeErrorMessage=A newer version of
[ProductName] is already installed. /
MediaTemplate /
Feature Id=ProductFeature Title=Test Level=1
ComponentGroupRef Id=ProductComponents /
/Feature
/Product
Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=LocalAppDataFolder Name=AppData
Directory Id=AppRootDirectory Name=TestApp
/
/Directory
/Directory
/Fragment
Fragment
ComponentGroup Id=ProductComponents
Directory=AppRootDirectory
Component Id=ProductComponent
Guid=7AA2DC14-D353-474B-A0DB-C9430753668F
RemoveFolder Id=RemoveDir On=uninstall
Directory=AppRootDirectory /
RegistryKey Root=HKCU
Key=Software\TestApp
RegistryValue Type=string
Name=Description Value=[ProductName] KeyPath=yes /
/RegistryKey
File Source=Product.wxs /
/Component
/ComponentGroup
/Fragment
/Wix
Then, I have this bootstrapper:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Bundle Name=Bootstrapper1 Version=1.0.0.0 Manufacturer=Someone
UpgradeCode=2f3f318f-a5ef-41cf-96d3-31276b88691f
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.RtfLicense /
Chain
MsiPackage SourceFile=..\Test\bin\Debug\Test.msi /
/Chain
/Bundle
/Wix
When I run the bootstrapper, then increment the Bundle/@Version and the
Product/@Version attributes and run the bootstrapper again, the bootstrapper
offers the UI for new installations.
The Bootstrapper log reads as follows:
[1168:1008][2012-04-27T11:05:56]: Burn v3.6.2823.0, Windows v6.1 (Build 7601:
Service Pack 1), path: C:\temp\Test\Bootstrapper1\bin\Debug\Bootstrapper1.exe,
cmdline: ''
[1168:1008][2012-04-27T11:05:57]: Setting string variable 'WixBundleLog' to
value 'C:\Users\hkrause\AppData\Local\Temp\Bootstrapper1_20120427110557.log'
[1168:1008][2012-04-27T11:05:57]: Setting string variable
'WixBundleOriginalSource' to value
'C:\temp\Test\Bootstrapper1\bin\Debug\Bootstrapper1.exe'
[1168:1008][2012-04-27T11:05:57]: Setting string variable 'WixBundleName' to
value 'Bootstrapper1'
[1168:1008][2012-04-27T11:05:57]: Detect 1 packages
[1168:1008][2012-04-27T11:05:57]: Detected related bundle:
{49c5e601-b030-423b-a3b0-3bbacca35c84}, type: Upgrade, scope: PerUser, version:
1.0.0.0, operation: MajorUpgrade
[1168:1008][2012-04-27T11:05:57]: Detected related package:
{B581A39E-7BF2-48FE-B361-E10EB3C34356}, scope: PerUser, version: 1.0.0.0,
language: 0 operation: MajorUpgrade
[1168:1008][2012-04-27T11:05:57]: Detected package: Test.msi, state: Absent,
cached: None
[1168:1008][2012-04-27T11:05:57]: Detect complete, result: 0x0
So, it detects a previous version and says it would do an upgrade. But then,
the UI for a new installation appears. If I go with the installation, I end up
with two ARP entries.
Am I doing something wrong with my installer?
Kind regards,
Henning
--
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
Re: [WiX-users] Possible bug with Burn in perUser upgrade scenario?
Hi Rob,
yes, my fault. I was under the impression that there should be a custom UI for
upgrades.
Couldn't reproduce the issue with the duplicate ARP entry, so I closed the bug.
Kind regards,
Henning
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Friday, April 27, 2012 5:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Possible bug with Burn in perUser upgrade scenario?
The wixstdba does not show special UI for upgrade scenarios. It just shows
install (or an error message if it thinks it will downgrade what is on the
machine).
That said, it should remove the previous Bundle when installing the new
one. Can you share out more of the log? The part that shows the removal of
the old Bundle is later in the log. It looks like everything was detected
correctly.
On Fri, Apr 27, 2012 at 2:31 AM, Henning Krause
m...@henningkrause.euwrote:
Hi,
I've probably run into a bug with the latest WIX 3.6 build (see issue
https://sourceforge.net/tracker/?func=detailaid=3521939group_id=105970
atid=642714)
on SourceForge.
Basically, I've an MSI which installs a file in a per-user scenario:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=* Name=Test Language=1033 Version=1.0.0.0
Manufacturer=Someone UpgradeCode=d7aea251-6b1e-4f16-80a5-
67d2f1d524d3
Package InstallerVersion=200 Compressed=yes
InstallScope=perUser /
Property Id=ALLUSERS Secure=yes /
MajorUpgrade DowngradeErrorMessage=A newer version of
[ProductName] is already installed. /
MediaTemplate /
Feature Id=ProductFeature Title=Test Level=1
ComponentGroupRef Id=ProductComponents /
/Feature
/Product
Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=LocalAppDataFolder Name=AppData
Directory Id=AppRootDirectory
Name=TestApp /
/Directory
/Directory
/Fragment
Fragment
ComponentGroup Id=ProductComponents
Directory=AppRootDirectory
Component Id=ProductComponent
Guid=7AA2DC14-D353-474B-A0DB-C9430753668F
RemoveFolder Id=RemoveDir
On=uninstall Directory=AppRootDirectory /
RegistryKey Root=HKCU
Key=Software\TestApp
RegistryValue Type=string
Name=Description Value=[ProductName] KeyPath=yes /
/RegistryKey
File Source=Product.wxs /
/Component
/ComponentGroup
/Fragment
/Wix
Then, I have this bootstrapper:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Bundle Name=Bootstrapper1 Version=1.0.0.0
Manufacturer=Someone UpgradeCode=2f3f318f-a5ef-41cf-96d3-
31276b88691f
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.RtfLicense /
Chain
MsiPackage SourceFile=..\Test\bin\Debug\Test.msi
/
/Chain
/Bundle
/Wix
When I run the bootstrapper, then increment the Bundle/@Version and the
Product/@Version attributes and run the bootstrapper again, the
bootstrapper offers the UI for new installations.
The Bootstrapper log reads as follows:
[1168:1008][2012-04-27T11:05:56]: Burn v3.6.2823.0, Windows v6.1 (Build
7601: Service Pack 1), path:
C:\temp\Test\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: ''
[1168:1008][2012-04-27T11:05:57]: Setting string variable 'WixBundleLog'
to value
'C:\Users\hkrause\AppData\Local\Temp\Bootstrapper1_20120427110557.log'
[1168:1008][2012-04-27T11:05:57]: Setting string variable
'WixBundleOriginalSource' to value
'C:\temp\Test\Bootstrapper1\bin\Debug\Bootstrapper1.exe'
[1168:1008][2012-04-27T11:05:57]: Setting string variable 'WixBundleName'
to value 'Bootstrapper1'
[1168:1008][2012-04-27T11:05:57]: Detect 1 packages
[1168:1008][2012-04-27T11:05:57]: Detected related bundle:
{49c5e601-b030-423b-a3b0-3bbacca35c84}, type: Upgrade, scope: PerUser,
version: 1.0.0.0, operation: MajorUpgrade
[1168:1008][2012-04-27T11:05:57]: Detected related package:
{B581A39E-7BF2-48FE-B361-E10EB3C34356}, scope: PerUser, version: 1.0.0.0,
language: 0 operation: MajorUpgrade
[1168:1008][2012-04-27T11:05:57]: Detected package: Test.msi, state:
Absent, cached: None
[1168:1008][2012-04-27T11:05:57]: Detect complete, result: 0x0
So, it detects a previous version and says it would do an upgrade. But
then, the UI for a new installation appears. If I go with the installation,
I end up with two ARP entries.
Am I doing
[WiX-users] Get MSI logs when Burn chain failed
Hi, I have a burn chainer which installs an MSI. If the MSI fails (error 1603), I only get said error code in the burn log (msi failed with error 0x80070643). That's not very helpful because 1603 is kind of a standard error message. Is it possible to get a verbose MSI log from the package? Can the LogPathVariable property of the MsiPackage be used for this? Kind regards, Henning -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn Upgrade/Maintainance issues
Hi all, I've created a bootstrapper using burn which works rather well. One thing however: If I execute the bootstrapper multiple times, I always get the Install sequence. The install phase will then run, but since all chained products are already installed, the system is effectively not changed. However, I get a second entry in ARP. The log file contains this line: [1DF0:1958][2012-02-15T16:24:53]: Detected package: Outlook_addin__x86_, state: Present, cached: No There are no other products in the chain. This line occurs in the log before I hit the Install button. Shouldn't Burn realize that the product in question is already installed and thus change to the Modify appearance? Kind regards, Henning -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: Chain with MSI only packages fails with Directory not found error
I'm using WiX v3.6.2610.0
Test platform: Windows 2003 x86 en, latest service pack
I created a Burn Bootstrapper which installs one MSI as Per User. Depending
on the state of the target machine, some prereqs have to be installed
per-machine.
So I created this bootstrapper:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Bundle Name=Super product Version=1.0.0.0 Manufacturer=Someone
UpgradeCode=2F4ACE94-1117-4D3F-98E4-7DBA5EACC60E
Compressed=yes
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.HyperlinkLicense /
WixVariable Id=WixStdbaLogo Value=AppIcon.bmp /
WixVariable Id=WixStdbaLicenseUrl
Value=http://example.com/license.html; /
util:RegistrySearch Key=SOFTWARE\Microsoft\VSTO Runtime
Setup\v4R Value=VSTORFeature_CLR40 Win64=no Variable=VSTO2010Present
Root=HKLM/
Chain
ExePackage Name=VSTO 2010 x64
DetectCondition=VSTO2010Present=1 Compressed=no
InstallCommand=vstor40_x64.exe /q
DownloadUrl=http://download.microsoft.com/download/F/3/9/F395E3C2-28A0-4F0D-9E20-FF4D1ADB08D8/vstor40_x64.exe;
SourceFile=External Setups\vstor40_x64.exe
PerMachine=yes
UninstallCommand=vstor40_x64.exe /qu
Vital=yes Permanent=yes /
MsiPackage SourceFile=Installers\OutlookAddinX86.msi
Name=Outlook addin (x86) Cache=yes Compressed=yes /
/Chain
/Bundle
/Wix
Works like charm if the ExePackage needs to be installed as well. But if that
package is already installed, the setup fails:
[180C:1704][2012-02-15T09:58:18]: Burn v3.6.2610.0, path:
C:\Product\Development\UI\Build\Outlook Addin Setup\Bootstrapper.exe, cmdline:
''
[180C:1704][2012-02-15T09:58:18]: Setting string variable 'WixBundleLog' to
value
'C:\Users\Administrator\AppData\Local\Temp\Super_product_20120215095818.log'
[180C:1704][2012-02-15T09:58:18]: Setting string variable 'WixBundleName' to
value 'Super product'
[180C:1704][2012-02-15T09:58:18]: Setting string variable
'WixBundleOriginalSource' to value 'C:\Product\Development\UI\Build\Outlook
Addin Setup\Bootstrapper.exe'
[180C:1704][2012-02-15T09:58:19]: Detect 2 packages
[180C:1704][2012-02-15T09:58:19]: Setting string variable 'VSTO2010Present' to
value '1'
[180C:1704][2012-02-15T09:58:19]: Condition 'VSTO2010Present=1' evaluates to
true.
[180C:1704][2012-02-15T09:58:19]: Detected package: VSTO_2010_x64, state:
Present, cached: No
[180C:1704][2012-02-15T09:58:19]: Detected package: Outlook_addin__x86_, state:
Absent, cached: No
[180C:1704][2012-02-15T09:58:19]: Detect complete, result: 0x0
[180C:1704][2012-02-15T09:58:22]: Plan 2 packages, action: Install
[180C:1704][2012-02-15T09:58:22]: Skipping dependency registration on package
with no dependency providers: VSTO_2010_x64
[180C:1704][2012-02-15T09:58:22]: Planned package: VSTO_2010_x64, state:
Present, default requested: Present, ba requested: Present, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[180C:1704][2012-02-15T09:58:22]: Setting string variable
'WixBundleLog_Outlook_addin__x86_' to value
'C:\Users\Administrator\AppData\Local\Temp\Super_product_20120215095818_0_Outlook_addin__x86_.log'
[180C:1704][2012-02-15T09:58:22]: Setting string variable
'WixBundleRollbackLog_Outlook_addin__x86_' to value
'C:\Users\Administrator\AppData\Local\Temp\Super_product_20120215095818_0_Outlook_addin__x86__rollback.log'
[180C:1704][2012-02-15T09:58:22]: Planned package: Outlook_addin__x86_, state:
Absent, default requested: Present, ba requested: Present, execute: Install,
rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[180C:1704][2012-02-15T09:58:22]: Plan complete, result: 0x0
[180C:1704][2012-02-15T09:58:22]: Apply begin
[180C:1704][2012-02-15T09:58:22]: Caching bundle from:
'C:\Users\Administrator\AppData\Local\Temp\1\{db0b8631-45f6-43e8-9c45-4dbf76a5a05d}\.be\Bootstrapper.exe'
to: 'C:\Users\Administrator\AppData\Local\Package
Cache\{db0b8631-45f6-43e8-9c45-4dbf76a5a05d}\Bootstrapper.exe'
[180C:1704][2012-02-15T09:58:22]: Error 0x80070003: Failed to cache bundle
from:
'C:\Users\Administrator\AppData\Local\Temp\1\{db0b8631-45f6-43e8-9c45-4dbf76a5a05d}\.be\Bootstrapper.exe'
to 'C:\Users\Administrator\AppData\Local\Package
Cache\{db0b8631-45f6-43e8-9c45-4dbf76a5a05d}\Bootstrapper.exe'
[180C:1704][2012-02-15T09:58:22]: Error 0x80070003: Failed to cache bundle from
path:
C:\Users\Administrator\AppData\Local\Temp\1\{db0b8631-45f6-43e8-9c45-4dbf76a5a05d}\.be\Bootstrapper.exe
[180C:1704][2012-02-15T09:58:22]: Error 0x80070003: Failed to begin
registration session.
