Chapter 27
The third command encrypts the connectionStrings section of the configuration file for the web application StagingWebsite. Other sections of the configuration file can also be encrypted using the same command. If at some later stage you need to decrypt the configuration section, execute the same command, but with –pd instead of –pe. For example:
aspnet_regiis -pd “connectionStrings” -app “/StagingWebsite”
Summar y
This chapter showed you how to use Visual Studio 2005 to take charge of your application and configure it to connect to a database using a connection string. With the built-in support of the data classes in the
.NET Framework, connection strings can be dynamically created and modified so you never have to handcraft a connection string again.
Upcoming chapters continue the data access story, as you learn how to work with strongly typed datasets and a raft of new data controls.
Assembly Signing
When you create your .NET projects, they compile down to an assembly. By default, this assembly is open and doesn’t have any security on it to ensure that your users are consuming the correct version of the binary file. However, signing your assembly can rectify that issue by providing a strong name to the compiled application or component, which can then uniquely identify it to other applications and even system administrators who can apply a security policy against it.
Before you take a look at how to sign your solution’s output, you need to understand a couple of concepts — namely, strong-named assemblies and the Global Assembly Cache.
Strong-Named Assemblies
A strong name consists of the parts that uniquely identify an assembly’s identity. This includes the plain-text name and a version number. Added to these elements are a public key and a digital signature. These are generated with a corresponding private key. Because of this private/public key system coupled with a digital signature, strong names can be relied on to be completely unique.
Using a strong name can also ensure that the version of your assembly is the one that has been shipped. No modification can be made to it without affecting its signature and thus breaking its compatibility with the generated strong name.
As mentioned previously, using strong names also gives administrators the ability to explicitly set security policy against your solutions by referring to their unique names. This can give a corporation confidence that once deployed, the software will run as expected because it cannot be tampered with without affecting the signing of the strong name.
Once you start using strong-named assemblies in your solution, you will have to use strongnamed files right down the chain of references because allowing an unsigned assembly as part of the chain would break the very security that strong-naming your assembly was intended to implement.
Chapter 28
The Global Assembly Cache
If you’ve been programming with .NET for a while, you’re already familiar with the Global Assembly Cache, but if you’re new to the world of .NET this might be a new concept. Every computer that has the
.NET Framework installed has a systemwide cache that stores all assemblies that are to be shared by multiple applications.
In this cache (usually stored in a folder within the Windows directory) you’ll find the common language runtime components as well as other globally registered binary files that you, and anyone else, can consume. If an assembly is only going to be used by a single application, then it should be deployed in that application’s folder.
However, if you are going to share the assembly between applications and want to store it in this Global Assembly Cache (known as the GAC), then your assembly must be strong-named. You don’t have a choice in the matter, because the cache interrogates all files to ensure that their integrity is valid; hence, it needs the strong-name versioning to compare against.
Signing an Assembly in VS 2005
Previously, signing an assembly in Visual Studio required the generation of a strong-name key (.snk) file via an external utility and then editing the assembly attributes of your application’s configuration file. Thankfully, Visual Studio 2005 changes all that for managed code projects by introducing an additional page in the Project Designer specifically for signing the output of your project.
The Signing tab (see Figure 28-1) enables you to sign the assembly in the lower half of the page. You first should select the Sign the Assembly checkbox to indicate that you will be generating a strong name. You will then need to select the strong name key file to use when signing the assembly.
Assembly Signing
Sometimes you won’t have access to the private key to successfully sign the assembly. When you’re in this situation, you can still dictate that the application will ultimately be digitally signed, but also select the Delay Sign Only option as well.
While you are deferring the signing process, you won’t be able to debug or even run the application, but you can at least build it to be ready for the signing phase.
Existing key files in either the older .snk paired key file format or the new .pfx format can be used. From the drop-down list, select the Browse option to locate the file in your file system and click OK in the dialog to save the key file to the Signing page settings.
Alternatively, you can create a new strong-named key by selecting the New option from the drop-down list. When you choose New, you will be able to create a new .pfx formatted strong-named file. Figure 28-2 shows the Create Strong Name Key dialog. You can simply choose a filename to use for the key or additionally protect the key file with a password.
Figure 28-2
Either way, once you’ve created and selected the .pfx file, it will be added to your project in the Solution Explorer, enabling you to easily include it for deployment projects.
Summar y
Strong-naming your application and thus safeguarding it from improper use is now straightforward to implement, and can be done completely from within the Visual Studio 2005 IDE. The Signing page gives you the ability to both create and set the key file without having to edit the application’s assembly attributes directly.
Preemptive Error Correction
It’s obviously a good idea to deal with errors as soon as they pop up in your program code. Unfortunately, some issues don’t show up at design time in an obvious way that you can deal with because they’re marked as only warnings, while other issues aren’t even marked up as such by default. In this chapter, you’ll learn how to customize your compilation experience so you can deal with issues before getting too far into the development cycle. You’ll also learn how Visual Studio 2005 tries to help you when you encounter certain types of errors by prompting you with suggested solutions.
Smar t Compile Auto Correction
Chapter 18 briefly touched on a feature of Visual Studio 2005 that offered error correction via smart tags. The full name for this feature is Smart Compile Auto Correction, and it is available to both Visual Basic and C# developers as they write the program code for an application.
As you write your code, Visual Studio 2005 continuously performs a background compilation of the program logic to look for errors. As errors occur, the IntelliSense engine marks up the code with different types of messages and errors so you’re made aware of them.
Some detected errors have a set of easily implemented solutions. With these errors, the Visual Studio IDE determines the possible answers for the given issue that could be added to the program code and presents you with a list from which to choose.
It does this with the Smart Compile Auto Correction feature of IntelliSense, adding an extra visual indicator to the end of the compilation error in question. This small glyph — by default, a small yellow and maroon line drawn underneath the last character of the statement in error — can be used to access the Error Correction Options smart tag dialog.
Hovering your mouse pointer over this indicator displays the smart tag button. When clicked, the Error Correction Options dialog will appear, enabling you to select the desired solution. Figure 29-1 shows a typical error that falls into the category of easily correctable.
Figure 29-1
In this case, an object was defined of a type that doesn’t exist or is not immediately known to the program in its current context. Visual Studio 2005 first background-compiles the statement and determines that it is in error. Using its normal behavior, it first provides feedback by marking up the section of the statement in error with the wavy underline (blue by default).
Visual Studio 2005 then checks to see whether the error is in its list of easily rectified issues. When it finds that undefined object types often have easy fixes, it paints the additional glyph at the end of the statement (which is hidden in Figure 29-1 by the smart tag button).
Typically, placing your mouse pointer over a statement that has been marked as an error results in a tooltip displaying a summary of the problem. In this example, the tooltip indicates that the Type ‘XmlDocument’ is not defined and must be of a known type. Errors that fall under the purview of the Smart Compile Auto Correction feature display an additional button to access the smart tag.
In Visual Basic, this button consists of an icon with an exclamation mark and a down arrow. In addition, as you can see in Figure 29-1, it displays a tooltip containing the Error Correction Options text and the assigned keyboard shortcut for the feature.
Opening the smart tag dialog displays the error message along with suggestions for how to fix it. Figure 29-2 shows the result of opening the smart tag dialog for the undefined XmlDocument object type. The dialog repeats the error text and offers four possible solutions to the error.
Figure 29-2
As you can see in this example, Visual Studio tries to guess what you meant when you wrote the code, so it not only provides a fully specified Xml.XmlDocument object definition, but also the HtmlDocument object type that doesn’t need to be qualified.
To implement a particular solution, click its corresponding link in the list. Doing so applies the fix to the code (as the tooltip will inform you), performing whatever actions are necessary to correct it.
Preemptive Error Correction
In some cases, the suggested fix might need further explanation than a simple one-line description. In these situations, the smart tag dialog extends to include a preview pane for each possible solution it has found. These preview panes can be expanded and collapsed as needed, with an option at the bottom of the dialog window to Expand All Previews simultaneously (see Figure 29-3).
Figure 29-3
Figure 29-3 shows a compilation error and a pre-defined solution available for it. Because the For loop requires a matching Next statement to close the block of code that will be looped, IntelliSense marks it up as a compilation error. However, the problem has a straightforward solution — to insert the corresponding Next statement, so the Smart Compile Auto Correction feature displays the smart tag dialog.
In this case, the solution is displayed with a preview of what will happen if you select the particular option, enabling you to confirm what actions will be taken before they occur, and implement your own solution if the suggestion is incorrect.
C# developers will have a slightly different experience with the Smart Compile Auto Correction feature because of the way errors are displayed when working in the code. Because errors are not normally marked up through the background compilation process, C# programmers may not even realize that they have coded an error in the program logic.
Despite this, Visual Studio 2005 still identifies certain easily correctable errors and marks them up with the error correction smart tag visual indicator. Placing your mouse pointer over this indicator displays the C# version of the smart tag button, as shown in Figure 29-4.
Figure 29-4
In this case, the tooltip that accompanies the smart tag is modified to include more meaningful information about what actions can be performed. As this sample implies, the suggested solutions are not necessarily marked as error corrections, but instead are portrayed as helper functions.
Chapter 29
What’s interesting is that the two languages have different sets of problem statements that can be rectified, and even different lists of corrections that can be implemented to fix an issue. The example shown in Figure 29-4 is the C# equivalent of the Visual Basic example shown earlier, with a variable defined as the XmlDocument object type without fully qualifying it in the code. However, in the case of C# code, only two suggestions are made, as displayed in Figure 29-5.
Figure 29-5
These suggestions accurately reflect the typical responses that a C# developer might take, and assume that the programmer knew what object was wanted. Note that the first suggestion is to add a using statement at the top of the program logic. Because the solution involves inserting code in another part of the program, an additional icon is displayed next to the link.
Customizing Warnings in Visual Basic
Although Smart Compile Auto Correction is an incredibly useful feature of Visual Studio 2005 that bolsters the value of using the IDE in addition to the valuable information provided by other aspects of IntelliSense, you may not be aware that some warnings are more important than others. In fact, some commonly encountered situations in code are overlooked by default, leaving you without a clue as to why your program might be failing.
It all comes down to the warning levels of your program, and what situations are considered warnings or errors. To customize the way warnings are dealt with in a specific project, open the My Project page for the project. You can do this by either right-clicking the project’s entry in the Solution Explorer and choosing the Properties command, double-clicking the My Project entry in the Solution Explorer, or executing the Project Project Name Properties menu command.
The warning settings are all accessible from the Compile page of My Project, as shown in Figure 29-6.
The first settings to look at are the compile options. By default, Option Explicit is turned on, requiring you to explicitly define any variables that you use in your program code. However, Option Strict is turned off. Option Strict forces you to properly convert variables of one type to another, rather than let the compilation engine implicitly convert them for you.
Because this can cause a large number of errors you may not want to deal with (it will even report the conversion of an Integer to a String as an error), the option is turned off by default. For commercial applications, it’s worth turning the option on and reviewing the errors that are generated with the setting enabled.
Preemptive Error Correction
Figure 29-6
When using Option Strict, the Smart Compile Auto Correction feature is activated for any implicit conversions you might have in your code, giving you quick access to the correct conversion statement required for the situation. For example, the following code would be fine with Option Strict off, but will generate a compilation error for each line when Option Strict is active:
Dim myDocObject As Object = New Xml.XmlDocument Dim myDoc As Xml.XmlDocument
myDoc = myDocObject
Dim myString As String
Dim myInteger As Integer = 3 myString = myInteger
Using the Smart Compile Auto Correction feature, with a couple of mouse clicks this code is converted to properly coded type conversions. The assignment statements for the myDoc and myString variables are flagged as errors that have possible solutions. Using the Smart Compile Auto Correction links that are added to these errors, you can select from the suggestions, which results in the following code block:
Dim myDocObject As Object = New Xml.XmlDocument Dim myDoc As Xml.XmlDocument
myDoc = CType(myDocObject, Xml.XmlDocument)
Dim myString As String
Dim myInteger As Integer = 3 myString = CStr(myInteger)
