VS 2005 Debugger Features

Visual Studio 2005 Beta 1 is released at last! Previously known as Whidbey (and internally it will forever known as Whidbey, as 7.1 is forever Everett, as 7.0 is, er, 7.0) this beta is going to be available to MSDN Universal subscribers, and some other ways too (see later).

VS 2005 Debugger Features

New DataTips. Remember back to Visual C++ 4.0 (I think) that first brought you DataTips? Well think of those same tips, but on crack, and you get New Datatips. You can inspect whole objects in the datatips now, kind of a floating Watch window. It is the most important improvement to the debugger since, well, since VC2 really.
Tracepoints. A tracepoint is a breakpoint that doesn’t stop. Well instead of stopping, they print messages. Anything you like, including text, variables, stack traces, anything you like really. They are a great way to add logging to code without having to rebuild a thing.

Source file checksums. Ever got the debugger confused by having two different source files with the same name but in different paths? We have, and lots of other people too (especially default.aspx). The confusion is over: the C++, C# and VB compilers now emit a checksum of the source file into the debug info, so the debugger can tell if it got the right version or not. This makes breakpoints bind to the right source file even in the case of multiple matching basenames, something that has troubled us (and users) forever. (Note that checksums are not generated for ASP.NET compiles in beta 1).

Visualizers. Using a complex managed type that is ugly to view in the Watch window (e.g. DataSet)? Now you can either use a built-in Visualizer, or write your own. For DataSet you see the data in a proper grid control, for example. You can view long strings in a text editor, or an XML viewer if you like. If you want to write your own Visualizer for your type, or a Frameworks type, go right ahead. It just takes a bit of C#.
STL Data Display. STL types have always been a challenge for the debugger. In VC6 the debug format truncated the managled names at 255 bytes so you often couldn’t even manually look at the structure of some STL objects. This is fixed in 7.0, but ugly data structures are still ugly even if you can see more of them. VS Whidbey has a meta-language that lets you define exactly how to display complex types and includes support for all the common STL types. A hash table displays as an array in the debugger now, instead of that ugly thing it really is.
64-bit Support. Both native and managed debuggers support AMD64 and IA64 debugging now, with good feature parity with 32-bit, though no Edit & Continue or Mixed debugging.

Storing and Reading Base64 Encoded Connection String in Web.Config
Introduction
Many people store database connection string in web.config file. However, web.config file being an XML file, the data stored there is in clear text format. This is especially important for connection strings because anybody can easily see your database details including user id and password. In this article we will see how you can encrypt values stored in web.config using Base64 encoding and later on decrypt them in your code. Note that Base64 encoding is not a secure algorithm but it is a quick and easy way to hide the connection string details from casual readers.
Storing custom values in web.config
You store custom configuration values in web.config using section. The section looks like this:
<appSettings>
<add key="connectionstring"
value="data source=.\vsdotnet;initial
catalog=Northwind;user id=sa;password=mypassword"/>
</appSettings>
In short you store key-value pairs inside the section.
Encrypting connection string
In order to encrypt above connection string we will be using System.Convert class. We will build a small console application that allows us to pass plain connection string as command line argument and then displays encrypted version on the console.
The code looks like this:

Public Shared Sub Main(args() As String)
Dim data() As Byte = System.Text.ASCIIEncoding.ASCII.GetBytes(args(0))
Dim str As String = Convert.ToBase64String(data)
Console.WriteLine(str)
End Sub
Here, we are using System.Text.ASCIIEncoding.ASCII class to convert the connection string to an array of bytes. This is necessary because the Convert class function ToBase64String() expects array of bytes and then returns Base64 encoded version of it.
You can invoke above application (I created it as Base64Encrypter.exe) at command prompt like this:

Base64Encrypter.exe "data source=.\vsdotnet;initial catalog=Northwind;user id=sa;password=mypassword"
The output will be:
ZGF0YSBzb3VyY2U9Llx2c2RvdG5ldDtpbml0aWFsIGNhdGFsb2c9Tm9ydGh3aW5kO3VzZXIgaWQ9c2E7
cGFzc3dvcmQ9bXlwYXNzd29yZA==

You can now copy-paste this encoded version of the connection string in the web.config. The new appSettings section will look like this:
<appSettings>
<add key="connectionstring" value="ZGF0YSBzb3VyY2U9Llx2c2RvdG5ldDtpbml0aWFsIGNhdGFsb2c9Tm9ydGh3aW5kO3VzZXIgaWQ9c2E7
cGFzc3dvcmQ9bXlwYXNzd29yZA=="/>
</appSettings>

Reading the encrypted connection string back

Now, let us see how we can read the encrypted connection string and decrypt it so that we can use it further.


Dim data() As Byte = Convert.FromBase64String
(ConfigurationSettings.AppSettings("connectionstring"))
str = System.Text.ASCIIEncoding.ASCII.GetString(data)


Here, we again used the Convert class and called its FromBase64String function. This function accepts Base64 encoded string and returns a byte array. In order to retrieve the appSetting value we used ConfigurationSettings class as shown above. Finally, we used ASCII class again to convert the byte array to a string.