FWIW, the reason why Gecko wouldn't need an additional package is that those parts are in Wine itself. We have Wine-specific iexplore.exe -regserver (and -unregserver) that are used as an equivalent of uninstalling Mono MSI package. It's easy to do for registries; files may more tricky, but fake DLLs should be doable this way. Gecko way may be not suitable for Mono, but may be worth consideration. Do existing files prevent native .net installer from running or installing them? Are the files that you intend to install just fake DLLs? Could we have Wine install them itself?
Part of the purpose of the files and registry keys is to prevent the native .NET installer from running. Most .NET application installers will try to run the .NET installer, and once it runs we can't reverse it.
We install some files which require Mono to build. I expect there will be more in the future.
The files and registry keys could probably be installed by .inf, given that we have access to the files themselves which have to come from Wine Mono. My concern is that we wouldn't have a reliable way for programs like winetricks to remove them before installing native .NET.
I'm going to be making another attempt at preventing the .NET 4.0 installer from trying to install over Wine Mono, and one possible outcome is that we have to install a stub MSI to impersonate .NET 4.0.
An important thing in past decisions was that prefixes should be transferable. For example, if you copy a prefix that uses a shared Mono to another machine that does not have Mono globally installed, it should still work. I guess now that have a reliable downloader/installer, we may just install required package the old way on the other machine. This can be done, but may need a special attention. Esp. if you'd implement the idea of "small" Mono MSI file, you'd need to make sure that it would not prevent complete install when shared location can not be located in runtime.
I'm starting to favor the CAB approach for this reason. For us to consider Wine Mono to be installed, we need the MSI and the Mono runtime. We could have logic which checks for both of these, and reruns the MSI if something is missing. That would take care of switching from a small MSI to the full one, but it makes checking for an install more complex. If we always have the Mono runtime installed in a shared addon location, we only need to check there. We can then run the MSI from the addon location unconditionally, and the MSI component will only do the install when it needs to.
This leaves the question of which component runs the MSI, and when. If mscoree does it, then appwiz.cpl only needs to manage static files, but doing the install via appwiz.cpl won't create a working installation. One would have to register mscoree or do a prefix update. If appwiz.cpl does it, that's some extra complexity that I'm not sure it should have.
Another thing to consider is that shared Gecko/Mono installation may be not mappable to DOS drives (eg. removed z: drive). We could probably fallback to full "old way" in such case. Or maybe we could make it work with ??\unix paths, I'm not sure.
How does this work currently? I would expect that an MSI can't install from outside the prefix in this configuration.