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
("220.127.116.11"), since strings containing numeric values still compare (and
sort, for that matter) like strings. For example:
string s9 = "18.104.22.168";
string s10 = "22.214.171.124";
string s11 = "126.96.36.199";
Console.WriteLine(string.Compare(s11, s10) > 0);
Console.WriteLine(string.Compare(s10, s9) > 0);
The first WriteLine statement would write "True", since strings
"188.8.131.52" and "184.108.40.206" 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 "220.127.116.11" is less than
"18.104.22.168". 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("22.214.171.124");
Version v10 = new Version("126.96.36.199");
Version v11 = new Version("188.8.131.52");
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.
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.
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…
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.
Visual Studio Tools for Office 2005 (VSTO) family is getting bigger: after initial Word and Excel support and InfoPath refresh (available for MSDN subscribers), now there's Visual Studio 2005 Tools for Office Outlook (Beta)
, allowing developers to write Outlook Add-ins in managed code.
The following files from my NTK2005
talk/lab are ready for download:Visual Studio Tools for Office 2005PowerPoint slidesClickOnce Lab
PowerPoint slidesDemo codeHands-On-Lab manual
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.
First Visual Studio 2005 Beta 2 bits are available for MSDN subscribers to download. I guess april 15th wasn't such a bad guess after all. The real experience
begins in a week... ;)