After a day or two of maintenance, the revamped MSDN subscriptions site appears to be up and running. One of the new downloads available is of course a full set of Visual Studio 2005 August CTP builds, including VSTO and VSS. And to complement that, WSE 3.0 Beta was also released a few days ago.
Also new: Enterprise Library for .NET 2.0 August CTP (built for VS2005 Beta 2). Read more here.
I installed not one, but two IM clients today. The first was MSN Messenger upgrade (7.5). Nothing radical here. Then I tried freshly baked Google Talk... Installation went smoothly and while installing, it detected existing installation of Gmail Notifier, unistalled it and replaced with new Google Talk client, also able to check my gmail. A fair trade... :)
Like the name suggests, Google Talk looks as it's primarily meant for voice conversation, although chatting works well too. Not much fancy stuff, basic iconography, but smileys are recognized and there are some neat text tricks like *emphasizing* text. The one thing that bugs me is the need to build another contact list. I'm using MSN Messenger, Skype, and now Google Talk, each with separate contact list. Also, currently Google Talk requires gmail account to use it, but that's going to change. All in all, a nice start.
On a side note: congratulations to Peter, for winning the C9 contest with this Outlook 2003 plugin! Way to go, man!
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…
This is the first post in a new environment. You can access my old blog through this address. I'll redirect my RSS feed to the new blog in a day or two..