Programmatically building a dotNetInstaller package

Mar 20, 2009 at 6:39 PM
First off, so glad to see the project moved to Codeplex! I'd used it at a previous employer and always thought it should be on a place like this. Thank you very much for that.

We're looking at <hints id="hah_hints"></hints>writing some custom deployment and packaging software that will make a single dotNetInstaller package as an end result. Ideally, we'd do this programmatically without resorting to a command line, etc.

Poking around the source and DLLs, it seems like InstallerLinker.CreateInstaller() would be the logical entry point for another DLL to call - would you agree with that? More importantly, can we expect that to be a (semi-) stable interface for using dotNetInstaller?

Thanks,
-Scott
Mar 20, 2009 at 6:49 PM
The short answer is yes.

InstallerLib is the common denominator and was designed exactly for your purposes. Add a reference to it in any .NET project and you can call InstallerLinker. I don't plan to do any work to the interface at least in the short term, so I guess I don't expect it to change. It's rather rudimentary. For example it is taking a configuration file in. A better way of doing this is to split the interface and take a loaded ConfigFile. There're many other improvements like that that are desired. So I think you'll run into limitations and you are invited to contribute changes to this interface in DNI rather than trying to workaround issues with the existing one. I'm here to help with code reviews and integration.

cheers
dB.
Jul 17, 2009 at 8:35 PM

I am curious whether you guys did anything with this (and for what product)?

So maybe this will be of interest to you. In 1.7 I've refactored the C++ configuration portion into a library as well, so you could now build another bootstrapper runtime and use the library to load the configuration. The library contains the component selection and execution code as well, but no execution pipeline (the for-each component, install, loop).