Microsoft invites you to MIX, our 72 hour conversation live in Vegas, to discuss with industry leaders such as yourself high-fidelity commerce, media, services and security for the World Wide Web.  Join Bill Gates of Microsoft, Amazon, and web thought leaders such as Tim O’Reilly on March 20-22 at the Venetian hotel in Las Vegas to learn about the web’s next generation of content and commerce, plus the customer experience that is beyond the browser.  Registration is open!  www.mix06.com

The MIX conference is a LIVE conversation between web developers, designers and business leaders who create consumer-oriented web sites. Why is it called MIX?  The event is not only a place where you can Meet, Interact, and eXplore with Microsoft and others about the web, but we are MIXing things up by having a conference for tech geeks as well as business professionals who help make decisions about technologies and strategies for your company’s customer facing web sites.  When you attend MIX you’ll hear about Microsoft’s roadmap for the web, and learn the latest about Internet Explorer 7, Windows Media, Windows Live!, as well as “Atlas”, Microsoft’s new AJAX framework.  Register today and take advantage of the low price of $995, as well as the discounted conference hotel rate.

In a previous post I discussed some issues I’ve been having with the ASP.NET Development Server (aka VS Host or Cassini).

I have more information direct from Microsoft on my issue. It turns out that it is “by design”, and a sad thing this is… VS Host is designed such that the thread on which your code runs can (and does) go between AppDomains.

Objects placed on the Thread object, such as the CurrentPrincipal, must be serializable and the assembly must be available to all AppDomains; even the primary AppDomain that isn’t running as part of your web site!

And this is the root of my problem. I create a custom IPrincipal object in an assembly (dll). I put it in the Bin directory and then use it – which of course means it ends up on the Thread object. Cassini then runs my code in an AppDomain for my web site and all is well until it switches out into another AppDomain that isn’t running my web site (but rather is just running Cassini itself). Boom!

Why boom? Well, that custom IPrincipal object on the thread is still on the thread. When the thread switches to the other AppDomain, objects directly attached to the thread (like CurrentPrincipal) are automatically serialized, the byte stream transferred to the new AppDomain, and deserialized into the new AppDomain. This means that the new AppDomain must have access to the assembly containing the custom IPrincipal class – but of course it doesn’t, because it isn’t running as part of the web site and thus doesn’t have access to the Bin directory.

What’s the answer? Either don’t use Cassini (which has been my answer), or install the assembly with the custom IPrincipal into the GAC. Technically the latter answer is the “right” one, but that has the ugly side-effect of preventing rapid application development. All of a sudden you can’t just change a bit of code and press F5 to test; instead you must build your code, update the GAC and then you can test. Nasty…

As an aside, this is exactly the same issue you’ll run into when using nunit to test code that uses a custom IPrincipal on the thread. Unlike nunit however, you can’t predict when Cassini will switch you to another AppDomain so you can’t work around the issue by clearing the CurrentPrincipal like you can with nunit (or at least I haven’t found the magic point at which to do it…).

What’s really scary is that it was implied that this could happen under IIS as well – but that flies in the face of years of experiential evidence to the contrary. I guess the safe thing to do is to treat IIS like Cassini, and put shared assemblies in the GAC. But I’m not sure I’m ready to advocate that yet, because that means complicating installs a whole lot, and I’ve never encountered this threading issue under IIS so I don’t think it is a real issue.

Microsoft announced Go Live licenses this morning for WCF (Windows Communication Foundation / “Indigo”) and WF (Windows Workflow Foundation), which allow customers to use the January Go Live releases of WCF and WF in their deployment environments.  (Note that these are unsupported Go Lives.) 

More information about the Go Live program is at http://msdn.microsoft.com/winfx/getthebeta/golive/default.aspx.

There are also WCF and WF community sites, at:

http://windowscommunication.net

http://windowsworkflow.net

The community sites are intended to give users everything needed to start using WCF and WF today.

In a recent entry there was a comment pointing to this article, which discusses the way ASP.NET uses threads – a fact that has serious ramifications on software design.

It made me do some serious thinking/research, because CSLA .NET uses various elements of the Thread object, including the CurrentPrincipal, thread-local storage and (in 2.0) the culture properties. My fear was that if the thread can switch “randomly” during page processing, then how can you count on any of these elements from the Thread object?

Scott Guthrie from Microsoft clarified this for me on a couple key points.

First, ASP.NET doesn’t change your thread at “random” or “without warning” (phrases I’d used in describing my worries). It changes it only in a clearly defined scenario. Specifically, when your thread performs an async IO operation. Scott points out that this is perhaps most common in a page that takes advantage of the new async page capability, or within a HttpModule that uses any async IO.

In other words, normal web pages really aren’t subject to this issue at all. It only occurs in relatively advanced scenarios. And you, as the developer, should know darn well when you invoke an async operation; thus you know when you open yourself up for thread switching.

Still, I wanted to make sure the Business Objects book didn’t go down a bad path with the Thread object. But Scott clarified further.

ASP.NET ensures that, even if they switch your thread, the CurrentPrincipal and culture properties from the original thread carry forward to the new thread. This is automatic, and you don’t need to worry about losing those values. Whew!

However, thread-local storage doesn’t carry forward. If you use that feature of the Thread object in ASP.NET code you could be in trouble. This did cause me to rework some code in the book and in CSLA .NET. Specifically CSLA .NET 2.0 now detects whether it is running in ASP.NET or not and uses either thread-local storage or HttpContext.Current.Items to maintain its context data.

I also went the rest of the way and created a Csla.ApplicationContext.User property that gets and sets the user’s principal on either the Thread or HttpContext based on whether the code is running in ASP.NET or not. This allows you to write code in your UI and objects and other libraries without worrying about whether it might run inside our outside ASP.NET at some point.

Certainly for mobile business objects this is very important! They can (and often do) run in both a smart client and ASP.NET environment within the same application.

In a recent email discussion a fellow Microsoft Regional Director, Patrick Hynds, drew an analogy comparing programming languages to tanks and A-10 attack planes:

I know when to use a Tank (plodding and durable lethality) and I know when to use a A-10 (fast, maneuverable and vulnerable lethality), but if you make tanks fly and add a few feet of armor on an A-10 then you get the same muddy water we have between C# and VB.Net.  Those that know me will forgive the military analogy

I continued the analogy:

The problem we have today, in my opinion, is that C# is a flying tank and VB is a heavily armored attack plane.

Microsoft did wonderful things when creating .NET and these two languages - simply wonderful. But the end result is that no sane person would purchase either a tank or an A-10 now, because both features can be had in a single product. Well, actually two products that are virtually identical except for their heritage.

Of course both hold baggage from history. For instance, C# clings to the obsolete concept of case-sensitivity, and VB clings to the equally obsolete idea of line continuation characters.

Unfortunately the idea of creating a whole new language where the focus is on the compiler doing more work and the programmer doing less just isn't in the cards. It doesn't seem like there's any meaningful language innovation going on, nor has there been for many, many years...

(Even LINQ (cool though it is) doesn't count. We had most of LINQ on the VAX in FORTRAN and VAX Basic 15 years ago...)

The only possible area of interest here are DSLs (domain-specific languages), and I personally think they are doomed to be a repeat of CASE.

I'll do some more real blogging at some point too - probably once I get the new Expert VB/C# Business Objects books off to the printer in just a few more weeks.

In the meantime, Billy's history of programming languages left me in stitches!

First, my good friend and colleague Billy Hollis is blogging. Second, he's got a great analogy about the .NET Framework.

As I’m working on the next edition of my Expert VB/C# Business Objects books I’m building both a Web Forms and Web Services interface. And I’m running into issues with the ASP.NET Development Server provided with Visual Studio 2005. This web server is often referred to as the VS Host.

The issue is with assembly loading. Apparently the VS Host has difficulties loading assemblies at times, which causes issues.

For instance, you can’t test a custom membership provider if it is in a separate assembly that is referenced by your web site – that causes an assembly load exception.

In my particular case the problem I’m having is that I put a custom IPrincipal object on the thread and HttpContext. That works great, but at some point VS Host apparently switches to some other internal AppDomain – triggering an attempt to serialize and deserialize that principal object. The result? BOOM!

Again, an assembly load exception – this time because the attempt to deserialize the principal object into that other mysterious AppDomain fails…

All my usual tricks have failed. I’ve tried clearing the principal from the thread and HttpContext before the page processing is complete. No dice. I’ve tried handling the AppDomain event that is raised when an assembly can’t be found. No dice (which isn’t a surprise, since it isn’t MY AppDomain that’s having the problem).

In the end, the VS Host appears to be useless for any work where you are using custom principal or custom membership provider classes. In a casual conversation on this topic a friend of mine suggested that perhaps VS Host was for prototypes and hobbyists; and I think he was right. Real web development still must be done with IIS only...

Brant Estes, a fellow Magenic consultant, wrote a very interesting blog entry showing how you can embed those pesky extra DLLs into your EXE, and yet have .NET find them when needed. He even tried it with CSLA .NET, creating a single EXE that embeds the CSLA assembly as a resource - very cool!

In the January 2, 2006 edition of InfoWorld there’s a short article about the recent release of MySQL 5.0. I’ve used MySQL, and there are even people building CSLA .NET based applications with MySQL backend databases. Kudos!

But the article makes this comment about the new stored procedure support in MySQL:

“The stored procedures were generally stable in my tests, but this being MySQL’s first implementation, there were a few bugs. For example, I had some trouble with the server freezing up when I tried to open some of my larger procedures. Although not a show-stopper, this behavior could be a problem if you have a busy database.”

I had to read this several times to be sure I had it right. The “server freezing up” is “not a show-stopper”?!?

Suppose Oracle or SQL Server would “freeze up” when you opened a large stored procedure? On a busy database or not I’m guessing no sane person would say that this was “not a show-stopper”.

It is not a show-stopper because the expectations of a released open source (OSS) product just aren’t in the same league with “real” software? If so, then OSS really is just a joke. But I don’t buy this argument, because MySQL is used as “real” software by many companies, and thus it should be held to the same standard as any other database engine out there.

Or is it not a show-stopper because of media bias? Because the media tends to cut OSS slack they’d never dream of cutting proprietary software? Because if they scrutinized OSS software at the same level they do proprietary software everyone would see just how little difference “open” really makes in terms of quality or security?

I think this latter argument holds a lot more water. Americans like the underdog, and OSS is the underdog compared to any proprietary system out there. So the media throws objectivity out the window and cuts them a break. OSS is held to a lower standard, even so far as that having your database server freeze up is a trivial concern.

What a shame, since this sort of reporting will ultimately be a lead weight around the ankles of OSS. OSS will never get real respect unless it is treated as being in the same league with the rest of the software in the world. And that starts with the media…

I apologize for the shameless plug, but I thought this was rather cool:

I see that my Expert C# Business Objects book has been nominated for the .NET Developer's Journal (.NETDJ) Magazine 2005 Readers Choice Award in the

category of Best .NET Book/Training Software.

I would appreciate your vote so that the book can win this highly prestigious award.  You can also cast a vote for various other favorites you might have in other categories. As part of the voting process, you can also get a free subscription to the Digital Edition of .NETDJ.

Cast your vote at:  http://dndj.sys-con.com/general/readerschoice.htm 

To begin voting, click on the "Click Here to Vote Now!" link.

Voting Ends Midnight, December 31, 2005

Thank you!