Andrej Tozon's blog

In the Attic


Versioning with Version class

Sometimes you need to provide versioning functionality for your custom data, databases, etc. For handling version information inside your application you can use data types like string or int, or go with the Version class, which you commonly use when managing application and assembly versions.
When implementing custom versioning, which strongly depended on version comparison, I first had some doubts about using Version class for that. But this was mainly because of its serialized representation as a string (""), since strings containing numeric values still compare (and sort, for that matter) like strings. For example:

string s9 = "";
string s10 = "";
string s11 = "";

Console.WriteLine(string.Compare(s11, s10) > 0);
Console.WriteLine(string.Compare(s10, s9) > 0);

The first WriteLine statement would write "True", since strings "" and "" are equal in length and the latter is obviously greater than the first one. But when comparing the second pair, the result would be "False", like "" is less than "". That's because string comparison is made on a character base, not numeric. And character '9' in 7th position of s9 string evaluates as greater than '1' in the same position of the second one. The last zero in s10 just doesn't make any difference.

So I tried Version:

Version v9 = new Version("");
Version v10 = new Version("");
Version v11 = new Version("");

Console.WriteLine(v11 > v10);
Console.WriteLine(v10 > v9);

Version class comparison works as expected and both statements would write out the value of True.

The point here would be - don't judge objects for their serialized look.

Parsing dates

A rediscovered oldie: when dealing with some old, legacy code, you could find yourself wrestling with very oddly formatted data. One of the more common types the .NET framework can easily help you with, are the date/time values. For example, to convert string value of "890712" to a proper date, simply use

DateTime date = DateTime.ParseExact("890712", "yyMMdd", null)

which would result in 12.7.1989 or 7/12/1989.

ConnectionString builders

Implementing database login functionality in your application usually requires you to build your database connection string in code. There are many ways to do that, and new classes in .NET Framework 2.0 (or better - ADO.NET) adds another one.

ADO.NET introduces a new class to build your database connection strings: DBConnectionStringBuilder, which serves as a base class for other, strongly typed builders, like SqlConnectionStringBuilder, OleDBConnectionStringBuilder,  and others - even OracleConnectionStringBuilder. While DBConnectionStringBuilder operates in in key/value mode - you can set any connection string property using string values:

.Add("Data Source", "ServerName") -

strongly typed builders help you build your connection string for your database using specific properties. For example, you could build the SqlServer connection string using the code like this:

string username = "Username";
string password = "Password";
SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
builder.DataSource = "SqlServerName";
builder.InitialCatalog = "Database";
builder.UserID = username;
builder.Password = password;
builder.IntegratedSecurity = (user.Length + password.Length == 0);
builder.ApplicationName = Application.ProductName;
string connectionString = builder.ConnectionString;

It also works backwards - setting the ConnectionString property also initializes all other properties which you can later inspect for additional information. Using the following code, for example:

string connectionString = "Data Source=SqlServerName;Initial Catalog=Database;User Id=Username;Password=Password";
SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(connectionString);
bool allowAsync = builder.AsynchronousProcessing;
bool supportMARS = builder.MultipleActiveResultSets;

we find out that MARS is enabled by default, and asynchronous execution is turned off.

ConnectionString builders present a useful addition to the ADO.NET classes. Time to update some old code again…

TableAdapters & connection strings in VS2005

When you create a new TableAdapter for your DataSet using Configuration Wizard, VS kindly generates new code file for you and adds the specified connection string to application settings. The problem is that connection string also gets included in the auto generated code file and consequently embedded into compiled assembly, which may result in "unexpected behavior" in production environment, like application trying to connect to the wrong server and stuff... Not to mention potential security risks...
To turn this behavior off and store your connection string to configuration file only, select (Connection string) setting in your project's Settings page and switch its GenerateDefaultValueInCode property to false.

Microsoft NTK2005 conference, Portoroz

I'm back from the 10th NT conference, held in Portoroz, Slovenia, where I gave a talk about Visual Studio Tools for office 2005 and had a lab on deploying applications using ClickOnce. I will post PowerPoint presentations and demos on this site in a few days. If you have a question about using these new exciting tools and technology, you're more than welcome to post a comment here or email me.

Patterns & Practices Enterprise Library

If you ever used any of the Microsoft Application blocks  in your application, you'll love the Enterprise Library, released by Microsoft Patterns and Practices group. The library is composed of seven application blocks, all extendable, designed to work together and, what's best, very easy configurable with new  Enterprise Library Configuration Console.

The library includes QuickStart samples (C# and VB.NET), application blocks' source code (with unit tests).

Excellent stuff. Go get it!