Zero Touch and the Cache

I had a chance to travel to Calgary earlier this week to speak at the Microsoft Bigger Better Basic conference.  One of the session I was scheduled for including a number of demos on the Smart Client technology.  So I'm sitting on the plane running through the demos just to make sure that I don't...er...mess up in front of 600 people and I get to the Zero Touch Deployment (ZTD) demo.  This is a straightforward demo showing what happens if you move a .NET application onto a virtual directory.  The deployment is done by clicking on a link in a simple HTML page.  So sweat right?

So I get to the part where the HTML page is displayed, click on the link and...nothing happens.  That strikes me as a little strange, so I start checking on the normal stuff.  Does the file exists.  Is it really a .NET application.  Does the link in the HTML page point to the right place.  All looks good.  So now I go on to the more esoteric possibilities.  Do I have the appropriate permissions defined in the Framework Configuration Wizard.  Are there any settings in the virtual directory that might be giving me grief.  Has ASP.NET been installed in the virtual directory.  Still nothing.

Now I'm beginning to pull my hair out.  After another 15 minutes or so of puzzling, I try to view the source for the HTML page.  Nothing happens.  Fortunately, this is a situation that I'm familiar with.  If you can't view the source for a web page, your temporary Internet cache is full.  And then it hits me.  No room in the Internet cache means that the downloaded application doesn't have a place to live.  So I go into the Internet Options, clear out my cache and ZTD works like it's supposed to.  No damage (other than those haris that are still stuck between my fingers).

But this does bring out one of the biggest weaknesses in the ZTD model.  The downloaded application lives in the cache, along with other pages of stuff from the Internet.  It is too easy for a user to clear out the cache, thus removing the benefit of off-line functionality.  I believe that this situation will be corrected one of the future products (I can't remember whether it's Indigo, Whidbey or Longhorn).  The correction is the cache the ZTD applications in a different location and allowing a generally more granular level of cache clearing.  Can't come too soon for my taste.  ZTD is nice, but when in the hands of the uninitiated, it has the potential to generate some help desk traffic.

October 2003 Visual Studio .NET Documentation Update

It was Eric Rudder who mentioned in his keynote that there was a new update to all the online help for the Visual Studio including something like 5,000 new samples. He mentioned this update like it had been around for months. Well it was posted on Oct 22/2003 in case you missed it.

 It must be good, it's an 80mb download.

MSBuild vs. NAnt

Correct me if I'm wrong but isn't MSBuild a knock off of NAnt or any other derivative of Ant?

Is the only reason MS created such a build tool is so that internal MS employees could use it? Do their employee contracts prohibit them from using Open Source tools? That's my speculation. Please correct me if I'm wrong.

It's not a problem if I'm right - but why not just use it internally at MS? Why make it public for everybody's use. We already have a decent tool and we get the source code to boot - not to mention community support.

I didn't get a chance to go to the MS Build presentation (TLS347) so I apologize in advance if I'm just not getting it. I have looked at the slides but there isn't much there - nothing that I don't see in NAnt.

I'm really looking for the killer reason not to use NAnt and switch to MSBuild. Maybe the answer is this..

MSBuild will be the core build engine underneath Visual Studio and share project file formats with VS.NET. Certainly this has caused me some grief with NAnt in the past, mostly with VB.NET since slingshot (the last time I looked) only converted csproj files to build files and not vbproj. So I think the most important thing about MSBuild is not MSBuild itself but that the C# and VB.NET teams will have to (or already have) collaborated on a unified .proj file format. Hopefully the NAnt contributors will write an XslTransform. As an aside I hear that this level of integration won't be available for C++ developers. Now getting three teams to talk to each other - that's just impossible. I bet that the .proj file format changes again when the C++ team gets around to supporting MSBuild.

In addition to the VS.NET integration, there seems to be only 1 other significant difference between NAnt and MSBuild. MSBuild includes some kind of “full inner-task dependency“ that is supposed to allow for incremental builds. While I might care about this for an IDE experience (slightly) it's less important from a nightly build scenario - IMHO.

ASP.NET and the Event Log

Today's tidbit revolves around enabling the ASP.NET user to generate entries into the event log.  In an ideal world (hint, hint Microsoft designers), this would be a relatively straightforward process.  Or at least one that didn't require a direct hack into the registry.  But that is not the case at the moment.  So without further ado, here are the steps involved in enabling the ASP.NET user to create event log entries.

1. Launch RegEdit
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\
    CurrentControlSet\Services\EventLog\
3. From the menu, select Edit->Permissions
4. Click the Add button and write ASPNET.  (if ASP.NET is running under a different user id, use that id instead)
5. Click OK.
6. Select the newly added user from the list (ASP.NET Machine User by default).
7. Click on Full Control in the Allow column.
8. Click OK.

It is usually a good idea at this point to restart IIS with the IISReset command (Start | Run | IISReset).

For those concerned with the security hole that has been opened up.  Once these changes are implemented, the ASP.NET user has full control over the Application event log.  Worst case scenario, a bad process could fill up the event log or delete existing log entries.  However, as far as security breaches go, these are fairly minor, especially when compared to the benefits of being able to view log entries.

PDC Aftermath

It's now the Monday after PDC. I just woke up.

What a week! I didn't get a blog entry in on Tursday it was a very busy day. Talked to some ADO Microsofties about DataSets and Object Spaces. Sat in one a few last sessions. Did some shopping. Headed for the airport. For the next 12 hours we travelled.

Now I have to sit down and watch all the presentations I wanted to go to but couldn't get into, or picked something else.

I hope the DVD comes soon.

 

Bigger Better Basic

Over the next month we are co-presenting with Microsoft at their cross Canada tour called Bigger Better Basic . ObjectSharp will be in 5 cities Calgary, Vancouver, Toronto, Montreal and Ottawa.

Come on out.

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
    Register

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.