I want to compress multiple files and directories with wix installer and copy to custome fixed location eg. C:/MyAPP it while installing. I have following directory structure which i want to include into wix msi.
Directory structure:
MYAPPBin
myapp.exe
demo.dll
demo.dll2
How-To: I am against installing to the root, for many technical and practical reasons, but here is a description of how to do it: https://support.firegiant.com/hc/en-us/articles/230912267-Install-to-the-root-of-system-drive-
"No Speeches": Oh, let's rant :-). Why you should not do it? 1) Standard: It is not standard. 2) Necessity: It is generally not necessary. 3) Corporate: It will often not be accepted onto corporate machines for failing standards. 4) Support: Accordingly you will get support requests asking if this can be fixed by application packagers for corporate deployment - especially if you have lots of customers and user-base. 5) Technical: Typically you see technical deployment problems during repair, patching and upgrades. 6) Permissions: You will face ACL (permission) issues if you want to write to files in there (check for OS-differences, I didn't check lately) - so you need to apply full write permissions as well - a security issue when it is so in people's face on the root. 7) Tools: Modern deployment technologies actively make it hard to break the rules like this, for good reason - in the end: another wind-mill to fight for nothing gained? 8) Longevity: Future changes in Windows could mean your application no longer runs properly from that location? 9) Bloating: If many software do this it really bloats the root of your system drive and that can really annoy a lot of people - triggering unexpected and accidental deletion. 10) Backup: The product could accidentally be picked up for storage by backup systems bloating the backup - very bad if the product is big (unless backup is desired). 11) System Restore: I have honestly seen system restore mess up whole computers, and I wonder what it does to things that live on the system root? I don't know for sure. A section here on system restore and its lunacy (towards bottom). 12) Windows Updates: Not a great item, but let's list it. We have seen Windows Updates to crazy things like delete user's data before, and it is conceivable that it could cause interference for root folders. 13) Security Software: How does anti-virus and malware scanners like root folders? I have never seen any problems, but they keep adding more and more weird features and suddenly you have problems with something unexpected? (I have had anti-virus tools quarantine my freshly built binaries :-) - vernichtete!). 14) Indexing: For deployment of large numbers of data files, there is probably no indexing on the root of your system drive? (if that is desired). There is no indexing in %ProgramFiles% either, but there generally is in user-profile folders (desktop, my documents, etc...) - if the files you deploy are templates and such. And there are further issues. Much better to install in standard ways?
Anecdotally I can add: Diligent system administrators with cleanup-mania (formal diagnosis that) may delete such folders as part of their cleanup scripts and auditing (especially if you make the folder name mysterious), or at least want to throw out the application, or test moving it to %ProgramFiles% to see if it works. They may allow core security software to install like this, for easy access to settings and tools in there, but that is rare. Developers may accept SDKs installed this way - for the same reason: accessibility and ease of use. Some server software may also be deployed like this for "single-purpose-servers", but then it often goes to another drive than the system drive - such as D: - is my experience. For almost any other purpose it is detrimental - in my opinion and I think I share it with many deployment guys.
"Exceptions": I might opt for a "self-extractor" kind of approach defaulting to "My Documents" if the files you are deploying are to be used to change and modify. Or even the desktop for a set of HTML templates. It all depends on what makes sense, what is useful for users and what can be technically supported without "spaghetti incidents".
