Non-versioned files are typically updated based on the file hash, If the hash of the installed file is not the same as the hash of the incoming file then the installed file will be updated. There's no need to do your own patch mechanism with null component IDs.
http://msdn.microsoft.com/en-us/library/aa370532(v=vs.85).aspx Phil Wilson On Tue, Jan 14, 2014 at 11:53 AM, Laurene Koman <[email protected]> wrote: > More information on the issue we're trying to solve: > > > We need the ability to patch non versioned files /delete them if > necessary, etc. (in an MSP) We have found information indicating that > removing the ComponentID in the MSI will cause the Windows Installer to > treat these components as User Data. We've created a custom action to run > at maintenance which deletes the folder where these user data files were > installed. (The setup.msi has the ComponentIDs removed) > > next step, we want to add an MSM at MSP time to install these updated > files, add files or drop files. These files also have no ComponentID. > When applying this patch, the CA works and the files/folders are removed, > however the MSP does not add the files. > > The log indicates that the Components in question are > > Installed: Null > Request: Null > Action: Null > > Is there any solution to the problem (or another approach?) > > > ________________________________________ > From: Mita Patel [[email protected]] > Sent: Monday, January 13, 2014 10:09 PM > To: [email protected] > Subject: [WiX-users] Deleting files in a patch > > The msdn doc says the following for component id in the column table. > ComponentId --> If this column is null the installer does not register the > component and the component cannot be removed or repaired by the installer. > This might be intentionally done if the component is only needed during the > installation, such as a custom action that cleans up temporary files or > removes an old product. It may also be useful when copying data files to a > user's computer that do not need to be registered. > > Does this mean in the full msi, components with null id will not be > registered and if deleted then will not put the msi in repair? Which > further indicates that at patch time we can call a custom action to delete > these components , and this will not throw the msi in repair mode? > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] > Sent: Monday, January 13, 2014 9:13 AM > To: [email protected] > Subject: WiX-users Digest, Vol 92, Issue 20 > > Send WiX-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/wix-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of WiX-users digest..." > > > Today's Topics: > > 1. Installing framework 4.0 update (Goran Malovic) > 2. Re: Buindle Major Upgrade cause first msi uninstallation > (Tim Comport) > 3. How to get package version using burn API (Manas) > 4. Re: Chaining .NET 3.5 in Burn (Thomas Due) > 5. Can't run Heap on VS2013 MFC app (Gunnar Thalin) > 6. Re: How to get package version using burn API (Brian Enderle) > 7. Re: Buindle Major Upgrade cause first msi uninstallation > (Rob Mensching) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 11 Jan 2014 10:13:25 -0800 (PST) > From: Goran Malovic <[email protected]> > Subject: [WiX-users] Installing framework 4.0 update > To: "General discussion about the WiX toolset." > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Hi, > > our application requires .NET framework 4.0 and, since we use async > targeting pack, it also requires certain framework update to be installed. > I have found out that there are (at least) two updates that address issue > that arises when using async with framework 4.0 - KB2468871 and KB2600211. > Installing any of these two updates is enough, not both are required. My > qyestion is what is the correct way to make sure that our app will have all > prerequisites installed? > > Regards, > Goran > > > ------------------------------ > > Message: 2 > Date: Sun, 12 Jan 2014 20:11:08 -0800 (PST) > From: Tim Comport <[email protected]> > Subject: Re: [WiX-users] Buindle Major Upgrade cause first msi > uninstallation > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Any more info on this? I seem to be experiencing the same issue. > Bundle upgrade results in unchanged packages being uninstalled. > It appears to affect Windows XP but not Windows 7 in my testing. > > Is there an existing bug report for this, I was unable to find it ... ? > > Our current workaround is ensuring that all package versions are increased > in a bundle upgrade, however, now that the product has stabalized this is > no longer an option for us. > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Buindle-Major-Upgrade-cause-first-msi-uninstallation-tp7590764p7591715.html > Sent from the wix-users mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 3 > Date: Sun, 12 Jan 2014 22:38:02 -0800 (PST) > From: Manas <[email protected]> > Subject: [WiX-users] How to get package version using burn API > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Is there some way to get the version of a package contained within a > bundle using the burn API? None of the event handler arguments seem to > expose this information. > > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-get-package-version-using-burn-API-tp7591717.html > Sent from the wix-users mailing list archive at Nabble.com. > > > > ------------------------------ > > Message: 4 > Date: Mon, 13 Jan 2014 08:42:51 +0100 > From: Thomas Due <[email protected]> > Subject: Re: [WiX-users] Chaining .NET 3.5 in Burn > To: General discussion about the WiX toolset. > <[email protected]> > Message-ID: <3415CA37A52F074AB454B485FCDC17B00D489A518C@DK-HQ-MAIL> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you :) > > > Med venlig hilsen / Best regards, > Thomas Due ?- Software Developer > Tel: +45 8678 5500 Fax: +45 8678 5210 > Johann Gutenbergs vej 5-9, Aarhus N, Denmark [email protected] | > www.scanvaegt.dk > > > This e-mail and its attachments are intended for the named addressee only > and may contain information that is confidential and privileged. > Unauthorized use can instigate a claim for damages and constitute a > criminal offence. If you received this in error, please contact the sender > and delete the material. > > > > -----Original Message----- > > From: Phill Hogland [mailto:[email protected]] > > Sent: 10. januar 2014 21:13 > > To: [email protected] > > Subject: Re: [WiX-users] Chaining .NET 3.5 in Burn > > > > Niel provides the infor in his blog. > > http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html > > > > > > > > -- > > View this message in context: http://windows-installer-xml-wix- > > toolset.687559.n2.nabble.com/Chaining-NET-3-5-in-Burn- > > tp7591622p7591696.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > > > ------------------------------ > > Message: 5 > Date: Mon, 13 Jan 2014 12:39:55 +0000 > From: Gunnar Thalin <[email protected]> > Subject: [WiX-users] Can't run Heap on VS2013 MFC app > To: "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > When I create a new, empty MFC application in VS 2013 and run the vcxproj > file through Heat with "-pog Binaries", I get this error: > > error HEAT5305: Failed to load project testapp.vcxproj: Unable to cast > object of type 'System.Xml.XmlComment' to type 'System.Xml.XmlElement' > > If I create the MFC app in VS 2010 instead, it works. > It seems to have something to do with the "ToolsVersion" attribute in the > vcxproj file. It's set to 12.0 in the file made in VS 2013 and if I change > it to 4.0 and delete any "PlatformToolset" elements from the file, it > works. (But I guess it's not a good idea to do that, or?) > > (I know MFC is old, but we have some old projects we would like to move to > VS 2013 and WiX, so it would be very nice if I could get this to work.) > > Any help would be much appreciated. > > Thanks, > Gunnar > > > > ------------------------------ > > Message: 6 > Date: Mon, 13 Jan 2014 09:35:05 -0500 > From: Brian Enderle <[email protected]> > Subject: Re: [WiX-users] How to get package version using burn API > To: "General discussion about the WiX toolset." > <[email protected]> > Message-ID: > <CAKDn+dfKB=0SBQwZ4LQbhK= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > I use the following in my project, adding it to either the WiX project > file or as a task during 'msbuild': > > <!-- Define variables to be used throughout the install process --> > <Target Name="SetParameters"> > <GetAssemblyIdentity AssemblyFiles="..\HRActions\bin\HRActions.dll"> > <Output TaskParameter="Assemblies" ItemName="AssemblyVersions" /> > </GetAssemblyIdentity> > > <CreateProperty Value="%(AssemblyVersions.Version)"> > <Output TaskParameter="Value" PropertyName="AssyVersion" /> > </CreateProperty> > > <CreateProperty > > Value="$(AssyVersion.Split('.')[0]).$(AssyVersion.Split('.')[1]).$(AssyVersion.Split('.')[2])"> > <Output TaskParameter="Value" PropertyName="ShortAssyVersion" /> > </CreateProperty> > > <CreateProperty > Value="$(DefineConstants);LongAssyVersion=$(AssyVersion)"> > <Output TaskParameter="Value" PropertyName="DefineConstants" /> > </CreateProperty> > > <CreateProperty > Value="$(DefineConstants);ShortAssyVersion=$(ShortAssyVersion)"> > <Output TaskParameter="Value" PropertyName="DefineConstants" /> > </CreateProperty> > > <Message Text="AssemblyVersions: @(AssemblyVersions)"/> > <Message Text="AssyVersions: $(AssyVersion)"/> > <Message Text="ShortAssyVersion: $(ShortAssyVersion)"/> > > </Target> > > > This gets the version applied to the DLL file and then parses out the > pieces I want. > > > > Brian > > If you can't explain it simply, you don't understand it well enough. - > Albert Einstein > > > On Mon, Jan 13, 2014 at 1:38 AM, Manas <[email protected]> wrote: > > > Is there some way to get the version of a package contained within a > > bundle using the burn API? None of the event handler arguments seem to > > expose this information. > > > > > > > > > > > > -- > > View this message in context: > > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-g > > et-package-version-using-burn-API-tp7591717.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > ---------------------------------------------------------------------- > > -------- CenturyLink Cloud: The Leader in Enterprise Cloud Services. > > Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical > > Workloads, Development Environments & Everything In Between. > > Get a Quote or Start a Free Trial Today. > > > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg. > > clktrk _______________________________________________ > > WiX-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > ------------------------------ > > Message: 7 > Date: Mon, 13 Jan 2014 17:12:52 +0000 > From: Rob Mensching <[email protected]> > Subject: Re: [WiX-users] Buindle Major Upgrade cause first msi > uninstallation > To: General discussion about the WiX toolset. > <[email protected]> > Message-ID: > < > 1d3d3a1bad004910bb80a47d10fc2...@by2pr07mb185.namprd07.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Bundle log file should have detailed information about the states for each > package. > > -----Original Message----- > From: Tim Comport [mailto:[email protected]] > Sent: Sunday, January 12, 2014 8:11 PM > To: [email protected] > Subject: Re: [WiX-users] Buindle Major Upgrade cause first msi > uninstallation > > Any more info on this? I seem to be experiencing the same issue. > Bundle upgrade results in unchanged packages being uninstalled. > It appears to affect Windows XP but not Windows 7 in my testing. > > Is there an existing bug report for this, I was unable to find it ... ? > > Our current workaround is ensuring that all package versions are increased > in a bundle upgrade, however, now that the product has stabalized this is > no longer an option for us. > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Buindle-Major-Upgrade-cause-first-msi-uninstallation-tp7590764p7591715.html > Sent from the wix-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical > Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > ------------------------------ > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical > Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > > ------------------------------ > > _______________________________________________ > WiX-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wix-users > > > End of WiX-users Digest, Vol 92, Issue 20 > ***************************************** > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users
