Whidbey and Yukon names and dates tighten up

So I've heard that Yukon (Sql Server) and Whidbey (.NET 2.0?) are being now committed for “the first half of 2005”.

Furthermore, it can be confirmed that the names Sql Server 2005 and Visual Studio 2005 are the official names. Officially, I believe this is a 6 month slip. http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx. That's not too bad in the grand scheme of things...and of course, we all want to wait as long as it takes to get it right.

ADO.NET rant

Why is SqlDbType in the System.Data namespace when all the other provider specific types are in their own specific provider namespace? There is definitely some ugliness going on here. I'm not sure it's entirely a mistake.

As an aside, why is it SqlDbType and not SqlType? I can understand why OleDbType is named the way it is, but OracleType and OdbcType seemed to be named appropriately. Maybe it has something to do with the fact there is a System.Data.SqlTypes namespace and that would be just too close for comfort in the naming. Ok, so why isn't there an OdbcTypes namespace or any other types namespace for that matter? And shouldn't System.Data.SqlTypes be under System.Data.SqlClient.SqlTypes?

So what's the deal with IDataParameter and it's descendent IDbDataParameter? All of the typed provider parameter implementations implement both of these. Shouldn't they be collapsed into one? Even the IDbCommand.CreateParameter method has to return a IDbDataParameter. Furthermore, the online help for IDbDataParameter says it includes stuff for mapping to dataset columns. That's odd because the only 3 members of IDbDataParameter are Precision, Scale and Size. I'm pretty sure none of those having anything to do with Datasets. In fact, it's IDataParameter that provides this mapping in the SourceColumn member. Sheesh

Talk about your inconsistencies. It's still in WinFx from what I can tell. Please someone tell me there is a reason for this madness.

 

TVBUG Presentation on SOA Design - Mar 05, 2004 - Toronto - -15

Currently, the big architectural push is towards a service-oriented architecture (SOA). While the term sounds impressive, it is important to understand both what SOA is and how it can benefit a development team. In this presentation Bruce covers not only what SOA is, but how to design service-based applications using technologies that are currently available. And, as important, Bruce also covers how to make sure that your implementation can more easily take advantage of the new technologies that will be available with Indigo and Whidbey. For more information on the time and location, check out the Toronto Visual Basic User Group website

Takeaways from this session:

- What SOA is and how it compares to object-oriented development techniques. - How to design applications to take advantage of SOA. - A description of the technologies that can be used to build SOA applications right now.

Design by Blog

http://jroller.com/page/scotartt/20040216

I'd like to add to this new methodology...

  • "Programming by Googling" or "Progoogling"©

I also think that “Consensus Architecture“ can be automated on a world-wide basis by using the google api.

©Copyright Barry Gervin, 2004 - All rights reserved.

Visual Studio Command Prompt

This is a trick I got from Paul Murphy at the Toronto Security Briefing. Which was very good by the way, I thought Paul did a great job. If you missed it and would like to see the slides and demos. Visit Paul's Blog he posted them last night. http://www.paul.bz/blog.aspx.

Back to the tip. You would think after a Security briefing my tip would be about security. But to be honest I need time to digest some of the tons of information presented.

This is a really simple little thing I knew how to do but never thought to do it.

As a .NET developer it is inevitable that you will be opening the Visual Studio Command prompt to run some command line utility. Weather it's Sn.exe or GacUtil.exe or one of the many other utilities you can run from the command line. It is suggested (with good reason) that you develop logged in as a regular user, not administrator. If you are developing as administrator there is a good chance when the application is run by a non administrator there will be code that will not run due to the difference in permissions between the two accounts.

Wouldn't it be nice if the Command prompt looked different when you opened it as administrator. So you know visually right away that you are in that session as an administrator.

Here is how to do it:

  • Open the Visual Studio Command Prompt
  • Click on the Command Prompt icon (Control Box) and select properties
  • Click the advanced button
  • Select Run with different credentials (When opening a command prompt you will no be prompted to log in as another user)
  • Click OK and then switch to the colors tabs.
  • Select another background colour for the command prompt. (You can change what ever you want about the command prompt as you visual cue)
  • When you click OK on the properties dialog you will be asked if you want to Apply changes to just this window or Modify the shortcut that started this window. Select the second option.

From now on when you open the Visual Studio Command Prompt as Administrator it will look different than the normal Command Prompt.

Thanks for the tip Paul.

Debunking Dataset Myth

Many people think that datasets are stored internally as XML. What most people need to know is that Datasets are serialized as XML (even when done binary) but that doesn't mean they are stored as XML internally - although we have no easy way of knowing, it's easy to take a look at the memory footprint of datasets compared to XmlDocuments.

I know that if datasets were stored as XML, then in theory, datasets should be larger since BeginLoadData/EndLoadData implies there are internal indexes maintained along with the data.

It's not easy to get the size of an object in memory, but here is my attempt.

long bytecount = System.GC.GetTotalMemory(true);
DataSet1 ds =
new DataSet1();
ds.EnforceConstraints =
false;
ds.Order_Details.BeginLoadData();
ds.Orders.BeginLoadData();
ds.ReadXml("c:\\test.xml");
bytecount = System.GC.GetTotalMemory(
true) - bytecount;
MessageBox.Show("Loaded - Waiting. Total K = " + (bytecount/1024).ToString());

long bytecount = System.GC.GetTotalMemory(true);
System.Xml.XmlDocument xmlDoc =
new System.Xml.XmlDocument();
xmlDoc.Load("c:\\test.xml");
bytecount = System.GC.GetTotalMemory(
true) - bytecount;
MessageBox.Show("Loaded - Waiting. Total K = " + (bytecount/1024).ToString());

I tried these examples with two different xml files - both storing orders & orderdetails out of the northwind database. The first example was the entire result set of both tables. The dataset memory size was approximately 607K. The XmlDocument was 1894K, over 3 times larger. On a second test, I used only 1 record in both the order and order details tables. The dataset in this case took 24K and the XmlDocument took 26K, a small difference.  You will notice that in my dataset example I have turned off index maintenance on the dataset by using BeginLoadData. Taking this code out resulted in a dataset of 669K, an increase of approximately 10%. An interesting note is that if you put in a BeginLoadData and EndLoadData, the net size of the dataset is only 661K. This would imply that leaving index maintenance on during loads is inefficient in memory usage.

The speed of loading from XML is a different story.  Because the XmlDocument delays (I'm assuming) the parsing of the XmlDocument, the time to load of the full dataset from an XML file is 1/3rd of the time to load the DataSet from XML. I would be careful in being too concerned about this. Loading a dataset from a relational source like a DataAdapter that involves no Xml parsing and is much faster.

If you load up Anakrino and take a look at how the Dataset stores it's data, each DataTable has a collection of columns, and each column is in fact a strongly type storage array. Each type of storage array has an appropriate private member array of the underlying value type (integer, string, etc.). The storage array also maintains a bit array that is used to keep track of which rows for that array are null. The bit array is always checked first before going to the typed storage array and returns either null or the default value. That's pretty tight.

The GAC Exposed

So you want to see what's in the Gac. Of course if you go to c:\windows\assembly in your explorer - you see a customized shell extension of the global assembly cache. If you want to see the actual files underneath, in the past I've always gone to the command prompt and dir myself into long file name oblivion.

To get rid of that shell extension, just add a new DisableCacheViewer registry entry (type DWORD) underneath the key HKLM\Software\Microsoft\Fusion and set the value to 1 and presto - it's gone. C:\windows\assembly has never looked so good. Of course, don't do this on your end users' machine as this is really just developer requirement to help figure out what's going on and what's really in the GAC.

If that doesn't help you debug your assembling binding problems - don't forget about FUSLOGVW.exe. But that's another blog entry for another day.

Presentation at TVBUG

For those of you in the greater Toronto area, I will be giving a presentation on Designing Service Oriented Architecture Based Applications at the Toronto Visual Basic Users Group meeting on March 16.  For more information, check out their web site at http://www.tvbug.com.

Mississauga .NET User Group: Whidbey/Longhorn drill down - Feb 19, 2004 - Toronto - -14

By now, you have seen some very exciting previews of the new .NET technologies! This session will drill down behind the scenes to give you a more in depth look. If you have not yet witnessed Whidbey and Longhorn in action, you must absolutely make the time to attend this event. This session will introduce some of the new features that will be available to developers in the next release of the Windows .NET Framework SDK and Visual Studio.NET code-named Whidbey. Additionally, time will be spend examining the new subsystems that are planned for the next major release of the Windows operating system, code-named Longhorn, including the Avalon presentation subsystem, WinFS, and Indigo.

Upstaged by Ballmer

So it would seem I'm upstaged by Steve Ballmer who is coming to town the same day as the CTTDNUG presentation I was making about Whidbey.  So in the interest of the greater good - my talk has been postponed until Mar 31.

The “Ballmer Developer Briefing” is mostly about Security...if that interests you?

What do you mean “IF” - of course that should matter to you. It should matter to everybody. Writing secure code isn't just about logging in you know. It's about keeping your code safe and more importantly your end users machines and data safe and not allowing your software to act as a gaping hole into their system or data be it through spoofing or SQL Injection Attacks. Writing code these days is more of a liability than it ever has and we all have to be responsible - so do yourself and the rest of the world a favour and brush up on your knowledge of security. Either that, or hire a good lawyer.

I'm so convinced this is a an important event (and sorry that I had to cancel my presentation) that ObjectSharp is co-sponsoring a bus for members of the CTTDNUG that will travel to Toronto from Kitchener and back. And for those of you no where near Kitchener? Did I mention that parking is free?

See you there.