Re: Microsoft Visual Studio Installer Projects 2022 Documentation

1 view

Skip to first unread message

Message has been deleted

Ardith Hoefel

unread,

Jul 17, 2024, 4:20:50 PM7/17/24

to pycrazzricdau

This is a plea from the author to stop trying to do this. This article is now over 9 years old and nowadays there are far, far, far better ways to create a customised windows installer. Even if your back is against the wall, like mine was 9 years ago, just say no to whoever suggested following this article and tell them even the author of the article thinks that this way only leads to madness.

microsoft visual studio installer projects 2022 documentation

Descargar Zip ->>> https://urluss.com/2yOLj5

Now if you want to read some crazy stuff that I did in 2007 and that really you can be too clever for your own good, please continue and read the article below but only for the purpose of your own enjoyment.

Over the years, I've started to become a bit of a build monkey, i.e. taking all the code produced by the developers and getting it to build using automated builds, running unit tests as part of the build and finally getting it to deploy and run on a machine that has not had a developer (or Visual Studio) near it. Plus, doing whatever development work comes my way as well. One of the things I have learned over time is that the person who knows most about how the code should work when running on another machine is the developer that wrote the code in the first place. So, how do we get the developers to tell us what we need to know? Let's examine the behaviour of 90% of developers and the environment that they work in.

1) Developers hate writing documentation. They will dodge the topic when raised and even, on some occasions, fix bugs in old VB code which have suddenly become urgent after many years of being blissfully ignored.

2) Buying new software on top of the initial Visual Studio purchase is a nightmare of justification and licensing. Justifying the purchase of installer software in case the setup needs something that can't be met with the built-in setup projects takes time and paperwork. Uh-oh, looks a bit like documentation and so it is avoided.

3) Some installer software tools resort to scripting languages to customise the install and do other actions. Most developers don't like script-based languages and, because some installer tools use a custom script language, it also means a new learning curve. So, calls for a specialist are made from developers and that new individual then has to deal with point 1 in order to get their work done. You could use free installer tools e.g. the WIX Toolset, but there are not many people out there that know this tool. Also, the learning curve is fairly steep, as you have to know a lot about installers to understand what is happening when it all goes wrong.

Because of the last item, point 2 is overcome due to the ability of developers to build and test the installer locally. They can also integrate it into their solution and use drag and drop to put files in all the right places. Should the install need a bit of customisation, we can use .NET Installer-based classes to modify our configuration files with information gathered from the simple dialogs. This solves the issues raised by points 1 and 3.

Okay, some installer zealots would say that the use of scripts and .NET Installer-classes is bad ju-ju and should be avoided. Instead we should all use proper custom actions, i.e. native DLLs. However, we live in the real world, folks, and we do what we can in the limited time given to us. The problem in going with point 4 is that it is usually at the end of the project when we discover we need that extra customisation. By then, it is too late to buy new tools and get to grips with them before the product is shipped.

There is very limited documentation about the installer dialogs. What does exist seems to be related to language globalization/customisation. However, what we learn is that the installer dialogs are in the folder %ProgramFiles%\Microsoft Visual Studio 8\Common7\Tools\Deployment\VsdDialogs and that these files can be edited using the Orca tool that ships as part of the Windows Installer SDK. By viewing the dialogs in those folders using the Orca tool, it is easy to determine which .wid file belongs to which entry in the Add Dialog screen in Visual Studio. Before we start editing these files it is recommended that a backup is made of these files.

This unique naming makes sense when you think that we could be adding them all into one installer or, as we can suspect, merged into one installer. This is why there may be a limited number of pre-made dialogs.

This looks like the information that is displayed in the Add Dialog section of Visual Studio. There is also an Attributes field here that I think is used to control when the dialogs appear. For example, all of the Admin dialogs have an attribute that is greater than or equal to 8192 -- i.e. the 13th bit is set -- whereas for normal dialogs it is the 12th bit. Certain dialogs only show up in web setup projects; 5th bit (or 7th bit in admin dialogs) is set. Other dialogs also have some unique setting. For instance, for both admin and normal dialogs the finished dialog has the 3rd bit set. We can therefore infer that the Attributes field is used to both control when the dialogs show up and perhaps control positioning in the UI. It would therefore make sense that if you make a new custom dialog for use in a similar situation as another dialog that already exists, then using the same attributes as that dialog would be the approach to take.

Looks like a mapping table of values from the Visual Studio environment; defined in ModuleConfiguration to the standard tables within the installer before or during the moment they are merged into one installer.

2) Open in Orca and change all occurrences of CustomTextA to CustomTextD in the Dialog, Control, ControlCondition and ControlEvent tables. See the Dialog, Condition, and Argument columns where applicable.

Start Visual Studio and see if it appears in the Add Dialog window of a set-up project. Nope. Hang on, maybe it is a bit more advanced than that. Perhaps it is trying to present the one in my default language in Visual Studio, which happens to be English (United States) and has a LCID of 1033. Make a copy in the VsdDialogs/1033 folder, changing the Language field in the ModuleSignature table to 1033 for good measure. Restart VisualStudio and have another look. Success!

But does it work and will it play nicely with the other dialogs? We can only hope that the developers of this bit of Visual Studio do not care what dialogs are available so long as we keep to that same pattern (naming conventions and suchlike). Let's create a test project, add all four of our text box dialogs, play with a few settings, shuffle the order, compile and test. It's looking good. Add a quick and dirty CA to display a few properties. Another success. So now we know how to make a copy of an existing dialog and we can easily repeat that process should the need arise.

2) Adding a new radio button is relatively simple in that we only need to update the RadioButton table. Using Orca, we can copy and paste a row and then edit that row such that its order is 5 and it has a Y-value of 96. NOTE: we need to make sure that the containing control in the Control table is also big enough.

4) Using Orca, edit the ModuleConfiguration table so that we can manage the Label and Value of our new button in Visual Studio. Let's duplicate rows Button4Label and Button4Value to make Button5Label and Button5Value, respectively. The fields with the hashes (#) look like they may be referring to resource text strings; we can hopefully ignore them for now.

5) Again using Orca, edit the ModuleSubstitution table to add 3 new rows that will set the Property, Text and Value properties of our new radio button. You will have to change the Row field to BUTTON5;5 before you can change the Table field back to RadioButton.

Restart Visual Studio and open up the test set-up project. A partial success, it seems we can add the new dialog and we can see 5 radio buttons when we run the installer. However, the properties for the fifth button don't seem to be appearing in the Properties window of Visual Studio. What about the # values? Could the problem be that the code uses them to generate the descriptors when building the collection for the property grid and thus may filter out duplicates? Let's edit the ModuleConfiguration table and the changed the fields with # values in them to what we want to display. Hopefully the developers at Microsoft have written the code such that if it did not find the resource it would fall back and display what it sees instead. Save to disk, make a copy in the VsdDialogs/1033 folder, restart Visual Studio and try again. Success!

New 5 radio button dialog: notice that the description is for the 4 radio button dialog. Originally I didn't know where this description entry was, but thanks to a tip from Grump we now know that the information can be edited using Orca under the View Summary Information menu option.

We can also see that this dialog has a GUID as a package code and that when we investigate the original dialogs, the value of this GUID matches the GUID in the ModuleSignature table. It does not appear that this GUID as edited by this dialog has any effect on the creation of installers, but we will maintain the mapping just in case.

The figure above displays the property grid, showing the extra properties and the hard-coded labels. Now we know how to add new controls and extend the configuration of the dialogs that we can add to our installers.

A few of the controls on the dialog can be managed via the existing tables, e.g. enabling buttons. But if we want a finer control, we may need to resort to a custom action (CA). For this example, we'll create an update/upgrade to the License Agreement dialog screen. We'll incorporate a custom action that will check that the user has made an attempt to read the licence by checking that the window has been scrolled to the bottom. When this has happened, a property called LicenseViewed will be created and set to "1." NOTE: I am using a version of the IsLicenceViewed CA by Kallely L. Sajan, found here. I have only made a slight modification to the CA such that it gets the name of the required window from a property within the installer, i.e. make it more generic.