Rockford Lhotka

 Tuesday, January 17, 2006

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.

Tuesday, January 17, 2006 2:48:29 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

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.

 

Tuesday, January 17, 2006 2:13:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, January 13, 2006

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!

Friday, January 13, 2006 12:47:37 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, January 6, 2006

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

Friday, January 6, 2006 4:19:28 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

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...

Friday, January 6, 2006 11:43:45 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 4, 2006

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!

Wednesday, January 4, 2006 12:47:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, January 3, 2006

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…

Tuesday, January 3, 2006 5:04:24 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, December 28, 2005

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!

Wednesday, December 28, 2005 10:56:47 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, December 13, 2005
I am at the point now where I think the resource.resx file for CSLA .NET 2.0 is stable. Of course it is only in English at this point, and so I am putting out a call to anyone willing to translate the file to other languages.
 
Thanks to volunteer efforts, CSLA .NET 1.x has resources in a total of 11 languages, which is simply wonderful!
 
If you are willing to translate the resources to your language, many people would appreciate your help.
 
The English resource.resx file can be downloaded here: www.lhotka.net/files/csla20-resources.zip
 
If you are able to translate the file, please email me the resulting translation and I'll incorporate it into the solution so it is available when the book comes out (anticipated for the end of March 2006).
 
I'll keep a log of the languages as part of the CSLA .NET 2.0 Change Log, so you can check there to see if your language already has a translation.
 
Thank you!
 
Rocky
Tuesday, December 13, 2005 4:55:14 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, December 7, 2005

Slashdot has some funny ones from time to time. Like this one, where the author contends that AJAX is a new Microsoft technology.

(note: the article he links to about AJAX is worth the read!)

But AJAX isn't new. It is old - many years old, for all that it didn't become popular until recently.

And it was the tech darling Google that made it popular, not Microsoft.

Sure it is based on technology Microsoft put in the browser many years ago, but until Firefox added support and Google used it broadly it was a sleeper...

But on slashdot everything negative must be associated with Microsoft - it's a rule I guess...

 

Wednesday, December 7, 2005 7:42:46 PM (Central Standard Time, UTC-06:00)  #    Disclaimer