October 20, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Implementing a Custom ConnectionString Installer for Setup

  • October 10, 2007
  • By Paul Kimmel
  • Send Email »
  • More Articles »

Inserting a Breakpoint for Debugging

First, if you write a custom action/installer, like all code, you will want to debug it. The key to debugging installers is to add this statement:

System.Diagnostics.Debugger.Break().

If you try attaching to a running install process—one way to debug a running process—Visual Studio seems incapable of breaking into the installer. However, with the Debugger.Break() call you will be prompted to attach an instance of Visual Studio.

Creating the DataLinksClass

The first few lines after the Debugger.Break statement create the DataLinksClass and ConnectionClass. The DataLinksClass represents the Data Link Properties dialog and the ConnectionClass will contain the connection string. The call to instance.PromptEdit displays the dialog.

Reading Context Parameters

The Context.Parameters dictionary lets you get values from the Setup process. You want the installation target directory and the name of the configuration file to modify. (You will set these when you define the setup project and custom action.)

If, for some reason, the config file can't be found, the code throws an exception that will roll back the install. You could, in practice, let the install continue because you could always set the connection string manually, too.

Using the ConfigurationManager to Overwrite the ConnectionString

The code wraps by using the ConfigurationManager.OpenExeConfiguration, reading the connection string section, and setting the connection string dynamically. The call to GetAdjustedConnectionString strips out the Provider, which you don't need.

Finally, you use the ConfigurationSection class and the ProtectSection method to encrypt the connection string before saving. .NET includes a provider statement to the config section and automatically "knows" how to unencrypt and encrypted config section. When finished, you save the changes.

Defining the Setup Project

Visual Studio defines a setup project template and includes a wizard. You can add the setup project by using the wizard. The wizard will include the application and the custom installer.

To add the custom action, follow these steps:

  1. Select the setup project.
  2. Click the View|Editor|Custom Actions menu.
  3. Right-click the install item and select add custom action.
  4. Pick the output from MyInstaller as the custom action.
  5. Press F4 to open the Properties window and, in the CustomActionData field, add the parameters your installer needs: /configFile="UsesConnection.exe"/targetDir="[TARGETDIR]\"

Figure 6 shows approximately what Visual Studio will look like after you complete the steps listed above. (Hint: Pay close attention to the use of quotes and slashes in the CustomActionData.)



Click here for a larger image.

Figure 6: The CustomActionData contains our context parameters, configFile and targetDir.

Run and Test

Finish up by running the install project by selecting the setup project and clicking the Project|Install menu item. After running the install, open the UsesConnection.exe.config file and you will see the encrypted connection string and the Rsa provider information. Run the deployed UsesConnection project, and you will see that the connection string works, implying clearly that .NET has unencrypted the string for you.

If you need some more help, check these supporting links:

Summary

MSBuild is powerful. The setup integration in .NET is sometimes a little confusing. However, when you figure out the Custom Actions and installer behaviors you can add just about any behavior you want. In ther example, you used an existing COM feature through Interop to define a connection string. You also used the .NET framework to encrypt the connection string. (This is a good idea in most cases, falling under the auspices of protecting secrets.)

I also including information on debug installers using Debugger.Break. Javascript uses debugger, most Visual Studio code can be debugged in the IDE, but installers need Debugger.Break. (It'd be nice if Microsoft homogenized debugging here too.) I hope with these elements combined, you will be able to create some cool install features for your applications. Enjoy!

About the Author

Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Look for his upcoming book LINQ Unleashed for C# from Sams. You may contact him for technology questions at pkimmel@softconcepts.com.

If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Glugnet has two groups, Glugnet in East Lansing and Glugnet-Flint (in Flint, of course) and some of the best sponsors (and some of the best companies) in the free world. If you are interested in attending, check out the www.glugnet.org web site for updates or contact me.

Copyright © 2007 by Paul T. Kimmel. All Rights Reserved.





Page 4 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel