I’m currently working on a Visual Studio 2010 setup Project and would like to know if the following is possible:
1) Run the setup project in a way that the default forms don’t show, instead I’d show my own custom form that subscribes to setup project events. This way I'd show install messages and increase my own progress bar.
2) If 1 is possible, I would need a way to specify the default location.
3) I have a separate library project, where I have a custom install class (inherits from “System.Configuration.Install.Installer”) from within the install handler I’d like to be able to show custom windows forms, and control choices made by the user. I guess this is possible by adding a reference to system.windows.forms, but would this be the correct way to go about this? If I couldn't hide the default install form, these custom forms would appear over the default install one and I think it would look too great.
Suggestions, links etc appreciated Thanks!
*UPDATE 1 *
Could I launch an .msi from c# code but also passing in a value.?
Just what this guy does here: link
But passing in a value... then from my custom install class I take actions depending on this value.
UPDATE 2
Seems like I can: link code project
UPDATE 3
I'm considering in doing the following, I'll start testing with a winforms app.
1) Launch winforms application.
2) Make a few webService calls, display data, user makes selection.
3) As per link in update 1, launch process(silent mode) and per update 2, pass in selected values.
4) Use some cross process events mechanism (WCF) so that my custom install class can notify my form of the different steps its running and update progress bar and messages.
You can create custom forms but the declaration needs to be done inside MSI. You can show a custom dialog via a custom action but that will not help you much since msi does this:
This is done every time a custom action is called. This is one of the main reasons why custom actions are normally written in C++.
To be more flexible you should use the WIX toolkit which allows .NET integration as good as it can be with MSI. MSI itself knows nothing about .NET and is a world of its own. MSI itself defines dialogs and controls inside the msi via tables like the Dialog and Control table. You could create a dialog and store your state in a msi property between each several msi actions which need to happen e.g. to calculate the disc space for the selected features and so on. But I doubt that this solution will be performant and I fear that starting and shutting down the CLR so often inside one process will expose you to CLR bugs that no one has encountered before.
To set the target location you only need to call the MSI method MsiSetTargetPath which you can PInvoke very easy.
To disable the normal UI you can override it completely or partially vis MsiSetExternalUI but I have not tried to disable only specific dialogs. If you want to hide specific dialogs you should check the msi tables of your current MSI to check if you can set a msi property to make the dialog think it has already been shown.
Yours, Alois Kraus