[WiX-users] Burn: forceReboot and UI
Hello. Can I switch off install dialog after forceReboot? Every time after rebooting I have to set options in the Options dialog. And how to save the options between rebootings? It is possible? ExePackage Id=WindowsInstaller SourceFile=..\MsiProjects\SourceDir\Packages\WindowsXP-KB942288-v3-x86.exe Compressed=no Vital=no InstallCommand=/quiet /norestart PerMachine=yes Cache=no InstallCondition=Feature1 AND VersionMsi lt; v4.5.0.0 ExitCode Behavior=forceReboot / /ExePackage ExePackage Id=dotNetFx40 SourceFile=dotNetFx40_Full_x86_x64.exe InstallCommand=/quiet /norestart Compressed=no InstallCondition=(NOT DotNetFramework40FullInstallRegValue=1) AND Feature1 ExitCode Behavior=forceReboot / /ExePackage Thanks for your help, Sergey -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] help: Parameters are not passing to custom actions when push button clicked?
Only deferred custom actions use the CustomActionData class. Immeadiate
Custom Actions can access properties directly:
var installLocation = session[INSTALLLOCATION];
Here is what I consider `required` reading on the subject:
http://www.installsite.org/pages/en/isnews/200108/index.htm
From: k.koteswararao k...@metricasystems.com
Sent: Wednesday, March 28, 2012 11:58 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] help: Parameters are not passing to custom actions
when push button clicked?
Hi every one,
Aim trying to execute c# custom actions but problem is parameters are not
passing to code. Here my code
Binary Id=myAction SourceFile=MyCustomAction1.CA.dll /
CustomAction Id=SetCustomActionDataValue Return=check
Property=myActionId
Value=INSTALLLOCATION=[ProductName];AnotherValue='Just a value' /
CustomAction Id=myActionId BinaryKey=myAction
DllEntry=MySimpleAction
Return=ignore Execute=immediate /
InstallExecuteSequence
Custom Action=SetCustomActionDataValue Before=myActionId NOT
Installed/Custom
Custom Action=myActionId Before=InstallFinalizeNOT
Installed/Custom
/InstallExecuteSequence
Form UI iam calling the custom action code
Here the code
Control Id=btnCheckConnection Type=PushButton Height=17 Width=56
X=304 Y=213 Text=Test
Publish Event='DoAction' Value='myActionId' Order=1 1/Publish
/Control
My C#code
[CustomAction]
public static ActionResult MySimpleAction(Session session)
{
try
{
session.Message(InstallMessage.Warning,
new Record(new string[]
{
string.Format(INSTALLLOCATION{0},
session.CustomActionData[INSTALLLOCATION])
}));
session.Message(InstallMessage.Warning,
new Record(new string[]
{
string.Format(Another Value{0},
session.CustomActionData[AnotherValue])
}));
//MessageBox.Show(Pid);
}
catch (Exception exception)
{
session.Log(exception.ToString());
return ActionResult.Failure;
}
finally
{
}
return ActionResult.Success;
}
Any wrong that code?
Thanks
Pallapothu
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] upgrade didn't remove the earlier product from ARP
Using Wix 3.5, my initial MSI package (MyProduct v1.0) contained quite a few features, e.g. MS Word 95/XP/2003/2007/2010, MS Excel 95/XP/2003/2007/2010, MS PowerPoint 95/XP/2003/2007/2010. Their feature level was initially set to 0 but set to 1 if the specific app existed (using AppSearch). In other words, if MS Office 2003 was installed, only Word 2003, Excel 2003 and PowerPoint 2003 features had level=1, and the rest remained as 0. Recently I made the upgrade MSI package (MyProduct v2.0) using the same approach people said, such as, in How to implement WiX installer upgrade?http://stackoverflow.com/questions/114165/how-to-implement-wix-installer-upgrade And I scheduled *RemoveExistingProducts After=InstallValidate* in * InstallExecuteSequence*. Here is a fatal flaw in my installer: suppose the user had MS Office 2003 when he installed MyProduct v1.0. Now he upgraded MS Office to Office 2007 (therefore Office 2003 no longer exists), before he upgrades MyProduct to v2.0. My installer can't handle this. Why? I've tried to remove the old features (e.g. Word 2003, etc.) using the type 1 custom action by calling MsiSetFeatureState function. Although that function returned ERROR_SUCCESS, their states didn't get set to ABSENT but remained as NULL (I know the feature levels for Word 2003 etc. are 0 since they don't exist any more, and I believe that's why feature state unchanged), and I gave up eventually. (If you have any idea to make it work, please guide me to the light!!!) Anyway, my main question is not about the above bug. For now, I am more concerned about unable to remove the existing product, v1.0: Case1: upgrade without upgrading MS Office (works) When I tested the upgrade without upgrading MS Office, the upgrade works, and there is only one entry (MyProduct v2.0) in Add/Remove Program (aka ARP): the upgrade removed the earlier product entry from ARP. Case2: upgrade after upgrading MS Office (disaster) However, if I upgrade Office from Office 2003 to Office 2007 and then perform the MSI upgrade, not only Word 2003 feature / Word 2007 feature were installed, but also there are two entries (MyProduct v1.0 and MyProduct v2.0) in ARP. If I tried to uninstall v1.0 in ARP, it seemed to uninstall it, but if I refresh ARP, v1.0 re-appears, so I couldn't even uninstall v1.0. I compared the log files generated for both cases but it didn't tell me why. And I have no idea why. Can anyone help me? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix Burn LogoFile doesn't work on Windows XP
Hi, I create a burn exe and as long as I don't specify a LogoFile attribute for the bal:WixStandardBootstrapperApplication element I have no problems. But when I do add this attribute it works fine on Windows 7 but does not work on Windows XP. On XP the GUI does not even load. In the log I get: [07D8:081C][2012-03-29T12:16:16]: Error 0x8007000d: Failed to load theme controls. [07D8:081C][2012-03-29T12:16:16]: Error 0x80004005: Failed to create main window. [07D8:080C][2012-03-29T12:16:16]: Shutting down, exit code: 0x80004005 My XML is below. The only difference in the XML between the two cases is the LogoFile attribute. I also tried to use a Payload element for image as I seen a post by someone else using a custom theme but it didn't make a difference. Bundle Name=Dynagen Configurator Version=0.9.0.0 Manufacturer=Dynagen Technologies Inc. UpgradeCode=e5ce911c-cae5-43f8-b11e-878989f1fec5 IconSourceFile=$(var.ConfigExePath)\DynagenProgramIcon.ico HelpUrl=www.dynagen.ca Condition=NOT ( ((VersionNT=600) OR ((VersionNT=501) AND (ServicePackLevel=3))) AND (VersionMsi=301) ) BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense bal:WixStandardBootstrapperApplication LogoFile=$(var.ConfigExePath)\DynagenProgramIcon.ico LicenseUrl=http://www.dynagen.ca; SuppressOptionsUI=yes / !-- -- !--Payload SourceFile=$(var.ConfigExePath)\DynagenProgramIcon.ico/-- /BootstrapperApplicationRef Chain PackageGroupRef Id='Netfx4Full' / PackageGroupRef Id=VS2010_Cpp/ PackageGroupRef Id=Shell_Installer/ /Chain /Bundle A bug or am I doing something wrong? Wes Manning -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows service event source
So I have that in there, but the event items still show up as Service1 in the event log. On Wed, Mar 28, 2012 at 7:58 PM, John H Bergman (XPedient) john.berg...@xpdnt.com wrote: I use something like this: !-- Create the Event Log -- util:EventSource Name='My Service EventLog' Log='My Service Eventlog ' EventMessageFile='[NETFRAMEWORK40FULLINSTALLROOTDIR]\EventLogMessages.dll' SupportsErrors='yes' SupportsWarnings='yes' SupportsInformationals='yes'/ .Net 2.0 also has the same DLL. If you have a custom Eventlog dll, created using the mc compiler, you could substitute that dll here, it would have to be compiled with the native C/C++ compiler though. John -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Wednesday, March 28, 2012 7:57 PM To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Windows service event source Take a look at: http://wix.sourceforge.net/manual-wix3/util_xsd_eventsource.htm An event source in windows is really just some registry entries. The EventSource extension is some compiler synatical sugar that simlifies authoring this. Your Installer class isn't needed and shouldn't be used as it increases the fragility of your MSI. From: Chris Robison chrisdrobi...@gmail.commailto: chrisdrobi...@gmail.com Sent: Wednesday, March 28, 2012 6:00 PM To: wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net Subject: [WiX-users] Windows service event source I'm using the latest weekly build of Wix. The ServiceInstall feature doesn't create a properly named event source for the service. The event source for a service turns out to be Service1. The service installer built into .NET does it. Can anyone point me in the right direction? Thanks, Chris -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows service event source
You know what, I figured it out. That source doesn't have to do with installer at all. I just had to set the service name in code in the ServiceBase class for it to display correctly. Chris On Thu, Mar 29, 2012 at 9:30 AM, Chris Robison chrisdrobi...@gmail.comwrote: So I have that in there, but the event items still show up as Service1 in the event log. On Wed, Mar 28, 2012 at 7:58 PM, John H Bergman (XPedient) john.berg...@xpdnt.com wrote: I use something like this: !-- Create the Event Log -- util:EventSource Name='My Service EventLog' Log='My Service Eventlog ' EventMessageFile='[NETFRAMEWORK40FULLINSTALLROOTDIR]\EventLogMessages.dll' SupportsErrors='yes' SupportsWarnings='yes' SupportsInformationals='yes'/ .Net 2.0 also has the same DLL. If you have a custom Eventlog dll, created using the mc compiler, you could substitute that dll here, it would have to be compiled with the native C/C++ compiler though. John -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Wednesday, March 28, 2012 7:57 PM To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Windows service event source Take a look at: http://wix.sourceforge.net/manual-wix3/util_xsd_eventsource.htm An event source in windows is really just some registry entries. The EventSource extension is some compiler synatical sugar that simlifies authoring this. Your Installer class isn't needed and shouldn't be used as it increases the fragility of your MSI. From: Chris Robison chrisdrobi...@gmail.commailto: chrisdrobi...@gmail.com Sent: Wednesday, March 28, 2012 6:00 PM To: wix-users@lists.sourceforge.netmailto: wix-users@lists.sourceforge.net Subject: [WiX-users] Windows service event source I'm using the latest weekly build of Wix. The ServiceInstall feature doesn't create a properly named event source for the service. The event source for a service turns out to be Service1. The service installer built into .NET does it. Can anyone point me in the right direction? Thanks, Chris -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows service event source
The problem I ran into when the installer didn't create the event source was a permission one. If your service has the adequate permissions, the service class can create the eventlog, however, most of my services run at a considerable lower privilege, and so I have to rely on the installer to create it. John -Original Message- From: Chris Robison [mailto:chrisdrobi...@gmail.com] Sent: Thursday, March 29, 2012 10:56 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows service event source You know what, I figured it out. That source doesn't have to do with installer at all. I just had to set the service name in code in the ServiceBase class for it to display correctly. Chris On Thu, Mar 29, 2012 at 9:30 AM, Chris Robison chrisdrobi...@gmail.comwrote: So I have that in there, but the event items still show up as Service1 in the event log. On Wed, Mar 28, 2012 at 7:58 PM, John H Bergman (XPedient) john.berg...@xpdnt.com wrote: I use something like this: !-- Create the Event Log -- util:EventSource Name='My Service EventLog' Log='My Service Eventlog ' EventMessageFile='[NETFRAMEWORK40FULLINSTALLROOTDIR]\EventLogMessages.dll' SupportsErrors='yes' SupportsWarnings='yes' SupportsInformationals='yes'/ .Net 2.0 also has the same DLL. If you have a custom Eventlog dll, created using the mc compiler, you could substitute that dll here, it would have to be compiled with the native C/C++ compiler though. John -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Wednesday, March 28, 2012 7:57 PM To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Windows service event source Take a look at: http://wix.sourceforge.net/manual-wix3/util_xsd_eventsource.htm An event source in windows is really just some registry entries. The EventSource extension is some compiler synatical sugar that simlifies authoring this. Your Installer class isn't needed and shouldn't be used as it increases the fragility of your MSI. From: Chris Robison chrisdrobi...@gmail.commailto: chrisdrobi...@gmail.com Sent: Wednesday, March 28, 2012 6:00 PM To: wix-users@lists.sourceforge.netmailto: wix-users@lists.sourceforge.net Subject: [WiX-users] Windows service event source I'm using the latest weekly build of Wix. The ServiceInstall feature doesn't create a properly named event source for the service. The event source for a service turns out to be Service1. The service installer built into .NET does it. Can anyone point me in the right direction? Thanks, Chris - --- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:wix-us...@lists.sourceforge.ne t https://lists.sourceforge.net/lists/listinfo/wix-users - - This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:wix-us...@lists.sourceforge.ne t https://lists.sourceforge.net/lists/listinfo/wix-users - - This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
I've started playing with Microsoft's new hosted build service and I've come across some issues. The environment is locked down ( the builds don't run with administrative priv ) so you can't install software. While I understand WiX can xcopy deploy to a build envionment, I wanted to also leverage the MSBUILD ( .wixproj ) support because, well, that's kind of the whole design of TFS Team Build. So I grabbed the contents of the MSBuild Targets dirctory and the WiX directory and checked it into source control. Then I passed the following values into the build: /p:WiXTargetsPath=..\WiX\MSBuild\wix.targets;WixTasksPath=WiXTasks.dll;WixTo olPath=..\WiX\Application\bin;WixExtDir=..\WiX\Application\bin Everything almost worked except for ICE Validation. I was getting the usual suspect: light.exe: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I'm running the X86 msbuild platform. Does anyone have any suggestions on what could be done with user-privs only to fix this problem? Turning off validation is a horrible work around. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] RemoveExisitngProducts and deferred CA
Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveExisitngProducts and deferred CA
The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Theme
I started tinkering with this, and got something like this to work : BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense bal:WixStandardBootstrapperApplication LicenseFile=license.rtf LogoFile=mylogo.bmp SuppressOptionsUI=yes ThemeFile=mytheme.xml LocalizationFile=mytheme.wxl / Payload Name=myico.ico Compressed=yes SourceFile=application.ico/ /BootstrapperApplicationRef Some explanation below : 1. Some theme files can be found in the source under src\ext\BalExtension\wixstdba\Resources 2. I hacked up RtfTheme.[xml|wxl] to come up with my own Mytheme.* -- the schema is documented in the Wix 3.6 help file (as of build 2719 at least). 3. Myico.ico is used in my theme as a custom icon for the main window. Staring at WixStandardBootstrapperApplication.cpp and BalCompiler.cs helps, as does searching the source tree .. Parkes, Kevin wrote I'm exploring Burn and would like to try using my own theme with WixStandardBootstrapperApplication.Foundation. I'm probably being dense but I haven't managed to get anything working so far and the documentation isn't exactly extensive (yet). A few quick pointers as to how to get started would be much appreciated. Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Theme-tp7262316p7418931.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
Could it be authority to execute/registration of vbscript? I believe some of those validation tests still have vbs in them, and if it can't run, it's going to fail every time. -- 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: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, March 29, 2012 11:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers I've started playing with Microsoft's new hosted build service and I've come across some issues. The environment is locked down ( the builds don't run with administrative priv ) so you can't install software. While I understand WiX can xcopy deploy to a build envionment, I wanted to also leverage the MSBUILD ( .wixproj ) support because, well, that's kind of the whole design of TFS Team Build. So I grabbed the contents of the MSBuild Targets dirctory and the WiX directory and checked it into source control. Then I passed the following values into the build: /p:WiXTargetsPath=..\WiX\MSBuild\wix.targets;WixTasksPath=WiXTasks.dll;WixTo olPath=..\WiX\Application\bin;WixExtDir=..\WiX\Application\bin Everything almost worked except for ICE Validation. I was getting the usual suspect: light.exe: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I'm running the X86 msbuild platform. Does anyone have any suggestions on what could be done with user-privs only to fix this problem? Turning off validation is a horrible work around. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
I've done more research. I wrote a per-user install that didn't require admin and tried to install it by using an MSBuild Exec task. I got a 1601 error message saying the installer service was unavailable. I also ran sc query msiserver and it didn't say it was disabled. But clearly MSI is locked down in their build environment. From: John Cooper jocoo...@jackhenry.com Sent: Thursday, March 29, 2012 3:00 PM To: chr...@iswix.com chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Could it be authority to execute/registration of vbscript? I believe some of those validation tests still have vbs in them, and if it can't run, it's going to fail every time. -- 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: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, March 29, 2012 11:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers I've started playing with Microsoft's new hosted build service and I've come across some issues. The environment is locked down ( the builds don't run with administrative priv ) so you can't install software. While I understand WiX can xcopy deploy to a build envionment, I wanted to also leverage the MSBUILD ( .wixproj ) support because, well, that's kind of the whole design of TFS Team Build. So I grabbed the contents of the MSBuild Targets dirctory and the WiX directory and checked it into source control. Then I passed the following values into the build: /p:WiXTargetsPath=..\WiX\MSBuild\wix.targets;WixTasksPath=WiXTasks.dll;WixTo olPath=..\WiX\Application\bin;WixExtDir=..\WiX\Application\bin Everything almost worked except for ICE Validation. I was getting the usual suspect: light.exe: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I'm running the X86 msbuild platform. Does anyone have any suggestions on what could be done with user-privs only to fix this problem? Turning off validation is a horrible work around. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveExisitngProducts and deferred CA
Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Phil phil.wil...@invensys.comwrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Wix 3.6 Burn - Automatic Updates could not be paused
Wesley, yes, please attach your log to the bug. Did you author any
dependencies for any packages, including your ShellSetup.msi? Was this your
own MSI that you built, and not something that Microsoft Update would've
affected (i.e., upgraded, patched, etc.)? Or was this something from
Microsoft you rebundled that might've been affected?
On Wed, Mar 28, 2012 at 6:30 AM, Wesley Manning wmann...@dynagen.ca wrote:
Done. I can attach my burn package exe to the bug if you want. Let me
know if you need anything else
Wes
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: March-28-12 10:07 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix 3.6 Burn - Automatic Updates could not be
paused
Can you open a bug on the 0x8007002 error. There was an old issue about
that but if you're using the latest drops, it should be fixed there.
On Wed, Mar 28, 2012 at 5:44 AM, Wesley Manning wmann...@dynagen.ca
wrote:
I'm using v3.6.2726.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: March-28-12 12:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix 3.6 Burn - Automatic Updates could not be
paused
What version of the WiX toolset are you using?
On Tue, Mar 27, 2012 at 12:49 PM, Wesley Manning wmann...@dynagen.ca
wrote:
Hi,
It's a very old laptop. I ran windows update on it and it listed
100 updates. Note at this time my burn package (i.e. my program)
was still installed. I installed the 100 updates and rebooted the
computer. I tried uninstalling my program and it failed and this
was in
the log:
[0F24:0B64][2012-03-27T16:05:33]: Detect complete, result: 0x0
[0F24:0B64][2012-03-27T16:05:35]: Plan 3 packages, action: Uninstall
[0F24:0B64][2012-03-27T16:05:35]: Error 0x80070002: Failed
dependents check on package provider:
{A20ABBF9-534E-41A2-A7FE-7611EB47E7A1}
[0F24:0B64][2012-03-27T16:05:35]: Error 0x80070002: Failed to plan
dependency actions to unregister package: ShellSetup.msi
[0F24:0B64][2012-03-27T16:05:35]: Error 0x80070002: Failed to plan
execute package.
I then did a repair which was successful and after that I was able
to successfully uninstall my program. I installed my program again
and I no longer have the updates could not be paused error. But
any idea why I get the error that prevents my from uninstalling?
My burn package installs (in listed order):
(1) .net framework 4.0 (not cached)
(2) Visual 2010 C++ Redistributable Package (not cached)
(3) Shell Setup.msi (which is my program, this is cached)
When I ran Windows Update among the 100 updates were updates for the
.net framework 4.0 so this may be the reason for uninstall failure.
I went to another computer I had and checked for updates. There was
an update for Visual 2010 C++ Redistributable so I installed that
(before this I had already installed my program on this computer).
After I did and went to uninstall my program it gave me the same
error
as the other computer.
Exact same message in log as above. I had to do a repair and then
was able to uninstall my program successfully. So it seems any
changes to .net or redistributable will prevent uninstall.
Is this a known bug with burn? Or is there something I need to do
differently?
It also appears that when I do a repair the .net 4.0 framework is
downloaded (I guess since it is not cached). How does this affect
the updates/patches that get installed from windows update when burn
repairs the .net framework? Wouldn't the repair overwrite the new
updates?
Wes
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: March-26-12 8:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix 3.6 Burn - Automatic Updates could not
be paused
Yes, that is exactly what it is trying to do. Something is unhappy
with AU on that machine.
On Mon, Mar 26, 2012 at 2:30 PM, Wesley Manning
wmann...@dynagen.ca
wrote:
Hi,
I'm testing the burn (the
WixStandardBootstrapperApplication.HyperlinkLicense version)
installer I created on three computers two of which are Windows XP
with service
pack 3.
This error always appears in the burn log for one of them:
Automatic updates could not be paused due to error: 0x8024a000.
Continuing... .
This can cause the installer to hang for up to 6 minutes. It
only
occurs
on the same computer. This occurs just after Apply begin in the
log.
Does anybody know possible reasons why this is occurring and what
I can do about it, if anything? Is this a bug?
I assume it is attempting to pause Windows Update. Is this true?
Regards,
Wes Manning
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
ICE does not seem work correctly on a default, locked-down install of Windows Server 2008 R2 with AppLocker enabled. IIRC, an MSI policy that is locked down on Server also has to be enabled (it's been a while since I had to ge this working on my own machine). On Thu, Mar 29, 2012 at 1:21 PM, Christopher Painter chr...@iswix.comwrote: I've done more research. I wrote a per-user install that didn't require admin and tried to install it by using an MSBuild Exec task. I got a 1601 error message saying the installer service was unavailable. I also ran sc query msiserver and it didn't say it was disabled. But clearly MSI is locked down in their build environment. From: John Cooper jocoo...@jackhenry.com Sent: Thursday, March 29, 2012 3:00 PM To: chr...@iswix.com chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Could it be authority to execute/registration of vbscript? I believe some of those validation tests still have vbs in them, and if it can't run, it's going to fail every time. -- 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: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, March 29, 2012 11:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers I've started playing with Microsoft's new hosted build service and I've come across some issues. The environment is locked down ( the builds don't run with administrative priv ) so you can't install software. While I understand WiX can xcopy deploy to a build envionment, I wanted to also leverage the MSBUILD ( .wixproj ) support because, well, that's kind of the whole design of TFS Team Build. So I grabbed the contents of the MSBuild Targets dirctory and the WiX directory and checked it into source control. Then I passed the following values into the build: /p:WiXTargetsPath=..\WiX\MSBuild\wix.targets;WixTasksPath=WiXTasks.dll;WixTo olPath=..\WiX\Application\bin;WixExtDir=..\WiX\Application\bin Everything almost worked except for ICE Validation. I was getting the usual suspect: light.exe: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I'm running the X86 msbuild platform. Does anyone have any suggestions on what could be done with user-privs only to fix this problem? Turning off validation is a horrible work around. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveExisitngProducts and deferred CA
Did you keep the Component Guid stable? What does the log file say about the Component being installed and uninstalled? You want to focus on the Component state. On Thu, Mar 29, 2012 at 2:25 PM, Meera Jindal meera.jin...@gmail.comwrote: Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Phil phil.wil...@invensys.com wrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net
