3

I want to build a Wix installer which will detect a few programs of mine and update them.

I have c# code (using another DLL) to check a few things on the system, then I want to download a table of the most recent version of all the apps, decide which app I need to update, and then download & update the selected ones.

So my question is, can Wix preform the following actions:

1) run another dll call using c#?

2) download a file from the web and parse it (let's say - also using c#)?

3) go to a link and download an MSI\EXE?

4) install the MSI\EXE (let's say run it on silent mode)?

5) uninstall old other apps from system?

Improve this question
1
  • I suppose you can go as far as you want. Whether that's good design or not is another question... Commented Aug 1, 2013 at 14:10

3 Answers 3

Reset to default
5

Windows Installer has a mutex that only allows 1 execute sequence per machine and 1 UI sequence per process. One MSI cannot install another MSI due to this limitation. There are hacks around this but they don't follow good design (don't provide proper elevation support or silent install / uninstall support ).

You should use custom actions with care. A properly designed custom action should behave like the standard actions built into Windows Installer. That is support transactional installation whenever possible and be data driven via custom tables.

A better candidate for the stuff you are describing needing to be done would probably be a bootstrapper / chainer such as WiX's Burn feature.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

1) - definitely yes

2)-5) you could do it but you should differ msi from "custom bootstrapper" and "custom after install configuration manager". General rule: use msi package only for resource (usually files; in more complex cases - registry, in most cases sql objects) atomic deployment; move all other functionality outside msi (means use wix ony to build msi; create custom utilities for bootstrapper and configuration tool; see wix samples how to integrate three parts together).

Improve this answer

3 Comments

Thanks! can you explain to difference between msi and a bootstrap/"configuration manager". they are still part of the Wix but not MSI?
The MSI SDK came with a very simple sample setup.exe project but other then that nothing. They left that problem to the tools providers (InstallShield mainly at the time).
*.msi is the package of instruction for Winodows Installer tool. you can create such package using wix. Bootsraper is the custom app that usually manage/installs prerequisites and after this starts windows installer process. Any setup.exe is bootsrapper. Wix brings a sample of it, last version propose "general bootsrapper" but it is not flexible. Custom configuration manager is a custom app that could be used after msi have successfully installed all files e.g. to configure user access. Wix is mostly about msi package creation.
1

1) Yes but keep in mind that if you have a dependency on .NET 3.5 and you are on a box with .NET 4 your custom action will not be able to run. Besides this your custom action dll is unpacked from the msi into the %TEMP% folder. If you have any dependency to other dlls not stored in the GAC you will fail to load. If you bring in another e.g. C++ dll you have to embed it as resource in your C# dll and unpack it as well to find it.

2) You can do whatever you have the rights for.

3) Sure

4) Only one MSI installation can run at one time. You have to spawn some child process to wait until the current installation is over.

5) Yes sure. The easiest way is to add an Upgrade table to your msi to simply uninstall any software which has this upgrade code. This is the only allowed action where two msis at the same time can be active. Look at the InstallExecute Sequence table for RemoveExistingProducts action.

Improve this answer

3 Comments

Re .NET 3.5/40. That's not true. You can compile the assembly for .NET 2.0/3.0/3.5 and tell it that 4.0 is a supported runtime. It's also not true what you said about the GAC. You can add files as references or content to your DTF custom action project and it'll all get uncompressed to the temp directory.
That can be true for Wix but not if you directly deploy e.g. a managed C++ assembly with an unmanaged entry point. The pure MSI logic knows nothing about .NET. It does extract your dll and execute the specified entry point and then does unload the dll after your custom action has executed.
You might want to read about WiX DTF. It solved all of these problems five years ago. blog.iswix.com/2008/05/…

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.