Re: [WiX-users] Automatically include arbitrary files
Yes, exactly. On Thu, Jul 22, 2010 at 12:26 PM, Lukas Haase lukasha...@gmx.at wrote: Dear Blair, Thank you very much for your comprehensive explanation. Together with the comments from Does the MSI-filename matter I think I won't care about minor and small updates and just ship always a major upgrade. Morever if this is best practice. The saving isn't it worth! Just one last comment on this: I will always ship anything and just always change version and product GUID. But I will always keep the same UpgradeCode, won't I? This means that as long as I keep the UpgradeCode the same the MSI will detect a previous version and may upgrade it? Regards, Luke Am 22.07.2010 19:05, schrieb Blair: One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me 2% static content). If you are vigilant at maintaining the component rules you can use late scheduling of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the for any given build, release either MSI or superseding MSP, never both rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my back-of-the-envelope analysis may not be correct. Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... ... -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF.net email
Re: [WiX-users] Automatically include arbitrary files
Correct. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:27 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files Dear Blair, Thank you very much for your comprehensive explanation. Together with the comments from Does the MSI-filename matter I think I won't care about minor and small updates and just ship always a major upgrade. Morever if this is best practice. The saving isn't it worth! Just one last comment on this: I will always ship anything and just always change version and product GUID. But I will always keep the same UpgradeCode, won't I? This means that as long as I keep the UpgradeCode the same the MSI will detect a previous version and may upgrade it? Regards, Luke Am 22.07.2010 19:05, schrieb Blair: One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me 2% static content). If you are vigilant at maintaining the component rules you can use late scheduling of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the for any given build, release either MSI or superseding MSP, never both rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my back-of-the-envelope analysis may not be correct. Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... ... -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do
Re: [WiX-users] Automatically include arbitrary files
Dear Blair, Thank you so much! It's really great! Did not think that it will be that simple. I am quiet astonished that all the flags you told me are neither in the help file nor at [1]. But calling heat without parameters tells all hidden parameters... Am 22.07.2010 00:48, schrieb Blair: -ag switch: [...] This results in stable GUIDs that don't change between builds unless you change the directory or the filename (and in either of those cases, you want a new guid). [...] The * for guids in the compiler means generate and the algorithm for guid generation is different based on what the guid is for, but always with an eye toward the safest results for as many cases as possible. This was exactly what I did not know. GREAT if this is the case!! Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... [...] SourceFile directory: Easiest fix (from my point of view) is to use the -var switch, and tell the compiler where to look. Something like this: Heat ... -var PdfFolder ... Candle ... -dPdfFolder=src\INSTALLDIR\pdf\ ... Great!! Thank you very much. For the archive: Use heat ... -var var.PdfFolder=... ... And for the second problem (TARGETDIR/INSTALLDIR) there is another hidden switch: heat ... -var var.PdfFolder=... -dr INSTALLDIR ... Regards, Luke [1] http://wix.sourceforge.net/manual-wix3/heat.htm -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 3:17 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files Am 22.07.2010 00:07, schrieb Lukas Haase: Dear Blair, I do not fully understand. You mean the -ag switch? But then on every compile the PDF files get a different GUID, don't they? Then back to the original question: Does it matter in ANY way if they get a different GUID on upgrades? I.e. In a few months I will make the first upgrade for for my product. Most likely a few PDFs will be removed, a few will be added. Is there any concern with your proposed method? Dear Blair, Sorry, I forget one additional question: Heat generates theFile-Elements as: File Id=fil6CD3EB10EF7C12F5645E92DEC7FA408E KeyPath=yes Source=SourceDir\04156.pdf / ^ but in fact I placed the PDFs (relative to the directory from where I call candle/light) in src\INSTALLDIR\pdf Is there any way to replace SourceDir with src\INSTALLDIR\pdf automatically? Or is there another solution? Similar the directory with is created as: DirectoryRef Id=TARGETDIR ^ Directory Id=dir92AEA0E44CFC478DB41459D407BB54A9 Name=pdf / /DirectoryRef But in fact it should beDirectoryRef Id=INSTALLDIR in order to work... Thank you very much. Regards, Luke Am 21.07.2010 23:41, schrieb Blair: In your settings for heat, you should use automatic component guids (they come out as Guid=*) and you should setup a component group for your PDF files (then you can simply refer to them from your feature using the ComponentGroupRef element). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 1:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Automatically include arbitrary files Hi, My setup project consists of a bunch of static files (application, DLL), a huge databasefile and a vast amount of PDF files. The PDF files are very volatile, they change from update to update (some are removed, some are added but no of them are changed). As they are many files I would really prefer to add them automatically. I looked at the include-directive from the preprocessor but I can't find out how to automate. I looked at fragments and played around with heat. In general, this would work. heat generates a wxs file containing a list of all pdf files. However, I have all of them to add to theFeature-List
Re: [WiX-users] Automatically include arbitrary files
One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me 2% static content). If you are vigilant at maintaining the component rules you can use late scheduling of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the for any given build, release either MSI or superseding MSP, never both rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my back-of-the-envelope analysis may not be correct. Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... ... -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Automatically include arbitrary files
Dear Blair, Thank you very much for your comprehensive explanation. Together with the comments from Does the MSI-filename matter I think I won't care about minor and small updates and just ship always a major upgrade. Morever if this is best practice. The saving isn't it worth! Just one last comment on this: I will always ship anything and just always change version and product GUID. But I will always keep the same UpgradeCode, won't I? This means that as long as I keep the UpgradeCode the same the MSI will detect a previous version and may upgrade it? Regards, Luke Am 22.07.2010 19:05, schrieb Blair: One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me 2% static content). If you are vigilant at maintaining the component rules you can use late scheduling of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the for any given build, release either MSI or superseding MSP, never both rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my back-of-the-envelope analysis may not be correct. Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... ... -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Automatically include arbitrary files
Hi, My setup project consists of a bunch of static files (application, DLL), a huge databasefile and a vast amount of PDF files. The PDF files are very volatile, they change from update to update (some are removed, some are added but no of them are changed). As they are many files I would really prefer to add them automatically. I looked at the include-directive from the preprocessor but I can't find out how to automate. I looked at fragments and played around with heat. In general, this would work. heat generates a wxs file containing a list of all pdf files. However, I have all of them to add to the Feature-List in my main file as ComponentRef-element! Isn't there a way to include the whole fragment and/or directory? Even if this would work, I still have to manually add/remove the items in the pdfs.wxs. It would be really great if I could just put the current PDFs in the diretory pdfs and all of them are just added to the MSI. However, if I run heat multiple times I clearly get different GUIDs for the PDFs on each call. Does it matter when the GUIDs of the files change? Especially for the update? Is there any chance to automate this process consistently? Best Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Automatically include arbitrary files
In your settings for heat, you should use automatic component guids (they come out as Guid=*) and you should setup a component group for your PDF files (then you can simply refer to them from your feature using the ComponentGroupRef element). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 1:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Automatically include arbitrary files Hi, My setup project consists of a bunch of static files (application, DLL), a huge databasefile and a vast amount of PDF files. The PDF files are very volatile, they change from update to update (some are removed, some are added but no of them are changed). As they are many files I would really prefer to add them automatically. I looked at the include-directive from the preprocessor but I can't find out how to automate. I looked at fragments and played around with heat. In general, this would work. heat generates a wxs file containing a list of all pdf files. However, I have all of them to add to the Feature-List in my main file as ComponentRef-element! Isn't there a way to include the whole fragment and/or directory? Even if this would work, I still have to manually add/remove the items in the pdfs.wxs. It would be really great if I could just put the current PDFs in the diretory pdfs and all of them are just added to the MSI. However, if I run heat multiple times I clearly get different GUIDs for the PDFs on each call. Does it matter when the GUIDs of the files change? Especially for the update? Is there any chance to automate this process consistently? Best Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Automatically include arbitrary files
Dear Blair, I do not fully understand. You mean the -ag switch? But then on every compile the PDF files get a different GUID, don't they? Then back to the original question: Does it matter in ANY way if they get a different GUID on upgrades? I.e. In a few months I will make the first upgrade for for my product. Most likely a few PDFs will be removed, a few will be added. Is there any concern with your proposed method? Regards, Luke Am 21.07.2010 23:41, schrieb Blair: In your settings for heat, you should use automatic component guids (they come out as Guid=*) and you should setup a component group for your PDF files (then you can simply refer to them from your feature using the ComponentGroupRef element). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 1:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Automatically include arbitrary files Hi, My setup project consists of a bunch of static files (application, DLL), a huge databasefile and a vast amount of PDF files. The PDF files are very volatile, they change from update to update (some are removed, some are added but no of them are changed). As they are many files I would really prefer to add them automatically. I looked at the include-directive from the preprocessor but I can't find out how to automate. I looked at fragments and played around with heat. In general, this would work. heat generates a wxs file containing a list of all pdf files. However, I have all of them to add to theFeature-List in my main file asComponentRef-element! Isn't there a way to include the whole fragment and/or directory? Even if this would work, I still have to manually add/remove the items in the pdfs.wxs. It would be really great if I could just put the current PDFs in the diretory pdfs and all of them are just added to the MSI. However, if I run heat multiple times I clearly get different GUIDs for the PDFs on each call. Does it matter when the GUIDs of the files change? Especially for the update? Is there any chance to automate this process consistently? Best Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Automatically include arbitrary files
Am 22.07.2010 00:07, schrieb Lukas Haase: Dear Blair, I do not fully understand. You mean the -ag switch? But then on every compile the PDF files get a different GUID, don't they? Then back to the original question: Does it matter in ANY way if they get a different GUID on upgrades? I.e. In a few months I will make the first upgrade for for my product. Most likely a few PDFs will be removed, a few will be added. Is there any concern with your proposed method? Dear Blair, Sorry, I forget one additional question: Heat generates the File-Elements as: File Id=fil6CD3EB10EF7C12F5645E92DEC7FA408E KeyPath=yes Source=SourceDir\04156.pdf / ^ but in fact I placed the PDFs (relative to the directory from where I call candle/light) in src\INSTALLDIR\pdf Is there any way to replace SourceDir with src\INSTALLDIR\pdf automatically? Or is there another solution? Similar the directory with is created as: DirectoryRef Id=TARGETDIR ^ Directory Id=dir92AEA0E44CFC478DB41459D407BB54A9 Name=pdf / /DirectoryRef But in fact it should be DirectoryRef Id=INSTALLDIR in order to work... Thank you very much. Regards, Luke Am 21.07.2010 23:41, schrieb Blair: In your settings for heat, you should use automatic component guids (they come out as Guid=*) and you should setup a component group for your PDF files (then you can simply refer to them from your feature using the ComponentGroupRef element). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 1:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Automatically include arbitrary files Hi, My setup project consists of a bunch of static files (application, DLL), a huge databasefile and a vast amount of PDF files. The PDF files are very volatile, they change from update to update (some are removed, some are added but no of them are changed). As they are many files I would really prefer to add them automatically. I looked at the include-directive from the preprocessor but I can't find out how to automate. I looked at fragments and played around with heat. In general, this would work. heat generates a wxs file containing a list of all pdf files. However, I have all of them to add to theFeature-List in my main file asComponentRef-element! Isn't there a way to include the whole fragment and/or directory? Even if this would work, I still have to manually add/remove the items in the pdfs.wxs. It would be really great if I could just put the current PDFs in the diretory pdfs and all of them are just added to the MSI. However, if I run heat multiple times I clearly get different GUIDs for the PDFs on each call. Does it matter when the GUIDs of the files change? Especially for the update? Is there any chance to automate this process consistently? Best Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Automatically include arbitrary files
-ag switch: sets the guid of each generated component as *. This cause the compiler to compute a GUID based on the directory tree the component is in and the name of the keypath. This results in stable GUIDs that don't change between builds unless you change the directory or the filename (and in either of those cases, you want a new guid). -ag should have been the default in heat from the beginning. If you use -gg, the guids will be different every time, and that would be bad. The * for guids in the compiler means generate and the algorithm for guid generation is different based on what the guid is for, but always with an eye toward the safest results for as many cases as possible. Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). SourceFile directory: Easiest fix (from my point of view) is to use the -var switch, and tell the compiler where to look. Something like this: Heat ... -var PdfFolder ... Candle ... -dPdfFolder=src\INSTALLDIR\pdf\ ... Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 3:17 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files Am 22.07.2010 00:07, schrieb Lukas Haase: Dear Blair, I do not fully understand. You mean the -ag switch? But then on every compile the PDF files get a different GUID, don't they? Then back to the original question: Does it matter in ANY way if they get a different GUID on upgrades? I.e. In a few months I will make the first upgrade for for my product. Most likely a few PDFs will be removed, a few will be added. Is there any concern with your proposed method? Dear Blair, Sorry, I forget one additional question: Heat generates the File-Elements as: File Id=fil6CD3EB10EF7C12F5645E92DEC7FA408E KeyPath=yes Source=SourceDir\04156.pdf / ^ but in fact I placed the PDFs (relative to the directory from where I call candle/light) in src\INSTALLDIR\pdf Is there any way to replace SourceDir with src\INSTALLDIR\pdf automatically? Or is there another solution? Similar the directory with is created as: DirectoryRef Id=TARGETDIR ^ Directory Id=dir92AEA0E44CFC478DB41459D407BB54A9 Name=pdf / /DirectoryRef But in fact it should be DirectoryRef Id=INSTALLDIR in order to work... Thank you very much. Regards, Luke Am 21.07.2010 23:41, schrieb Blair: In your settings for heat, you should use automatic component guids (they come out as Guid=*) and you should setup a component group for your PDF files (then you can simply refer to them from your feature using the ComponentGroupRef element). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 1:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Automatically include arbitrary files Hi, My setup project consists of a bunch of static files (application, DLL), a huge databasefile and a vast amount of PDF files. The PDF files are very volatile, they change from update to update (some are removed, some are added but no of them are changed). As they are many files I would really prefer to add them automatically. I looked at the include-directive from the preprocessor but I can't find out how to automate. I looked at fragments and played around with heat. In general, this would work. heat generates a wxs file containing a list of all pdf files. However, I have all of them to add to theFeature-List in my main file asComponentRef-element! Isn't there a way to include the whole fragment and/or directory? Even if this would work, I still have to manually add/remove the items in the pdfs.wxs. It would be really great if I could just put the current PDFs in the diretory pdfs and all of them are just added to the MSI. However, if I run heat multiple times I clearly get different GUIDs for the PDFs on each call. Does it matter when the GUIDs of the files change? Especially for the update? Is there any chance to automate this process consistently? Best Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
