MSDN and ObjectSharp: Bigger Better Basic - November, 2003 - Toronto - -10

ObjectSharp and MSDN team up to deliver a full day event designed to give developers using Visual Basic the expertise to create applications with .NET. We'll examine the design principles used to build smart client applications and a Services Oriented Architecture using Visual Studio .NET 2003. Attendees will also be able to see the Microsoft of tomorrow -- including live demos of future versions of Microsoft Visual Studio .NET and Microsoft Windows.

Event Dates:

  • Calgary Nov 4, 2003
  • Ottawa Nov 12, 2003
  • Montreal Nov 18, 2003
  • Toronto Nov 19, 2003
  • Vancouver Nov 26, 2003

Google Smoothies

Apparently google has a booth at PDC where they are giving away free smoothies. I searched and searched and searched but couldn't find it anywhere.


IsNumeric Best Practices

Needing to find out what the best why to implement the IsNumeric function in C# is, I went on a brief tour of the Internet today.  My result is a very informative article by J. Ambrose Little that benchmarks six (count 'em, six) different techniques.  The result is a virtual tie between an incremental character technique (use the Char.IsNumeric method on each character in a string), the Double.TryParse and VisualBasic.IsNumeric.  Useful information to keep in mind in the future.

Where is the holistic vision?

Microsoft is needs a holistic view of their platforms and development tools. I didn't see that this week, I doubt any of us will.

What I did see was 7 data access techniques in various stages of ready now, coming soon, and coming much later:

  • Use a DataAdapter to issue SQL  or stored procedures. Useful for working with a DataSet and doing optimistic updates.
  • Use a DataReader to issue a SELECT or stored procedure to walk through rows 1 at a time. Used for fast streaming of read only data.
  • SqlDataSources. From what I can tell, this is a terrible thing. I've seen this in two places so I'm not sure they are the same. The first demo I saw of this it was just called a “Data Source“ It was in a windows forms application and it looks  like a typed dataset (and in fact is/uses them) but it also embeds SQL queries (and updates, inserts and deletes) into the actual typed dataset. But I use datasets through the various tiers of my application from UI to data access and I don't want this marshaled throughout the application. I talked to Paul Yuknewicz from the VB team about this. I told him it would be okay in the design time to do this - but you have to split these out into two classes. He said I could, but he couldn't show me. He said the typed data set and the data access classes could be in separate namespaces. When I told him I needed them in separately assemblies because my datasets go down to the win forms client, but the data access sits in my middle tier and hits the database. He took this as a good feature request, but he didn't give me a good feeling about it. I mentioned this to another guy on the Data team and he said that these Data Sources would not be for me. I suppose if you're building a dog house, it doesn't have to be well architected like a sky scraper. Unfortunately I've had to do many renovations of dog houses in the past.
  • You can now embed some of the logic you'd do post retrieval to massage some data into the database. Yes, create a C# stored proc and return the data that way. You probably want to do this if the processing reduces the amount of ASCII (or the visibility - plain text - no encryption) to be sent along the wire.
  • SQLXML - not new but improved and gaining momentum. Can you say new language to learn? XQuery, XPath. This is nice if the data you deal with outside of the database is in XML. Also good for doing master/detail updates in 1 round trip. I like this.
  • ObjectSpaces. I saw a preview of this at PDC 2 years ago. I'm going to another session to learn more details in an hour. It's changed since then but the message is the same. It's an Object to Relational mapping scheme. You define how your tables relate to your objects - and then you merrily use your objects and ObjectSpaces figures out the SQL to send to the database. Why would you do this? Well if your app embeds a lot of business logic in your objects - which it should damn it. This technique lacks SQL fidelity and you have little direct control over the SQL emitted. Hmm. If I don't know what SQL will be issued how will I determine the best indices? How does the SQL Server team feel about this? I've already heard from Michael Pizzo that you can't expect the same performance as native SQL.
  • WinFS. Longhorn includes a new file system. My interpretation is that it's less of a file system and more of an intermediate object model that sits over top of NTFS and the next version of SQL. WinFS let's you view your SQL data as files. A record is a file. Not all files become records though. (I can hear DBAs everywhere sighing). The idea here is to “give users excellent windows experiences“ by getting data out of the silos of applications and bringing it to the shell to be integrated between applications the way users want it. I like the idea in theory but the security aspects scare me a bit. The nice thing is that this is coming in Longhorn - a long time from now so we have time to think about this more...and for MS to try and get it right. You can bind controls in your forms to properties on files (which are records - so those are just columns). Where is the business logic in that tier? Welcome back client server. Not sure how this all works on a LAN.

I was also saw at least 3 user interface models:

  • Traditional Smart Client Window Forms. These don't' change much in Whidbey.
  • ASP.NET Web Forms. Changing a bit. Still HTML coded into an aspx file.
  • Avalon XAML Forms. See my previous post about this. The key point is that it attempts to bring the benefits of Web Forms to Windows Forms and vice versa.

Let's not get into Pocket PC, Smart Phones, WML, Tablet Ink or Media Center. That would make this blog more ridiculous than it already is. Suffice it say that each of these 3 user interfaces all have their own databinding techniques and they are all different. I saw some of the ASP.NET Whidbey two-way databinding today and its nothing like WinForms binding. It's like that team never talks to the windows team. Sigh.

What I didn't see was anything about COM+, Enterprise Services. Where the hell was COM+. Does that all disappear with Indigo? Indigo is only supposed to be a communication platform right?

I guess it's my job as an architectural consultant to value each of these technologies, how they fit together ultimately - and a road map for doing something useful today - that will be useful tomorrow. Nobody at Microsoft has done this yet.

The scary thing is that it seems like all these teams are working in silos and not talking to each other enough. Seems to be a theme. Don't get me wrong, the are doing fabulous stuff but everybody has a different way of doing things. It seems like they spend lots of time developing their technology but not enough time building real applications that sit on top of them.

The good news is that its early for a lot of this stuff and lots of time to fix it and get it right. A lot of Microsoft guys were seeing some of this stuff for the first time themselves.

I suspect that the MSDN Prescriptive Architecture Group has some work cut out for them.

Phantom Properties

Yet one more interesting Web Service problem reared its head today.  The situation is as follows:

The result of a call to a Web Service method is supposed to be a class. The class contains the elements that, basically, make up a record in a database table.  Because of the way that we structure data access, our data access class returns a DataSet with a matching xsd file.  Once the xsd file had been created, the xsd.exe tool was used to create the class definition.  An instance of the class was then hydrated using the XML format of the DataSet and returned through the web service.

(just for the curious amongst you, our reason for not returning the DataSet itself is that the client is an older version of WebSphere and they don't have easy support for processing returning DataSets.)

Key point coming:  the minOccurs value on at least some of the data elements in the xsd was set to 0.  As a result, for some of the data types (specifically integers, int16 and bytes), additional properties were created.  For example, if there were a property called Status, a public boolean property called StatusSpecified would also be created. 

No problem to this point.  A web method is created with a return value of the class that was generated by xsd.  The method is called and *bam* (picture Emeril at this point), an error gets generated.  The error is the following:

Server was unable to process request. File or assembly name q2k5rmkd.dll, or one of its dependencies, was not found.

The experienced among you will recognize this as a error that occurs when the ASP.NET user doesn't have access to the temporary directory.  But that was not the case here. It is also an error that gets returned when one of the classes used in a web service message has a ReadOnly property.  But a review of the returned class shows that this is not the case either. 

As it turns out, the problem is that the Specified properties (such as StatusSpecified) conflicts with an automatically generated property called, coincidentally, StatusSpecified.  This automatic property is generated when the result set contains a minOccurs clause.  It is used with numeric values to identify those properties that have not been assigned.  It is necessary because numeric variables don't have a 'null' value. But the conflict between the autogen'ed properties and the properties that are created by xsd causes the error message seen above.  The easiest solution is to change the name of the properties included in the xsd.exe generated class to have a name that does not have 'Specified' as the suffix.

Food at PDC

I can't go all week without mentioning the food, here. I took a couple of pictures to get the point across. Check out my pictures. it will help you visualize.

I took a picture of the lunch and breakfast hall. I got as much in as I could with my camera. Imagine seating 8000 for lunch. It's quit amazing to watch, the staff here at the conference centre are great.

All around the conference centre there are tables full of food. There are two pictures of these also. They are always full of muffins, bagels, chips, chocolate bars, granola bars and fruit. There must be 10 of them set up. Next to these are giant coffee urns and barrels full of pop juice and water.

No one is going hungry here!

C# now there's a language

Did I mention msbuild? Microsoft is writing their own NANT. It's XML and everything.

Yesterday was a C# day for me.

I tried to get into Anders Hejlsberg's session on the new features in C#.

  • Generics
  • Iterators
  • Anonymous methods
  • Partial types
  • Property accessors with different accessibility

But it was full. Even the TV outside the room had no space around it. They sometimes re-run popular sessions. Fingers Crossed.

I did however get into a good session called Visual C# "Whidbey" IDE enhancements for the C# developer

Found some things in there to look forward to.

Debugging is easier with regard to DataSets. In Whidbey you can adjust what you want to see in the debugger. You can tell VS what you consider your code and therefore want exposed in the debugger. You can also click on a drop down and see a DataSet Visualizer, which is essentially a list box of DataTables and a grid for the DataRows and DataColumns. It's like a trimmed down version of Barry's DataSet Debugger. In the build I saw, it’s not as good as Barry’s but maybe it will get better.

Here's one Andre will like. They have included IDE support for refactoring code.

Rename - You can rename a method and have it change solution wide.
Extract Method - If you wrote a large method and later decide it would be better split into multiple methods. You can highlight a section of code and select [extract method]. Whidbey will prompt you for a method name. It will figure out what arguments you need the scope and what it returns.
Some others include:

  • Extract Interface
  • Encapsulate Field
  • Reorder parameters
  • Remove Parameters
  • Add Parameters

Expansions are cool too:
You know in VB .net how you type in a property and it fills in the get and set etc. VB had to do this because it's so verbose no one would use it otherwise. :)

Whidbey has something else cool called expansions (C# has it for sure. I have not confirmed VB). Using XML you can define an expansion, which shows up in IntelliSense. Lets say you wanted to create a property expansion. You could type in prop and it could fill in the following. the cursor would be placed on string ready for you to change. You can just tab through the fields (in yellow) to change the names.

private string name;

public string Name {

get { return name;}

set { name = value;} }

That's enough for now. I have to get to another session.

We are going to Universal Studios today whoohoo!

Tonight is universal studios night. Microsoft rented the park for us for a few hours. I can't wait. Shrek 4D here I come.

The network at the hotel sucks. Couldn't get on last night for any longer than a minute or two. We were supposed to be in a web cast with Microsoft today but couldn't get a spot quiet enough with a stable network to do it.

Got an email from Roman this morning. Thanks Roman. Seems the dart team lost last night. Hard luck guys. I was thinking about you.

Right now I'm in a session for the tester in me. “Avalon” UI Automation to improve application testing. It's just starting so I'll be right back.


Longhorn, Avalon and XAML oh my.

Yesterday I spent all my time at Longhorn presentations....for the most part. I got a chance to look a close look at XAML.

XAML does for smart client windows forms apps what aspx/HTML does to web apps: separates the UI from the rest of your app. In the wake of infopath, I've told more than one person that I didn't think traditional developers would be coding user interface 5 years from now. XAML makes it a lot easier for that to become true.

But XAML is more. Sure you can mark up your form with XML. But it can be compiled into BAML. Binary XAML. You don't have to use XAML to code up your forms, you can still use the current Windows Forms designer than puts your controls into .NET Code in the “Designer Generated Code” region of your form class. Both techniques get compiled and are the performance equivalents. That's cool. You can further compile (or is it link?) BAML into assemblies.

XAML has 2 (or 3) rendering modes. Fixed Format is like windows forms now. Also like Grid Layout in ASP.NET. You scroll around and stretch stuff - but nothing moves. Flow Format is more like traditional flowing HTML. You resize your browser and stuff changes. The rendering agent takes care of paging so the # of pages changes automagically as you resize. You can even click on the scroll bar to get thumbnail views of the next pages in the whole document.

Adaptive Flow is cool. Imagine a 16:9 wide screen and you resize your document to be full screen. It's tough to read a line that long. They've though of everything. When a line becomes too long to read, the rendering engine flips to the display to 2 columns like a newspaper or DTP style document. Makes it so nice and you can see it happen quickly as you resize a form - bam - two columns.

XAML makes skinning pretty easy. In fact in the “Being a good Windows Citizen” presentation, the Windows User Experience team talked about a technique for designing your UI that MS uses and recommends that we all do it. Create 2 or 3 fictional users for your application whose profiles are based on real or anecdotal evidence. Give them names. Give them photos. When you need to make a decision about how your UI should look or the app should work - ask yourself: How would Toby like this screen? How about Jeff? Ms has 8 fictional people that encompasses the full spectrum of their core windows & office products. Skinning your app is sometimes the only way to create a UI that will satisfy everybody - give them each their own. Not only is this possible with XAML, it can be done after the initial compile of your application and you can deploy BAML after initial release much like localized satellite assemblies. Way cool - so long as you design for this from the get go.

Another cool thing about longhorn is that the UI is all vector based. So you can do things like rotate your buttons and text boxes etc. Pretty cool, not very useful. Being able to zoom in on a part of your text though and still have a pretty (not aliased) image is wonderful. It demonstrates the power of the new graphics subsystem and the dependency on graphics cards in Longhorn. It's fast. The new graphics subsystem is rebuilt from the ground up to provide very fast. It needs to. Resolutions are getting bigger and bigger, and being able to scale a traditional UI to make it bigger is important given the predicted growth of screen sizes. It seems like more of a bell or whistle at this point, but it's going to totally change the user experience.

Data binding is now built into the OS. You can bind to files on your WinFs hard drive. A file can have meta data defined by a schema and any of that information is fair game to be bound into your apps. More to come on this. It's just too far out for me to “make it real” at this point. Data binding is one of those things you just have to get into when you need it. But it looks good.

I thought it was kind of goofy that during the key  note, all developer demos  for Longhorn and Avalon were done with Emacs, Slickedit and VIM. Then I realized they had to be. There is no Visual Studio for Avalon yet. You can still get VS.NET any version to edit the class files, but it's no full developer experience for Longhorn/Avalon. There is no WYSIWYG XAML editor yet.

Get ready to design your screens in FrontPage - Ahhhhh!

Interoperating with WebSphere

I just had the joy of spending a day trying to get my .NET Web Service to interact with a WebSphere client.  Regardless of the changes made, the following error was received on the Java side.

Unable to retrieve PropertyDescriptor for property Xxx

All of the property names matched up.  All of the properties in the Java class had getters and setters. The ultimate solution?  Change the case of the property names.  The problem only occurred if the property name started with a capital letter.  If changed to a camel case format, the problem goes away.  Apparently, this is a problem with the standard BeanSerializer in older versions of WebSphere (version 5.0 and earlier).  According to the notes that I found, it has been corrected at 5.1 and in a patch to 5.0.  Can't vouch for this, as we just swallowed hard and changed the case of our exposed properties.  I hate case sensitivity.