29

I would like to harvest a folder with a lot of files by using heat.exe. But instead of harvesting all files, I would like to exclude specific file extensions like "*.txt" or something like that. How can I do this?

user145400
  • 1,076
  • 1
  • 12
  • 27
Marcus
  • 1,105
  • 2
  • 21
  • 35

3 Answers3

7

I think the only option for now is to harvest the entire folder and apply a transform to the resulting .wxs file (see -t:<xsl> switch) to exclude what is not required (txt files in your case). However, I didn't try the 3.5 version of heat (judging based on the 3.0), but I don't think there are changes in this area.

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
  • Do you have more information on this? I would like to do the same thing, but against ".cs" files. I've scoured the net looking for examples, but haven't yielded anything. – Sean Anderson Dec 30 '11 at 00:40
  • 1
    What do you mean? The basic idea here is heat.exe will harvest the entire folder contents for you, sand it's your responsibility then to filter out the result, either with the XSLT and supported -t switch, or any other custom way. I'd also strongly recommend you to read and understand @Christopher's answer below about the danger of this approach. – Yan Sklyarenko Dec 30 '11 at 05:38
3

I'm not a huge proponent of this pattern. How do you ensure change control when using a non-deterministic process? How do you know a file that appeared in a directory really should ship in a product and how do you know a file that vanished from the directory shouldn't break a build? How do you know you are breaking the component rules and creating servicability issues?

I used to do dynamic file linking in the 1990's because it was "easy" but I can remember it biting me many times and I haven't done it ever since.

I know Bob Arnson used to agree with this view point:

http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg03420.html

But now in WiX 3.5 I'm starting to see capabilities that support dynamic linking and I just don't understand why they would go that way. I'd much rather update a WXS file and check it back into source control then risk putting my deployment process on autopilot.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • What do you mean by "ensure change control when using a non-deterministic process" in simple words? What is "dynamic linking" in this context, if not .dll files? I think you're trying to say that you should specify the same list of files a second time in WiX. It seems to me that this is tedious and error-prone and should be automated. – Anthony Jan 22 '12 at 20:23
  • 1
    What I'm saying is "the buck stops here". Installs are part development and part change management. It's frequently associated with build / release management. The point is if a new file needs to be added to the installer or a file needs to be removed from the installer I want that change to occur intentionally. When you use dynamic file linking upstream problems in the automation can cause files to magically appear and disappear from the installer with no warning. This never ends well. This *is* error prone. To be continued... – Christopher Painter Jan 22 '12 at 22:29
  • 1
    However having a work item associated with the installer stating that a file needs to be removed or added and tasking a developer to make a change in source control to implement that item is *not* error prone. It's something that can be built and tested. Now if upstream problems occur you don't get files magically added and removed. It's very reliable. Besides, I've worked on projects with 20,000 files in the installer and the churn from build to build isn't very great. You reach a point of stability where you no longer desire it to be dynamic anyways. – Christopher Painter Jan 22 '12 at 22:29
  • I'm not conviced by the "files magically appear and disappear" argument. If files are in the website's content, then these file appearing in the installer is a good thing, otherwise why are they present at all? If the actual content only appears sometimes nondeterministically, then the installer generator is buggy. If the files that you need are appearing and disappearing from your source tree, the problem's not in the installer. ... – Anthony Jan 23 '12 at 21:49
  • With two different list of files you can have web content that is present in source control, present when a developer is debugging locally, but are not present on a live installation. That is an invitation to chase spurious bugs. If the content file isn't present on a live site, surely it's better to remove it all the way upstream, rather than just in the installer? Why have two different content inventories? If they're not different, why have two identical independant ones? ... – Anthony Jan 23 '12 at 21:50
  • We could debate different strategies, and I'm happy that your way of working is supported, but I don't think it's the only way to do it, or that the tools should be limit you to working this way. – Anthony Jan 23 '12 at 21:50
  • Sorry, I think tools should good patterns and practices not antipatterns. There are far too many developers out there who don't know the first thing about installers who are tasked with creating installers. I've seen it all in my 16 years of experience and you can take it to the bank when this industry recognized expert tells you that it won't end well. – Christopher Painter Jan 24 '12 at 00:40
  • Unsuprisingly, your appeal to authority has not convinced me. All projects are not the same and I am not going to say what's the right way for your projects, they sound quite different from mine. But I agree that the tools and patterns should be easier - much easier - to use for developers who only work on installers occasionally, since this is the usual case. I'm still amazed that the esential difficulty of making an installer is so badly compounded by obtuse tools. – Anthony Jan 24 '12 at 21:41
  • No, the essential difficulty is that an installer is not simply xcopy. Not in expecting a tool to automagically abstract it as such. And I am also not suprised that you aren't convinced. That's OK, I've had that same reaction from hundreds of developers over my career and they all come around eventually once they realize the gravity of the situation. Frankly I don't care of your install is problematic, it just means more consulting work for me later. – Christopher Painter Jan 24 '12 at 21:47
  • This is an opinion, not an answer to the question. The opinion may be valid and well reasoned, but still not an answer to the (valid) question, thus in my opinion not constructive. – chris Feb 01 '13 at 14:35
  • I was always taught requirements, design, construction and that the farther you get the more painful it is to change. If I save someone the headache of going down a road they regret then it's constructive. If you don't think it's constructive, I don't really care. Sometimes "don't do that" is a valid answer. – Christopher Painter Feb 01 '13 at 16:05
  • In a CI environment, updating a wix source file whenever you add or remove a file in the project is contra-productive. – Oskar Emil Sep 24 '13 at 19:09
  • Nonsense. If you can be bothered to add a .CSPROJ to the .SLN you can be bothered to add a .DLL to the .WXS. It's called being a software engineer. – Christopher Painter Nov 19 '13 at 15:30
  • Installer is not only about hard products like .DLLs, .EXEs or similar. It can be about resource/content/data packages. For example, if you do some webthingies, you really may end up in having zillions of tiny files that often change their locations, names and quantities - just because the web guys like to create their websites that way. And no, they will not want to add every single file to "the masterlist", nor remove any single file from "the masterlist", simply because they are used to an environment that **existence** of the file at **that location** is enough. Irritating, but real life. – quetzalcoatl Feb 21 '14 at 23:14
  • Don't get me wrong - I'm not very experienced in the WiX toolset, and I don't want to fire another discussion. I just have seen many "fluent" code/content sets, and I just "sense a problem" with the approach of manually keeping up the lists. Teams already have much work, and if I tell them to keep extra list of 1000+ files, they will give ma a look and keep xcopying ;) I believe that `heat` and other generators really can help - they just have to be used properly, as any tool. – quetzalcoatl Feb 21 '14 at 23:22
  • @quezalcoatl- That works great until it doesn't. That's the problem. Odds are if someone can't keep up with their application footprint they can't keep up with the automation that's supposed to. MY last job had 250 developers working in a product line environment. This meant dozens of service families composing dozens of products on dozens of branches. The typical installer had 15,000 files and 150 features. We were able to maintain a product architecture roadmap and have all the developers contribute to it. The result has bulletproof installers and informed developers. – Christopher Painter Feb 22 '14 at 00:20
  • PS, I have a new feature I'd like to implement in ISWIX if you'd be interested in helping to write it. I think you'd like it. – Christopher Painter Feb 22 '14 at 00:21
  • This is an excellent discussion to which I'd like to add something; @ChristopherPainter you are correct in the principle, as we did get bit with missing or extraneous files; there are however other and (in my humble opinion) better ways to track files to be included in an installer, such as commit reviews and automated deployment verification processes, which validate both the installer logic and the actual installed files. Having yet another manual action for every file (especially art files) is not be the only way to go, and should not be forced; only recommended. – Christian Rondeau Jun 28 '14 at 20:59
  • @Christian the problem is I haven't seen any off the shelf solutions to do those things. It also tends to take a lot of $$$ to write those things one off for a single shop and it's only useful in that environment. All things considered, I choose to make the friction of making the change as small as possible. – Christopher Painter Jun 28 '14 at 21:20
2

Instead of trying to figure out how to harvest selected files from of a folder, I use a before build action to populate a folder with just the files that I want harvested. The following workflow has been working for me:

  1. Delete a "files" if it exists
  2. Create a "files" folder
  3. Copy the files to the "files" folder. I use the robocopy build action, that gives me enough control to specify which files to include or exclude.
  4. Harvest the entire folder.

I have it set to run the harvest action conditionally, just for debug builds. Release builds are generated from our TFS server and use the generated .wxs from source control. It should be OK to run harvest on the build server, but it's an extra step and not having it run eliminates the "non-deterministic process" problem described by Christopher Painter. Other than that one step, the same steps execute on the build server as they do on my dev machine.

Community
  • 1
  • 1
Chris Miller
  • 4,809
  • 4
  • 33
  • 50