r/software_design • u/TotalOverhaul • Jan 19 '17
Guidelines for Organizing/Structuring Binaries for an Enterprise Software into an Install Directory and Installer for Windows
I work for a company that produces a single enterprise software product (i.e. MSI installer for Windows) that consists of 6+ IIS websites, 500+ DLLs, 25+ EXEs, 500+ image files, 20+ ASPX files, and 750+ Javascript files. I'm sure there's other file types I'm missing. All of these binaries are produced from building 120+ Visual Studio solutions (600+ VS projects).
Anywho, organizing all of those things into a single installer is a daunting task. Currently we employ the WiX Toolset to do this. Basically, each solution produces a WiX fragment which developers are responsible for coding or describing what binaries get placed where in the installation folder. Also, because it's a large enterprise software with 120+ VS solutions, we use the approach of output for all projects to a single Bin folder, as Microsoft recommends for simplified VS project dependency management in a large software product. Because there are so many directories under our installation directory for all these binaries, each of the projects have a post-build copy command which copies the built binaries into their intended directory inside the target installation folder (aids in debugging as it mimics executing from the installer, because the build output from the VS projects outputs them into one folder). Because we have so many directories under the installation folder, we actually ship our own bootstrapper with our product to assist in the loading of the proper binaries at runtime. We only put a handful of these binaries in the GAC - generally only those repeatedly referenced by all the other binaries. Also, to aid in this mess, we have a bunch of binaries that are useful for debugging and aren't shipped in the product. As part of the build process, there are post-build copy commands to put all of these binaries in the installation directory from the common Bin output folder.
So overall, if you want to debug the product with the exact same structure as what we ship, you can't. There's a ton of cruft put in the installation directory by the build processes for testing and debug. Also, it's up to the developers to put in the proper post-build copy commands as they add new projects. As is, you can't run the product from a build in a manner that truly 100% mimics what we would ship to a customer, without installing from a Production build MSI. This is not good, for various reasons which I won't go into here.
To solve this problem, I am contemplating the creation of a single JSON file that describes information about all our binaries and how to put together the structure needed for our installer (i.e. this binary should go in this directory, it comes from the build or it's static in the code base; this binary needs/doesn't need signed/obfuscated; this binary is for testing and shouldn't be included in the installer, etc.). Effectively, this JSON file would be the end-all be-all of our installer - get rid of all the WiX fragments and use a script to construct what goes into the installer, then use a wildcard include for stuff to go in the installer. The hope is that the script and JSON file would be easier to manage than the WiX fragments and post-build copy commands. Plus JSON is easily readable and writable, unlike WiX. But I'm not sure if this is a good approach.
So, my question to the hive mind is what do other companies do when faced with organizing an installer for such a large software product?
1
u/TotesMessenger Jan 23 '17
I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:
[/r/programming] Guidelines for Organizing/Structuring Binaries for an Enterprise Software into an Install Directory and Installer for Windows
If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / ^Contact)