Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Monday, January 30, 2006

A public beta of CSLA .NET 2.0 is now available at www.lhotka.net/cslanet/csla20.aspx

The Expert C# 2005 Business Objects and Expert VB 2005 Business Objects books are still due out around the end of March. That is also the point at which the framework with "RTM".

The public beta should be reasonable stable. I am nearly done with technical reviews of the chapters, and so am basically done with the framework updates. The ProjectTracker sample application is still under review at this point.

Monday, January 30, 2006 2:44:08 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, January 24, 2006

Next week at VS Live in San Francisco I’ll release a public beta of CSLA .NET 2.0.

 

This will include both VB 2005 and C# 2005 editions of the framework code, along with a sample application in both languages, showing how the framework can be used to create Windows, Web and Web service interfaces on top of a common set of business objects.

 

Those business objects are substantially more powerful than their CSLA .NET 1.x counterparts, while preserving the same architectural concepts and benefits. These objects leverage new .NET 2.0 features such as generics. They also bring forward features from CSLA .NET 1.5, but in a more integrated and elegant manner. There are additional features as well, including support for authorization rules, a more flexible data portal implementation and more.

 

Watch www.lhotka.net for the release of the beta next week.

 

Click here to see Jim Fawcette's blog entry about the upcoming beta release.

Tuesday, January 24, 2006 1:43:25 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, January 23, 2006

[Warning, the following is a bit of a rant...]

 

Custom software development is too darn hard. As an industry, we spend more time discussing “plumbing” issues like Java vs .NET or .NET Remoting vs Web Services than we do discussing the design of the actual business functionality itself.

 

And even when we get to the business functionality, we spend most of our time fighting with the OO design tools, the form designer tools that “help” create the UI, the holes in data binding, the data access code (transactions, concurrency, field/column mapping) and the database design tools.

 

Does the user care, or get any benefit out of any of this? No. They really don’t. Oh sure, we convince ourselves that they do, or that they’d “care if they knew”. But they really don’t.

 

The users want a system that does something useful. I think Chris Stone gets it right in this editorial.

 

I think the underlying problem is that just building business software to solve users’ problems is ultimately boring. Most of us get into computers to express our creative side, not to assemble components into working applications.

 

If we wanted to do widget assembly, there’s a whole lot of other jobs that’d provide more visceral satisfaction. Carpentry, plumbing (like with pipes and water), cabinet making and many other jobs provide the ability to assembly components to build really nice things. And those jobs have a level of creativity too – just like assembly programs do in the computer world.

 

But they don’t offer the level of creativity and expression you get by building your own client/server, n-tier, SOA framework. Using data binding isn’t nearly as creative or fun as building a replacement for data binding…

 

I think this is the root of the issue. The computer industry is largely populated by people who want to build low-level stuff, not solve high-level business issues. And even if you go with conventional wisdom; that Mort (the business-focused developer) outnumbers the Elvis/Einstein framework-builders 5 to 1, there are still enough Elvis/Einstein types in every organization to muck things up for the Morts.

 

Have you tried building an app with VB3 (yes, Visual Basic 3.0) lately? A couple years ago I dusted that relic off and tried it. VB3 programs are fast. I mean blindingly fast! It makes sense, they were designed for the hardware of 1993… More importantly, a data entry screen built in VB3 is every bit as functional to the user as a data entry screen built with today’s trendy technologies.

 

Can you really claim that your Windows Forms 2.0, ASP.NET 2.0 or Flash UI makes the user’s data entry faster or more efficient? Do you save them keystrokes? Seconds of time?

 

While I think the primary fault lies with us, as software designers and developers, there’s no doubt that the vendors feed into this as well.

 

We’ve had remote-procedure-call technology for a hell of a long time now. But the vendors keep refining it every few years: got to keep the hype going. Web services are merely the latest incarnation of a very long sequence of technologies that all you to call a procedure/component/method/service on another computer. Does using Web services make the user more efficient than DCOM? Does it save them time or keystrokes? No.

 

But we justify all these things by saying it will save us time. They’ll make us more efficient. So ask your users. Do your users think you are doing a better job, that you are more efficient and responsive, that you are giving them better software than you were before Web Services? Before .NET? Before Java?

 

Probably not. My guess: users don’t have a clue that the technology landscape changed out from under them over the past 5 years. They see the same software, with the same mis-match against the business needs and the same inefficient data entry mechanisms they’ve seen for at least the past 15 years…

 

No wonder they offshore the work. We (at least in the US and Europe) have had a very long time to prove that we can do better work, that all this investment in tools and platforms will make our users’ lives better. Since most of what we’ve done hasn’t lived up to that hype, can it be at all surprising that our users feel they can get the same crappy software at a tiny fraction of the price by offshoring?

 

Recently my friend Kathleen Dollard made the comment that all of Visual Basic (and .NET in general) should be geared toward Mort. I think she’s right. .NET should be geared toward making sure that the business developer is exceedingly productive and can provide tremendous business value to their organizations, with minimal time and effort.

 

If our tools did what they were supposed to do, the Elvis/Einstein types could back off and just let the majority of developers use the tools – without wasting all that time building new frameworks. If our tools did what they were supposed to do, the Mort types would be so productive there’d be no value in offshoring. Expressing business requirements in software would be more efficiently done by people who work in the business, who understand the business, language and culture; and who have tools that allow them to build that software rapidly, cheaply and in a way that actually meets the business need.

Monday, January 23, 2006 11:41:13 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, January 19, 2006

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.

Thursday, January 19, 2006 4:25:32 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

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

Thursday, January 19, 2006 9:34:17 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, January 18, 2006

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.

Wednesday, January 18, 2006 1:13:41 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 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  |  Comments [0]  | 

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  |  Comments [0]  | 
 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  |  Comments [0]  | 
 Friday, January 06, 2006

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

Friday, January 06, 2006 4:19:28 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

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 06, 2006 11:43:45 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Wednesday, January 04, 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 04, 2006 12:47:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, January 03, 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 03, 2006 5:04:24 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In