Re: [WiX-users] Conditionally Including CustomActionRefs
I know that this is really old, but I don't see any reply to this, and I thought that I would respond so that, if nothing else, the archive will contain the answer. If you grab the source code and look at the WXS files for the extensions you will see that many of the custom actions have @Overridable="yes" set, which allows you to copy that element (without the Overridable attribute) into your authoring and alter things like the sequencing and the condition as you need without link errors. The VS2010InstallVSTemplates is one of those many custom actions that can be overridden that way. Blair -Original Message- From: Ian Williams [mailto:iawil...@microsoft.com] Sent: Monday, November 21, 2011 5:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Including CustomActionRefs Thank you for your reply. I do mean runtime. The CustomAction I'm including is from the WixVSExtension: VS2010InstallVSTemplates and the like. According to the documentation on this, it says that if you include the CustomActionRef, it will schedule everything for you (which I've observed is true). So I'm not sure how I can inject an extra condition into this. I don't have much experience with this area of wix. Ian -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Monday, November 21, 2011 4:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Including CustomActionRefs Do you mean buildtime? Check the preprocessor conditional statements: http://wix.sourceforge.net/manual-wix3/preprocessor.htm If you really mean runtime, when the package is getting installed, then you don't want to think of it as conditionally including a CustomActionRef. In this case you want to always include the CustomActionRef and use an appropriate condition in the schedule to determine whether it runs or not. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail > -Original Message- > From: Ian Williams [mailto:iawil...@microsoft.com] > Sent: Monday, November 21, 2011 4:17 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Conditionally Including CustomActionRefs > > I'm trying to conditionally include some CustomActionRef's based on a > property at runtime. I'm on WiX 3.6 beta right now. I can't figure out how to do this. > Does anyone know if this is possible? > > Thanks, > Ian > > -- > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] install file from subfolder
For the archives: Look at the "Specify source file locations" in the "Others" section of the "How To Guides" part of the CHM (or navigate there in the online manual). If those test.dll files are going into other directories than ones named subfolder1/subfolder2/etc then you will probably be looking at the Directory/@SourceName attribute. Blair -Original Message- From: Tomasz Grobelny [mailto:tom...@grobelny.oswiecenia.net] Sent: Monday, November 14, 2011 11:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] install file from subfolder Is it possible to install file that is located in subfolder of folder in which msi file is located? The installation media would look like this: rootfolder\ test.msi subfolder1\ test.dll subfolder2\ test.dll subfolder3\ test.dll Can this be done without manually specifying Media element for each subfolder? -- Regards, Tomasz Grobelny -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] BootstrapperApplication.DetectMsiFeature not fired
I'm using the WiX v3.6 Beta (v3.6.2221.0) here. This functionality has worked before, but now, the DetectMsiFeature event does not fire at all upon calling Engine.Detect(). Other related events, like DetectPackageComplete and DetectRelatedMsiPackage do fire. Is this a known problem? -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching and Pyro Warning PYRO1110
Further to my original question, I have been doing some testing. If find that: (1) if the patch contains a _new_ file that belongs to a feature that the is not installed on the user machine, then the patch effectively installs the feature (and uninstalling the patch does not remove the feature) along with the new file. (2) If the patch contains an _existing_ file update from a feature that is not installed, it has no effect (it doesn't install the file or alter the features installed on the machine). Can someone confirm this is what you would expect (and provide an explanation)? Thanks sanjay > -Original Message- > From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] > Sent: 05 February 2012 21:21 > To: 'General discussion for Windows Installer XML toolset.' > Subject: [WiX-users] Patching and Pyro Warning PYRO1110 > > I have created an MSI product installer for a product that has a main feature > (call it MF) and a sub feature (call it SF). It is mandatory to install the > main > feature but the sub feature is optional. > > I am experimenting with creating patches (small updates) using Wix 3.5 for > this product. I have a patch which adds a couple of new files to the > distribution. Using Pyro to generate the msp file using the diff.wixmst > between the two builds (the original and the one with added files), Pyro > gives me the waning: > > "Pyro.exe: warning PYRO1110 : Component 'XXX' was added to feature > . If you cannot guarantee this feature will always be installed, you > should consider adding new components to top-level features to prevent > prompts for source when installing this patch." > > I would have expected that if you initially installed the product without > feature SF, then you install the patch, that the relevant component 'XXX' > would not be installed (because you don't the feature that it belongs to). > Then if you ever modified the original installation to include feature SF > (with > the patch already installed), a new view of the product would be generated > that includes component XXX. It seems that this is not the case? Can anyone > explain how MSI works in this case? I have found this blog > (http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something- > you-didnt-build-with-wix-using-wix-.aspx ) where Peter Marcu says that you > should create a new top level feature (presumably that is always installed?) > in order to add these new files via a patch. Otherwise "Adding them to > existing features that are not always installed can leave you in some pretty > unfortunate situations". Can someone explain to me what these > "unfortunate situations" are? > > Also, If I have to create a new top level feature in the patch that always > installs the components, that would be pretty odd because I would have to > potentially install many redundant files (in the cases where the user never > installs the sub feature). Can I avoid this? > > Thanks in advance > sanjay -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BootstrapperApplication.DetectMsiFeature not fired
Just as an FYI, I now updated WiX to v3.6.2603.0, but the issue is still present. -Original Message- From: Alexander Krivács Schrøder [mailto:alexander.schro...@mermaid.no] Sent: 6. February 2012 12:44 To: wix-users@lists.sourceforge.net Subject: [WiX-users] BootstrapperApplication.DetectMsiFeature not fired I'm using the WiX v3.6 Beta (v3.6.2221.0) here. This functionality has worked before, but now, the DetectMsiFeature event does not fire at all upon calling Engine.Detect(). Other related events, like DetectPackageComplete and DetectRelatedMsiPackage do fire. Is this a known problem? -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] standard bootstapper and non-admin user
The message is
"0x8007051b - This security ID maynot be assigned as the owner of this object."
Here's the log:
[12B8:12F8][2012-02-06T14:21:24]: Burn v3.6.2527.0, path: C:\Users\Peter
Hull\Documents\in2it System Software\Setup.exe, cmdline: ''
[12B8:12F8][2012-02-06T14:21:25]: Setting string variable 'WixBundleLog' to
value
'C:\Users\PETERH~1\AppData\Local\Temp\in2it_System_Software_20120206142125.log'
[12B8:12F8][2012-02-06T14:21:25]: Setting string variable 'WixBundleName' to
value '...'
[12B8:12F8][2012-02-06T14:21:25]: Setting string variable
'WixBundleOriginalSource' to value 'C:\Users\Peter Hull\Documents\...\Setup.exe'
[12B8:12F8][2012-02-06T14:21:25]: Detect 2 packages
[12B8:12F8][2012-02-06T14:21:25]: Detected package: setup32.msi, state: Absent,
cached: No
[12B8:12F8][2012-02-06T14:21:25]: Detected package: setup64.msi, state: Absent,
cached: No
[12B8:12F8][2012-02-06T14:21:25]: Detect complete, result: 0x0
[12B8:12F8][2012-02-06T14:21:29]: Plan 2 packages, action: Install
[12B8:12F8][2012-02-06T14:21:29]: Condition 'Not VersionNT64' evaluates to
false.
[12B8:12F8][2012-02-06T14:21:29]: Planned package: setup32.msi, state: Absent,
default requested: Absent, ba requested: Absent, execute: None, rollback: None,
cache: No, uncache: No, dependency: None
[12B8:12F8][2012-02-06T14:21:29]: Condition 'VersionNT64' evaluates to true.
[12B8:12F8][2012-02-06T14:21:29]: Setting string variable
'WixBundleLog_setup64.msi' to value
'C:\Users\PETERH~1\AppData\Local\Temp\..._20120206142125_0_setup64.msi.log'
[12B8:12F8][2012-02-06T14:21:29]: Setting string variable
'WixBundleRollbackLog_setup64.msi' to value
'C:\Users\PETERH~1\AppData\Local\Temp\..._20120206142125_0_setup64.msi_rollback.log'
[12B8:12F8][2012-02-06T14:21:29]: Planned package: setup64.msi, state: Absent,
default requested: Present, ba requested: Present, execute: Install, rollback:
Uninstall, cache: Yes, uncache: No, dependency: Register
[12B8:12F8][2012-02-06T14:21:29]: Plan complete, result: 0x0
[12B8:12F8][2012-02-06T14:21:29]: Apply begin
[04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to secure cache
path: C:\ProgramData\Package Cache\
[04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to secure cache
directory: C:\ProgramData\Package Cache\
[04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to create completed
cache path for bundle.
[04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to cache bundle from
path:
C:\Users\PETERH~1\AppData\Local\Temp\{a477d6ef-5c9f-4330-9058-8bb42e84fa85}\.be\Setup.exe
[04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to begin
registration session.
[12B8:12F8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to begin
registration session in per-machine process.
[12B8:12F8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to register bundle.
[12B8:12F8][2012-02-06T14:21:35]: Apply complete, result: 0x8007051b restart: No
> From: peterhul...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Sat, 4 Feb 2012 09:36:09 +
> Subject: Re: [WiX-users] standard bootstapper and non-admin user
>
>
> I've got 2 MSIs, both with in their package element, and the bundle's wxs
> looks like this:
http://schemas.microsoft.com/wix/2006/wi";>
> I haven't got access to the system right now but it's windows 7 64-bit
> enterprise and the user is not an admin. The error message is something about
> not being able to use the token (I will write down exactly what on Monday)
> Pete
>
> > From: r...@robmensching.com
> > Date: Fri, 3 Feb 2012 23:18:28 -0800
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] standard bootstapper and non-admin user
> >
> > How did you mark that your MSIs are per-machine? The best thing to use is
> > the Package/@InstallScope attribute. Burn should automatically prompt for
> > elevation if it determines your MSIs are per-machine.
> >
> > On Fri, Feb 3, 2012 at 12:21 AM, Peter Hull wrote:
> >
> > >
> > > I've made an installer for 32- and 64-bit windows with separate MSIs,
> > > bundled with the standard BA
> > > (WixStandardBootstrapperApplication.RtfLicense). Both MSIs need admin
> > > privileges and are marked per-machine. If I run the installer as a
> > > non-admin user, the error message that the setup program gives is quite
> > > technical and (T believe) not all that helpful to the end user. Is there
> > > any way to make this message more friendly? In the MSI authoring I have
> > > been using something like Privileged.
> > > Is there an equivalent?
> > > Alternatively, would it make sense to mark the exe as
> > > requiresAdministrator in the manifest?
> > >
> > > Pete
> > >
> > >
> > >
> > > --
> > > Try before you buy = See our experts in action!
> > > The most comprehensive online learning library for Microsoft developers
> > > is just $99.99! Visual Studi
[WiX-users] 64-bit heat.exe
Hi, all. I'm encountering the problem ("*Could not harvest data from a
64bit dll*") detailed in this thread (
http://sourceforge.net/mailarchive/message.php?msg_id=27244946), which Rob
identified as a bug in heat.exe. I am wondering if
(A) anybody has been able to compile heat for the x64 target and
(B) if this fixes the bug.
I've tried building for 64b, and gotten some errors (see below). Before
either delving into this or trying to fix the bug, I was wondering if
anybody knows of any movement on this since the issue was first identified
last March.
Errors in 64b build:
[link]Creating library
C:\scm\external\wix\build\ship\x64\winterop.lib and object
C:\scm\external\wix\build\ship\x64\winterop.exp
[link] winterop.obj : error LNK2019: unresolved external symbol
CabCBegin referenced in function "long __cdecl CreateCabBegin(wchar_t const
*,wchar_t const *,unsigned long,unsigned long,unsigned long,enum
COMPRESSION_TYPE,void * *)" (?CreateCabBegin@
@YAJPEB_W0KKKW4COMPRESSION_TYPE@@PEAPEAX@Z)
[link] winterop.obj : error LNK2019: unresolved external symbol
CabCAddFile referenced in function "long __cdecl CreateCabAddFile(wchar_t
const *,wchar_t const *,struct _MSIFILEHASHINFO *,void *)"
(?CreateCabAddFile@@YAJPEB_W0PEAU_MSIFILEHASHINFO@@PEAX@Z)
... and several more like that.
Thanks,
Jerry
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Harvesting dll's referenced in a c# project in VS
To share my experience with harvesting: We had a very simple setup (no COM, no installutil automated setup, etc.). The projects producing built assemblies were responsible for staging all required files in such a way that we could use heat to harvest a directory into the setup. We didn't use project harvesting because it didn't harvest everything we wanted/needed to harvest. In this particular case, there were a number of files that were not part of the project proper but we included them as links so that we could have the project copy them into the output directory of the project. A developer accidentally removed these files from the project file causing the files to disappear from the MSI package. This was unfortunately not discovered until after release and became a huge embarrassment to our organization. This is a simple case of inadequate testing at both DEV and QA levels but had we not depended on harvesting (we no longer use automatic harvesting as part of our build process) we would have discovered the missing files at build time rather than much, much later. Using * to allow WiX to manage component GUIDs is so easy and robust now that whenever I hear somebody complain that they don't want to take the time to manage their component GUIDs I simply hear "I don't want to invest the time learning WiX, Windows Installer, nor what proper setup should look like on Windows platforms." Even heat can be told to use * rather than generating GUIDs which makes a great tool to generate WiX source initially. Heat can even post-process a file using XSLT to perform simple transformations. With nearly all development frameworks using XML to such a large degree I STILL find it confusing how so many people cannot work with XML, XPATH, nor XSLT. I *am* paid to produce quality software and that includes quality setup packages. I personally make it my mission to learn all the technology I use well enough to produce quality software. There is a time and place to use automation, code generation, and other software tools. In the case of Windows Installer packages, you rarely want to use automatic harvesting as part of your build process. Many of us share this advice multiple times a month out of our own experiences. We haven't failed to use it (we use it successfully) but have learned (more importantly) when _not_ to use it. Edwin G. Castro -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Sunday, February 05, 2012 1:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS Yes probably a bug but bottom line is VS deployment projects suck! It is more an issue with maintaining a reliable build or my installation project when moving the build between development and build machine, mainly it is related to COM references but I have also had issues with different versions of enterprise library. Also, its behaviour changes depending on whether the component is in the GAC for not often dev machines will have local references but build machines don't. I think I may not have explained what I do clearly. I do use harvesting but only at the start, I build all the source and write the output to a single folder or folder layout that matches the deployment. This picks up all the files and the references (as long as "Copy local" is set). I then run heat on that folder to generate a WiX source file. After that I maintain that file manually as I find it rarely changes but if it does I simply re-run the heat step. I find this keeps my install in a known state and if references are added I can validate them. For example, if someone adds a reference to v2 of a component and all other projects use v1 I need to validate whether the target system will support that or whether I need to deploy a new runtime install. Neil -Original Message- From: Michael Powell [mailto:mwpowel...@gmail.com] Sent: 04 February 2012 22:45 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS Yessir, which to me sounds like a bug. At least in our project, there are a MASSIVE number of assemblies with an equally MASSIVE number of references. There simply aren't enough hours in the day to maintain all that by hand over the long haul. On Sat, Feb 4, 2012 at 4:27 PM, Neil Sleightholm wrote: > Like you say each to his own but I have wasted a ridiculous amount of > time sorting out the mess Visual Studio deployment projects make of > auto harvesting. > > Neil > > -Original Message- > From: Michael Powell [mailto:mwpowel...@gmail.com] > Sent: 04 February 2012 20:10 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project > in VS > > Personally, each to his own I suppose. Professionally, I'm not being > paid to sit on top of my resource
Re: [WiX-users] WIX Example
A component in Windows Installer is the smallest "atom" available. It is immutable. In particular, the Windows Installer engine decides which resources to process based on which components are selected. When you place more than one physical resource in a component you lose the ability to patch/update/upgrade the files separately. For example, if the helper dll changes but the executable doesn't then any patches/updates/upgrades MUST change both the helper dll and the executable because the component as a whole is processed. Users are not allowed to select components directly. The setup developer is responsible for collecting components that must be installed together into features that are selectable by the user. Understanding the component rules and types of updates/upgrades is crucial to understanding the rationale for features and components in Windows Installer. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Phillip Wu [mailto:phillip...@lpi.nsw.gov.au] Sent: Sunday, February 05, 2012 4:11 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WIX Example I am reading the tutorial: http://wix.tramontana.co.hu/tutorial In the first example presented (samplefirst.wxs) there is an executeable, helper dll, pdf instruction manual. When the example is built it makes the executeable, icons, shortcuts one component. The helper dll is put into another component. Should not the executeable, icons, shortcuts and helper dll be in the same component as the executeable will not function without the dll? *** This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of the NSW Government. This email message has been swept by MIMEsweeper for the presence of computer viruses. *** Please consider the environment before printing this email. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Harvesting dll's referenced in a c# project in VS
Using Guid="*" does make things much simpler and I have started using this layout to simplify even further: This means there is only one entry for each file so it makes it even simpler for non-WiX developers to add/remove files i.e. no need to edit Directory and ComponentGroup fragments. WiX 3.6 simplifies this even further by allowing you to set ComponentGroup/@Directory. Unfortunately heat doesn't generate this but the format is so simple I just use a macro in my text editor to create it. Neil -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: 06 February 2012 16:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS To share my experience with harvesting: We had a very simple setup (no COM, no installutil automated setup, etc.). The projects producing built assemblies were responsible for staging all required files in such a way that we could use heat to harvest a directory into the setup. We didn't use project harvesting because it didn't harvest everything we wanted/needed to harvest. In this particular case, there were a number of files that were not part of the project proper but we included them as links so that we could have the project copy them into the output directory of the project. A developer accidentally removed these files from the project file causing the files to disappear from the MSI package. This was unfortunately not discovered until after release and became a huge embarrassment to our organization. This is a simple case of inadequate testing at both DEV and QA levels but had we not depended on harvesting (we no longer use automatic harvesting as part of our build process) we would have discovered the missing files at build time rather than much, much later. Using * to allow WiX to manage component GUIDs is so easy and robust now that whenever I hear somebody complain that they don't want to take the time to manage their component GUIDs I simply hear "I don't want to invest the time learning WiX, Windows Installer, nor what proper setup should look like on Windows platforms." Even heat can be told to use * rather than generating GUIDs which makes a great tool to generate WiX source initially. Heat can even post-process a file using XSLT to perform simple transformations. With nearly all development frameworks using XML to such a large degree I STILL find it confusing how so many people cannot work with XML, XPATH, nor XSLT. I *am* paid to produce quality software and that includes quality setup packages. I personally make it my mission to learn all the technology I use well enough to produce quality software. There is a time and place to use automation, code generation, and other software tools. In the case of Windows Installer packages, you rarely want to use automatic harvesting as part of your build process. Many of us share this advice multiple times a month out of our own experiences. We haven't failed to use it (we use it successfully) but have learned (more importantly) when _not_ to use it. Edwin G. Castro -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Sunday, February 05, 2012 1:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS Yes probably a bug but bottom line is VS deployment projects suck! It is more an issue with maintaining a reliable build or my installation project when moving the build between development and build machine, mainly it is related to COM references but I have also had issues with different versions of enterprise library. Also, its behaviour changes depending on whether the component is in the GAC for not often dev machines will have local references but build machines don't. I think I may not have explained what I do clearly. I do use harvesting but only at the start, I build all the source and write the output to a single folder or folder layout that matches the deployment. This picks up all the files and the references (as long as "Copy local" is set). I then run heat on that folder to generate a WiX source file. After that I maintain that file manually as I find it rarely changes but if it does I simply re-run the heat step. I find this keeps my install in a known state and if references are added I can validate them. For example, if someone adds a reference to v2 of a component and all other projects use v1 I need to validate whether the target system will support that or whether I need to deploy a new runtime install. Neil -Original Message- From: Michael Powell [mailto:mwpowel...@gmail.com] Sent: 04 February 2012 22:45 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS Yessir, which to me sounds like
[WiX-users] creating a patch using results in pyro error 0103
Hi there, I have a problem when I try to create a patch using torch and pyro. What I did until now: I saved the wixpdb files from the initial installer becaus I read it was recommended to do so. Well, I did... I created a new installer.msi with some changed files along with all other files packaged in the initial msi I executed torch with the following command line: torch -p -t patch -xi previous\installer.wixpdb current\installer\wixpdb -out current\patch.wixmst No errors occurred... I created a patch.wxs where I defined the componentref which has changed files and compiled and linked it. Also no errors... Than I run pyro with the command line: pyro current\patch.wixmsp -out installer_pl1.msp -t IdentifierFromPatchWXS current\patch.wixmst Executing this line causes pyro to complain about missing files. The file names printed out are pointing to the files used to create the initial installer.msi. this files are not available. So I am a newbie using pyro and I guess I am missing something to tell pyro to just use the files in the current\source folder. Or will pyro try to compare the current and the previous file to determine which files have changed? Isn't it the job of torch to check what has changed in the msi files? Can someone give me some pointers in how to tell pyro which files to package in the patch? Thanks in advance Regards, Michel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] standard bootstapper and non-admin user
Never mind it is due to the way our policies are set up.Thanks,Pete
> From: peterhul...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 6 Feb 2012 14:28:03 +
> Subject: Re: [WiX-users] standard bootstapper and non-admin user
>
>
> The message is
> "0x8007051b - This security ID maynot be assigned as the owner of this
> object."
> Here's the log:
> [12B8:12F8][2012-02-06T14:21:24]: Burn v3.6.2527.0, path: C:\Users\Peter
> Hull\Documents\in2it System Software\Setup.exe, cmdline: ''
> [12B8:12F8][2012-02-06T14:21:25]: Setting string variable 'WixBundleLog' to
> value
> 'C:\Users\PETERH~1\AppData\Local\Temp\in2it_System_Software_20120206142125.log'
> [12B8:12F8][2012-02-06T14:21:25]: Setting string variable 'WixBundleName' to
> value '...'
> [12B8:12F8][2012-02-06T14:21:25]: Setting string variable
> 'WixBundleOriginalSource' to value 'C:\Users\Peter
> Hull\Documents\...\Setup.exe'
> [12B8:12F8][2012-02-06T14:21:25]: Detect 2 packages
> [12B8:12F8][2012-02-06T14:21:25]: Detected package: setup32.msi, state:
> Absent, cached: No
> [12B8:12F8][2012-02-06T14:21:25]: Detected package: setup64.msi, state:
> Absent, cached: No
> [12B8:12F8][2012-02-06T14:21:25]: Detect complete, result: 0x0
> [12B8:12F8][2012-02-06T14:21:29]: Plan 2 packages, action: Install
> [12B8:12F8][2012-02-06T14:21:29]: Condition 'Not VersionNT64' evaluates to
> false.
> [12B8:12F8][2012-02-06T14:21:29]: Planned package: setup32.msi, state:
> Absent, default requested: Absent, ba requested: Absent, execute: None,
> rollback: None, cache: No, uncache: No, dependency: None
> [12B8:12F8][2012-02-06T14:21:29]: Condition 'VersionNT64' evaluates to true.
> [12B8:12F8][2012-02-06T14:21:29]: Setting string variable
> 'WixBundleLog_setup64.msi' to value
> 'C:\Users\PETERH~1\AppData\Local\Temp\..._20120206142125_0_setup64.msi.log'
> [12B8:12F8][2012-02-06T14:21:29]: Setting string variable
> 'WixBundleRollbackLog_setup64.msi' to value
> 'C:\Users\PETERH~1\AppData\Local\Temp\..._20120206142125_0_setup64.msi_rollback.log'
> [12B8:12F8][2012-02-06T14:21:29]: Planned package: setup64.msi, state:
> Absent, default requested: Present, ba requested: Present, execute: Install,
> rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
> [12B8:12F8][2012-02-06T14:21:29]: Plan complete, result: 0x0
> [12B8:12F8][2012-02-06T14:21:29]: Apply begin
> [04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to secure cache
> path: C:\ProgramData\Package Cache\
> [04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to secure cache
> directory: C:\ProgramData\Package Cache\
> [04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to create
> completed cache path for bundle.
> [04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to cache bundle
> from path:
> C:\Users\PETERH~1\AppData\Local\Temp\{a477d6ef-5c9f-4330-9058-8bb42e84fa85}\.be\Setup.exe
> [04D4:0DC8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to begin
> registration session.
> [12B8:12F8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to begin
> registration session in per-machine process.
> [12B8:12F8][2012-02-06T14:21:35]: Error 0x8007051b: Failed to register bundle.
> [12B8:12F8][2012-02-06T14:21:35]: Apply complete, result: 0x8007051b restart:
> No
>
>
>
> > From: peterhul...@hotmail.com
> > To: wix-users@lists.sourceforge.net
> > Date: Sat, 4 Feb 2012 09:36:09 +
> > Subject: Re: [WiX-users] standard bootstapper and non-admin user
> >
> >
> > I've got 2 MSIs, both with in their package element, and the bundle's wxs
> > looks like this:
>
> http://schemas.microsoft.com/wix/2006/wi";>
>
> Id="WixStandardBootstrapperApplicat\ion.RtfLicense" />
>
>
>
> InstallCondition="Not VersionNT64" />
> InstallCondition="VersionNT64" />
>
>
>
> > I haven't got access to the system right now but it's windows 7 64-bit
> > enterprise and the user is not an admin. The error message is something
> > about not being able to use the token (I will write down exactly what on
> > Monday)
> > Pete
> >
> > > From: r...@robmensching.com
> > > Date: Fri, 3 Feb 2012 23:18:28 -0800
> > > To: wix-users@lists.sourceforge.net
> > > Subject: Re: [WiX-users] standard bootstapper and non-admin user
> > >
> > > How did you mark that your MSIs are per-machine? The best thing to use is
> > > the Package/@InstallScope attribute. Burn should automatically prompt for
> > > elevation if it determines your MSIs are per-machine.
> > >
> > > On Fri, Feb 3, 2012 at 12:21 AM, Peter Hull
> > > wrote:
> > >
> > > >
> > > > I've made an installer for 32- and 64-bit windows with separate MSIs,
> > > > bundled with the standard BA
> > > > (WixStandardBootstrapperApplication.RtfLicense). Both MSIs need admin
> > > > privileges and are marked per-machine. If I run the installer as a
> > > > non-admin user, the error message that the setup program gives is quite
> > > > technical an
[WiX-users] Difference between Light.exe command lines generated from MSBuild switches
Hello! I'm seeing a different in the output Light.exe command lines when I msbuild and various combinations of switches, specifically /target. I tracked down the issue to a wixlib that doesn't get included on the light command line. When building from Visual Studio or the following command lines, the install compiles (workaround is to clean then build): * Visual Studio -> Build * Visual Studio -> Rebuild * msbuild c:\tfs\development\release\WixInstalls.sln /t:build /p:Configuration=release /p:Version=$version * msbuild c:\tfs\development\release\WixInstalls.sln /p:Configuration=release /p:Version=$version * msbuild c:\tfs\development\release\WixInstalls.sln /p:Configuration=release * msbuild c:\tfs\development\release\WixInstalls.sln /p:Version=$version When building this way, the install fails to compile. * msbuild c:\tfs\development\release\WixInstalls.sln /t:rebuild /p:Configuration=release * msbuild c:\tfs\development\release\WixInstalls.sln /t:rebuild /p:Version=$version * msbuild c:\tfs\development\release\WixInstalls.sln /t:rebuild Here are the errors I recieve: c:\tfs\development\release\FrontEnd\Product.wxs(52):error LGHT0094: Unresolved reference to symbol 'Property:WixCommon' in section'Product:*'. [c:\tfs\development\release\FrontEnd\FrontEnd.wixproj] c:\tfs\development\release\FrontEnd\Product.wxs(61): error LGHT0094: Unresolved reference to symbol 'Component:StartFolder' in section 'Product:*'. [c:\tfs\development\irelease\FrontEnd\FrontEnd.wixproj] c:\tfs\development\release\FrontEnd\Product.wxs(67): error LGHT0094: Unresolved reference to symbol 'WixUI:IR_UI_PERSISTENT' in section 'Product:*'. [c:\tfs\development\release\FrontEnd\FrontEnd.wixproj] Here is how it looks from Visual Studio's build command. I broke everything out on its own line just to make it clearer. C:\Program Files (x86)\Windows Installer XML v3.6\bin\Light.exe -out C:\Development\Release\FrontEnd\bin\Release\FrontEnd.msi -pdbout C:\Development\Release\FrontEnd\bin\Release\FrontEnd.wixpdb -cultures:en-US -ext "C:\Program Files (x86)\Windows Installer XML v3.6\bin\\WixUtilExtension.dll" -ext "C:\Program Files (x86)\Windows Installer XML v3.6\bin\\WixUIExtension.dll" -contentsfile obj\Release\FrontEnd.wixproj.BindContentsFileList.txt -outputsfile obj\Release\FrontEnd.wixproj.BindOutputsFileList.txt -builtoutputsfile obj\Release\FrontEnd.wixproj.BindBuiltOutputsFileList.txt obj\Release\BackupFiles.wixobj obj\Release\Files.wixobj obj\Release\InstallLocationProperties.wixobj obj\Release\Product.wixobj obj\Release\SymbolLinkCreation.wixobj C:\Development\Release\Wix\CommonInstallTools\CommonInstallTools\bin\Release\CommonInstallTools.wixlib <-- Missing from /t:rebuild The order from msbuild is a bit different, but -cotnentsfile, -outputsfile, and builtoutputsfile are missing, and most importantly the wixlib at the end (CommonInstallTools.wixlib) is always missing when using /t:rebuild. The strange thing is, there are two other projects in this solution that build MSIs successfully. Each of those projects requires this wixlib and they get compiled before the project that fails. Note: this project has been building successfully for almost year using the /t:rebuild switch. I added some custom action dlls and some .wxs files. -Derrick -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Included reference pulls in WixUI_Advanced
Hello! I managed to ignore the welcome screen, but in some cases, I need the InstallDirDlg dialog to show up. So I put in these lines: [Show Dialog="InstallDirDlg" After="WelcomeDlg"]UPGRADING_OLDER_PRODUCT AND NOT INSTALL_LOCATION_FOUND[/Show] This gives me these errors (I do not have a drive E:, BTW). E:\delivery\Dev\wix36_public\src\ext\UIExtension\wixlib\WixUI_Advanced.wxs(38,0): error LGHT0094: Unresolved reference to symbol 'Property:ApplicationFolderName' in section 'Fragment:'. E:\delivery\Dev\wix36_public\src\ext\UIExtension\wixlib\InstallScopeDlg.wxs(23,0): error LGHT0094: Unresolved reference to symbol 'Property:WixAppFolder' in section 'Fragment:'. With a little trial and error, I figured out that including WelcomeDlg in the After causes this error. This sequence works. [Show Dialog="InstallDirDlg" Before="ProgressDlg"]UPGRADING_OLDER_PRODUCT AND NOT INSTALL_LOCATION_FOUND[/Show] [Show Dialog="WelcomeDlg" Before="InstallDirDlg"](NOT Installed OR PATCH) AND (NOT UPGRADING_OLDER_PRODUCT)[/Show] Can anyone explain what is going on here? I figure it has something to do with the way properties include entire files when referenced, but I don't get this one because WelcomeDlg is used all over the place in my project. I'm interested in what process WiX is going thru to that would cause this. -Derrick -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MSP, whole features getting reinstalled
I'm creating my first MSPs. It appears that if a single component changes then all other components in the same Feature are reinstalled/repaired when the patch is applied. Is that correct behavior? Backstory: I have some components that install Services. These components do not change in the new version and the MSP doesn't transform them (I checked in Orca). It appears that since other components in the same feature are changed then the Services are getting reinstalled. This causes the Services' user-customized settings to be lost. The MSP replaces a single DLL and adds a bunch of fileVersion rows to the MsiAssemblyName table. The fileVersion rows seem to be the culprit causing the Services to get reinstalled. If anyone knows, let me know if this is normal behavior or if it sounds like I'm doing something wrong. Thanks! - John Burak -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSP-whole-features-getting-reinstalled-tp7260485p7260485.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry setting with configurable install directory -- problem with value of %SystemRoot%
Try setting the RegistrySearch/@Type attribute to "directory" instead of "raw". -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry-setting-with-configurable-install-directory-problem-with-value-of-SystemRoot-tp7255442p7260751.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] install file from subfolder
Hi. I'm having problems with pyro. I get this error: (note the weird Patch.msp in the temp directory showing twice?!) Copyright (C) Microsoft Corporation. All rights reserved. Updating file information. Creating cabinet files. There will be '4' threads used to produce CAB files. Creating cabinet 'C:\Windows\TEMP\prkmnyfn\#RTM.cab'. Generating database. C:\Windows\TEMP\prkmnyfn\Patch.msp : error PYRO0103 : The system cannot find the file 'C:\Windows\TEMP\prkmnyfn\Patch.msp'. 2012-02-06 18:29:56,371 [3] ERROR ProductPatchBuilder - ExecuteCommand: Microsoft (R) Windows Installer Xml Patch Builder version 3.5.2403.0 Copyright (C) Microsoft Corporation. All rights reserved. Updating file information. Creating cabinet files. There will be '4' threads used to produce CAB files. Creating cabinet 'C:\Windows\TEMP\prkmnyfn\#RTM.cab'. Generating database. C:\Windows\TEMP\prkmnyfn\Patch.msp : error PYRO0103 : The system cannot find the file 'C:\Windows\TEMP\prkmnyfn\Patch.msp'. The command I run is: pyro.exe "Temp\Patch.wixmsp" -out "Temp\Patch.msp" -t RTM "Temp\diff.wixmst" -v the diff.wixmst was create by torch, the 2 wixpdb files I used are EXACTLLY the same except for the wixFile table that has different paths to the newer and older files. (I find replace the path to reflect the location of the files since the MSI is generated in a directory I can't run the torch nor the pyro from). Thanks! -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
