We have an application consisting of multiple components: main app (installed in program files) and multiple datasets (located in AppData). In the future there will be available (also) individual updates for one of components. What I want is to create one installer for all components, but create multiple uninstallers for components accessible from Programs and Functions. I've looked at Inno Setup, but I think it doesn't support this. Also tried NSIS, but it looks much difficult to use.
Wouldn't it be just as well (or better?) to make it all one install/uninstall program. And it works by noticing which features are present? If none then your screen consists of check boxes with what you want and don't want, then upon running it again later you would uncheck what you want to remove, etc.
Related
We have a product with more than 100 'pieces' most of which are optional 'plug-ins'. We would like a non-programmer to be able to make a "customized" installer on a per-customer/sale basis. Our ideal would be simply a single executable/msi with a folder structure from which files/folders could be deleted, then when run the installer would simply not offer features corresponding to the deleted bits.
A separate, but similar issue is that the developers of these plug-ins are not installation experts and we would prefer not to have to edit shared installer source to add/remove one from our build-set. We've been using the "synchronized folders" feature of Advanced Installer for this, but we would like a separately selectable feature for each plug-in.
Is there an installer tool-chain that can support such(or similar) behavior?
If so does anyone have tips on how to actually implement it using said tool?
I created such a tool stack at my last job. We did product line development with dozens of service families, hundreds of features, thousands of merge modules and tens of thousands of files in a typical installer.
Each merge module was authored using IsWiX and compiled using WiX. We then used WiX XML as an input to our build automation system to generate InstallShield installers. A service family would have an XML file to describe it's portion of the feature tree and it would all get emitted into an empty InstallShield project.
Finally a product XML file would describe the INSTALLDIR, UpgradeCode and other meta along with which features to consume. We built dozens and dozens of installers off this common base code.
It would take days to explain everything but that gives you the idea. For a simpler environment you could create a UI to generate WiX code and then compile it into an MSI.
But I don't know that I'd ever give this to a non-programmer. Creating installers is programming.
There is no tool that creates features at runtime in the MSI package, at least no MSI based tool. This complicates too much the installer logic, as you would need a very complex custom action that reads the contents of the folders found next to the installer and then generate entries in the following MSI tables: Files, Directory, Component, Feature, FeatureComponents. And then inter-connect all of this.
That is not something easy to do at all, and very error prone is tried by something how does not have extensive experience in building MSI packages.
have you considered/tried any non-MSI package builders?
I am making an extension for both VS2010 and VS2012 that has a toolbar command.
Given the change in icon style between them, I want to provide a separate icon for each.
How do I specify that in .vsct? I assume I might be able to use Condition, but I am not sure if there is already a pre-defined value with VS version.
It seems it is not possible without using an MSI, see "VS Package (VSIX): Having two different toolbar icons for VS2010/VS2012" on MSDN forums.
Ryan Molden (MSFT):
I do not believe you can use VSIX to install or specify target specific resources. VSIX is intended as a very simplistic deployment mechanism, it is in fact just a renamed ZIP file plus an installer with a small amount of logic to process pkgdef files. If you want more complex installs (like laying down different dlls based on your install target) I believe you would need to create an MSI.
I'm developing two projects at once - a class library with classes for things I commonly want in my applications, and an application that uses it. Since I want the library to be easily re-usable by other applications (and virtually stand-alone, even if it wouldn't actually do anything on its own), I have placed the library and application in separate solutions. However, although the dependence is one-way, they grow together.
I usually work on these project with multiple instances of Visual Studio open - one for the library, one for the application, and sometimes one for a scrap project where fool around to try new things.
I'd like to have it so that if I first build the library (perhaps requiring a "Release" switch) and then build the application, the latest changes from the library are available in the dll:s imported by the app.
What is a good way to set this up? Can it be done with e.g. NuGet - and if so, how?
(If it matters, I'm currently using the default settings for everything - basically two solutions created with "file->new". I'd like to change as little as possible of that, to lessen the threshold to import the library in my next application.)
I'm creating an installer for a client at the moment but I know that I'll have to create another in a couple of weeks for a different client. What techniques do people use to keep things tidy? The only differences will be whether to include certain dlls with the installer and which initial config file to include.
I was thinking of creating a main wxs file which has most of the share installation information on it and a secondary file which would be customised to the client which would control which components should be included.
Either that or rewrite the main wxs file for each client but that means maintaining a full wxs file for each client with lots of duplicated information.
I assume many other people have come across this situation and I would like to know if I'm on the right path or if there are other much better solutions.
Thanks for any help, Neil.
The solution you choose will depend on how extensive the differences are going to be between the different client installers and how many different clients you'll have to support.
If you only have to maintain 2-3 client installers with max of 10 variables files between them just create a single shared .wxs file that brings in a client-specific .wxi based on build-time parameters. It's easy enough to manually create and maintain 2-3 client-specific .wxi files.
If you have to maintain more clients, or there are 50 different possible dll/config file permutations I'd make use of WiX's heat.exe "harvester" tool. You would create a staging directory for every client you had to support that contained the dlls/config files required for each installer, use heat to harvest each directory into separate .wxs files, and then create a single shared .wxs file that would compile against each of the different harvested .wxs files to create the client installers. This solution requires the build process to be a little more complicated, but it's easier than trying to maintain 20 different client-specific wix files.
We have an off the shelf application with hooks built in to handle customer specific needs.
The custom code uses the same core libraries as our standard application.
Our current process is ship the standard app via an MSI and then separately send along the custom dll.
How is this typically handled?
create a setup project for each customer with the custom dll included with the main app(this seems unmaintainable)
keep sending the standard msi and send the dll separately (this has already proven to be terrible idea)
send the standard msi in addition to a custom code msi
other
If I'm understanding your question, you have one part of the application that is common to all users, and another part of the application that is custom-made for each user?
If that's the case, you should consider implementing the common part of the application as a Merge Module. Then, you create the custom part as an MSI and include the merge module inside. This would make the common part much easier to manage.
MSDN article on merge modules
See this question, our requirement was to embed custom configuration files in the MSI.
You should be able to modify this fairly easily so you have a "standard" MSI, and then ship an MST+CAB file containing the custom code. MST files are already familiar to administrators deploying applications over a network, if your customers generally double-click to install then you'll want to include a batch file or instructions on how to install with a transform.. e.g:
msiexec.exe /i setup.msi TRANSFORMS=test.mst