CODEWITHSUNDEEP
windows-installer
Patrick
Patrick

Reputation: 1837

Why would you add custom tables to an MSI?

I'm just wondering what the use for this feature is, since MSIEXEC probably wouldn't even know it is there. Is there some Custom Actions code that could access them, perhaps?

Upvotes: 2

Views: 821

Answers (2)

Stein Åsmul
Stein Åsmul

Reputation: 42186

As Chris Painter states MSI files are transparent in the sense that you can see what is going to happen during the install based on the content of the MSI tables. This is one of the key benefits of MSI that you can find described here. Custom tables extend this built-in transparency to include custom actions fed by the actions specified in them. They also allows re-use of custom action code since the actions aren't hard coded, but specified in tables.

Whilst working in a large corporation I wrote a custom action DLL capable of doing several non-standard MSI tasks such as create local users and groups, create shares and set custom permissions among other things. By defining what should be done in custom tables, we could accomplish what we needed to do without hard coding anything in custom actions. Once created the custom actions for user creation could create any user specified in the custom table.

The custom tables are defined in the _Validation table in order to set acceptable value ranges and types for each column in the table. It is also possible to hook up custom ICE validation rules to detect errors in the custom tables. Custom actions requiring to resolve directories can add a foreign key from the custom table into the Directory table to be able to resolve the installation directory. You can also add foreign keys to other tables, including other custom tables.

In short custom tables are used by custom actions and are extremely effective when used to achieve flexibility and reuse of your custom actions. However, the implementation is a major effort. The WiX toolkit uses a number of custom tables to accomplish non-standard MSI tasks such as IIS installations. Their source code is open source and will show you how to write custom actions fed by custom tables. It involves quite a bit of hairy MSI technology such as sequencing and passing values from client to server process (elevated, deferred mode custom actions), but all of this should be possible to "borrow" from WiX - or better yet, use WiX's own ready-made custom actions.

If you have the skills to create this, I think it would be hugely beneficial to share your creation with the WiS community. This will also give you a bunch of highly talented developers to help you track down any bugs in your code and implementation.

Upvotes: 2

Christopher Painter
Christopher Painter

Reputation: 55601

The point is to write your custom actions to behave in a way similar to the standard actions. The action(s) and the table(s) define a pattern where the action performs the work and the table(s) define the work to be done. This is the heart of declarative, data driven programming. The opposite is when you tightly couple the two together in an imperative approach.

Suggested reading material:

Zataoca: Custom actions should be data driven.

Data Driven Managed Custom Actions made easy with DTF

Upvotes: 4

Related Questions