Downtown Metro Toronto .NET UG Inaugural Meeting!

Finally a downtown user group.  First week of every month - and the first one is April 1st - no fooling..at 200 Bloor St. East (Manulife) at Jarvis. This is also the first date on the MSDN Canada .NET User Group Tour across Canada. There is also a raffle for an XBox.

The sad news is that this meeting is going to get cut off at the first 200 people - so register soon by sending an email to GrahamMarko@rogers.com.

http://www.metrotorontoug.com/

speaker: Adam Gallant
location: Manulife Financial Building 1st Floor 200 Bloor Street East Toronto

Better Web Development

In this session, we will focus on some fundamentals in web development, including a special drill-down on security and caching. We will cover an overview of the .NET security, and specifically important aspects in ASP.NET security and best practices. We will also cover, at a high-level, the caching mechanisms used by ASP.NET.

Security for Developers

Why is that you can't plug a fridge into your house until it's been CSA or FCC approved, and that you have to have a licensed electrician install or at least review any modifications to the wiring in your house plugged into the grid - but any yahoo can build a piece of software and install it on their home computer connected to the internet for the world to hack into? Before I make a case that developers should be forced to do some security training or pass some certification....we have to keep in mind that most of the time the software sitting on somebody's home computer that is getting hacked into is Microsoft's. This is largely due to the size of the huge target on their back. What you think Linux is really more secure? What do you think is easier to hack into? It's easier to hack into something when you have the source code.

So, having said all that, there are changes coming for Microsoft developers in the security space:

  • Microsoft is turfing a few of the existing security training offerings. These include the Microsoft Security Clinic (2800) and Security Seminar for Developers (2805).
  • There is a new security course being developed: Developing Secure Applications (2840) and also a MS Press Training Kit both of which I'll be reviewing during their development.
  • Related to the new course and training kit, there is a new security exam for developer which unfortunately because of timing is only an MCAD/MCSD/MCDBA elective (not a required element - sigh). There are 2 versions - 1 for VB and 1 for C#. I guess they figure C++ and J# developers already write secure code. These are going into beta at the end of next month and I'll be auditing the C# version.
    71-330 Implementing Security for Applications with Visual Basic .NET
    71-340 Implementing Security for Applications with Visual C# .NET

I'm a little torn over this direction. Part of me says that security is so important, it needs to be covered in every MS Training course. To a certain extent that is already true, but I think they could go deeper. When I teach a windows, web or services course, I try to go deep on security. Sometimes you can go to far. Some pieces of security are more relevant to the type of application you are building, while other security issues are common regardless of the application architecture. Obviously we don't want to repeat a lot of content in each course - sometimes that is unavoidable. The other issue is that there is a lot to know about security and frankly I don't think every developer can master all of this. So teams need to dedicate a security architecture role on their project. For these folks - then yes I think it makes sense to have specific and deep training and certification for them. I think MS could probably do better than a single exam “elective”. How about an MCSD.NET+Security designation? MCDBA+Security as well - although you could argue that MCDBA's should be forced to have this security. Perhaps that will happen in the wake of Yukon - although I've heard no rumblings of creating Whidbey or Yukon flavours of exams or certifications at this point.

Our industry and profession needs to take a leadership role and be proactive in accepting responsibility and accountability for the important issue of security. We need to move our discipline to a higher level. I'm not convinced it has to be government that steps up to this place. Governments should only do what we can't do for ourself. Microsoft seems to be taking an increasingly proactive role on these security issues. It will be interesting to see how this pays off in 2-3 years from now.

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.