Rockford Lhotka

 Thursday, February 19, 2009

Setting up any type of n-tier solution requires the creation of numerous projects in the solution, along with appropriate references, configuration and so forth. Doing this with a Silverlight application is complicated slightly because Silverlight and .NET projects are slightly different (since they use different compilers, runtimes, etc). And sharing code between Silverlight and .NET projects complicates things a bit more, because the same physical code files are typically shared between two different projects in the solution.

CSLA .NET for Silverlight makes it relatively easy to create powerful n-tier applications that do share some code between the Silverlight client and the .NET server(s). Even though CSLA .NET does solve a whole host of issues for you, the reality is that the solution still needs to be set up correctly.

Here are the basic steps required to set up an n-tier CSLA .NET for Silverlight solution:

  1. Create a new Silverlight application project
    1. Have Visual Studio create a web application for the Silverlight project
  2. Add a new Silverlight Class Library project (this is your business library)
  3. Add a new .NET Class Library project (this is your business library)
  4. Use the Project Properties windows to set the Silverlight and .NET Class Library projects to use the same namespace and assembly name
    image
    image
  5. Remove the Class1 files from the Silverlight and .NET Class Library projects
  6. (optional) Add a .NET Class Library project to contain the data access code
  7. Set up references
    1. The Silverlight application should reference Csla.dll (for Silverlight) and the Silverlight Class Library
    2. The Silverlight Class Library (business) should reference Csla.dll (for Silverlight)
    3. The ASP.NET Web application should reference Csla.dll (for .NET), the .NET Class Library (business) and the .NET Class Library (data)
    4. The .NET Class Library (data) should reference Csla.dll (for .NET) and the .NET Class Library (business)
    5. The .NET Class Library (business) should reference Csla.dll (for .NET)
      image
  8. Add your business classes to the .NET Class Library (business)
    1. Link them to the Silverlight Class Library (business)
    2. Use compiler directives (#if SILVERLIGHT) or partial classes to create Silverlight-only or .NET-only code in each Class Library
  9. Configure the data portal
    1. Add a WcfPortal.svc file to the ASP.NET web application to define an endpoint for the Silverlight data portal
    2. Add a <system.serviceModel> element to web.config in the ASP.NET web application to configure the endpoint for the Silverlight data portal
    3. Add any connection string or other configuration values needed on the server to the web.config file
    4. Add a ServiceReferences.ClientConfig file to the Silverlight application and make sure it has an endpoint named BasicHttpBinding_IWcfPortal pointing to the server

This isn’t the simplest or most complex option for creating a CSLA .NET for Silverlight solution. You could use CSLA .NET for Silverlight to create a client-only application (that’s the simplest), or a 4-tier application where there is not only a web server in the DMZ, but also a separate application server behind a second firewall. I do think that the model I’ve shown in this blog post is probably the most common scenario however, which is why this is the one I chose to outline.

Thursday, February 19, 2009 4:24:58 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, February 10, 2009

A ridiculously long time ago I was in a meeting at Microsoft, sitting next to Ted Neward. As you may know, Ted lives in both the Java and .NET worlds and kind of specializes in interop between them.

Somehow (and I don’t remember the specifics), we got to talking about object serialization and related concepts like encryption, signing and so forth. It turned out that Java had a library of wrapper types that worked with the serialization concept to make it very easy to sign and encrypt an object graph.

Thinking about this, it isn’t hard to imagine this working in .NET, and so I whipped up a similar library concept. I’ve used it from time to time myself, but never quite got around to putting it online for public consumption. Until now:

Download the SerializationWrapper solution

The download includes nunit tests, so you can figure out how to use it pretty easily by looking at those.

For example, to sign a serializable object graph, just do this:

SignedWrapper<string> wrapper = new SignedWrapper<string>(data, hashKey);

You can then send the wrapper over the network as long as it is serialized using the BinaryFormatter or NetDataContractSerializer, and on the other end you can make sure it hasn’t been tampered with by verifying the signature:

if (wrapper.Verify(hashKey))

Of course the really tricky part is key exchange. How did both ends of the process get access to the same hashKey value? That’s outside the scope of my library, and frankly that is the really hard part about things like security…

In fact, if you look inside the code for the various wrapper classes, you’ll find that I’m just delegating all the interesting work to the .NET cryptography subsystem. By using the various wrappers together you can do asymmetric public/private keys, symmetric keys. You can do signing, and encryption. I think I now cover all the different algorithms supported by .NET – in one nicely abstract scheme.

Also, if you look inside the solution you’ll see a compression wrapper. That was an experiment on my part, and I really didn’t find the result satisfying. My thought was that you’d wrap your object graph (maybe after it was encrypted and signed) in the compression wrapper, and then that would be serialized to go over the wire.

But it turns out that there are two flaws:

  1. Serializing the compressed data makes it quite a bit bigger, and you are better off transferring the CompressedData value from the wrapper rather than allowing the wrapper itself to be serialized.
  2. More importantly, compressing encrypted data doesn’t work well. Encrypted data is pretty random, and the two compression algorithms included in .NET don’t do a particularly good job of compressing that data. I don’t know if other algorithms are better at compressing encrypted data, but I was disappointed with the results I found here.

In any case, I’ve found the crypto wrapper classes to be generally useful in abstracting most of the complexity of dealing with the .NET crypto subsystem, and I thought I’d share the code in case anyone else can find it useful as well.

Tuesday, February 10, 2009 3:24:10 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, February 5, 2009

I have run across a couple really interesting items in the Silverlight area recently, and I’d like to call some attention to both of them.

First is a tool that compresses xap files called XapOptimizer. Right now you can try it online – upload your xap, then download a compressed result. I’ve done this with a couple of my xap files and the size difference is quite remarkable. I assume it will be a product you can work into your build script at some point.

Second is something totally different: a browsable pattern library of UI patterns. This is really interesting, and potentially very useful, because it pulls together real-world examples showing various implementations of the patterns, as well as providing some good motivation and explanation about each. What’s even better, is that this is written in Silverlight. But the really impressive part of this is the effort that must have gone into collecting and organizing all the data for the patterns.

Thursday, February 5, 2009 9:16:16 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I think Silverlight represents the likely future of computing for most of us. And by “us”, I mean both Windows and web developers on the Microsoft platform (and maybe beyond).

I think we’re at a point of convergence, where two industry trends are coming together in a way that makes Silverlight the most compelling answer for a lot of development scenarios. These trends are the continued abstraction away from the hardware, and now the operating system; and the likelihood that the web as we know it is nearing the end of its life, so we’re looking for the next big thing in that space.

Arguably, Silverlight’s primary competitor is WPF. But I don’t think WPF is the long-term winner. Another obvious competitor is Flash/Flex/Air, and that could be serious except for the fact that Silverlight lets existing .NET developers (and there are a lot of us) leverage our existing skills, while Adobe means starting over. And another competitor is Gears, which may be valid, time will tell (as long as I don’t have to do Javascript), but also means starting over and discarding all the .NET skills we’ve accumulated. And Gears, to me, represents the last gasping attempt to salvage the web as we know it – and I suspect that’s a lost cause.

Part of the appeal of Silverlight, and the reason it almost instantly gains traction in any conversation with my clients, is that it is independent of Windows. They like the idea that it works across Windows versions without worrying that Microsoft will fix some Windows thing and break their app.

Some of them, especially those that deal with the government, really like that it works on the Mac as well as Windows. They have cross-platform requirements mandated by either the market or by law, and Silverlight gives them the option of using .NET (which they love) to run apps on the Mac.

Another part of the appeal of Silverlight, across the board from what I can see, is that people don't trust ClickOnce. But they do trust the browser as a deployment vehicle. I suspect this goes back, somewhat, to Silverlight being independent of Windows, while ClickOnce is more vulnerable to the OS itself. Our overall experience with ClickOnce is that it works great 99% of the time. And then 1% of the time it fails for no reason anyone can figure out. Same target machines, same configuration, but it just doesn't quite work. Maybe, over time, we'll find out Silverlight is also unreliable in this manner - but early indications are that this is not the case.

If you look at the theme here, it is about escaping the OS and all its complexity. And that's not entirely surprising.

We build the first OSes to abstract the hardware. And they evolved over decades until they were terribly complex, and somewhat intertwined with the hardware (driver issues are the major failure point for Windows).

So we built runtimes to abstract the OS (starting perhaps with Smalltalk, then VB, the JDK and now .NET). And they evolved over the past couple decades until they are becoming terribly complex, and somewhat intertwined with the OS (installing/upgrading .NET usually requires a reboot of Windows).

It appears to me that we're now building smaller, decoupled runtimes that are a bit less complex, and that are intentionally decoupled from the OS, and are largely self-contained. It is just the next step in the evolution - though I suspect it does mean Windows (or any other OS) becomes substantially less relevant to most people.

By itself, I'm not sure that a runtime that is less coupled to the OS would be enough to drive Silverlight’s future. But there's another dynamic here too: the aging of the web, and the search for "what's next".

I was subscribed to the Usenet newsgroups in the early 90's, when they were discussing the future of the global network. When WAIS, Gopher and HTTP were competing (Gopher came from Minnesota after all : ) ). And HTTP/HTML won, because they really were the superior document viewing technology. A global version of lex; something that should have filled the role of PDF.

But as we got into the mid-90's, people started bastardizing and hacking this technology. Warping it into something far different from its original intent. And that's OK - but it is important to realize this was done ad-hoc, with little or no pre-planning or thought of proper architecture.

I know, I sound like a CS purist, but really the web, as we know it, is a stack of horrible hacks, all leaned up against each other like the world's biggest and most expensive house of cards. In short, the technology of the web is a mess. Just witness the insanity around browser versions,  the standards compliance farce, and the ridiculously inefficient ways we waste time/money building a web app that runs on more than one version of even one browser.

Yes, the web has transformed the world. And it revealed some very good patterns for software and usability. But it became mainstream over 10 years ago, and most technologies fade gracefully away at the 10 year mark. So it is time for the web (as we know it) to die.

The question then, is what comes next? Do browsers become the new standards-based OS? Or do we extend the runtime concept into the web, as a long-term replacement.

Google is betting on the former, with Gears and Chrome. They clearly hope/expect that the browser itself will be the next OS - the thing that makes Windows and Mac OSes irrelevant. Adobe is betting on the latter. They clearly hope Flash/Flex/Air will be the runtime that makes both the browser and the OS irrelevant.

Microsoft is playing a smart game, imo. Silverlight (with Mesh and Azure) represents a strategy very similar to Adobe's (but bigger), where a runtime may well make the browser and the Windows/Mac/Linux desktop irrelevant. At the same time, they've got WPF as a fall-back in case the core OS does remain important to the average consumer.

So I think these two dynamics - the desire by our customers to escape the shackles of the OS (not just Windows - the OS in general), coupled with the fact that the industry is looking for the next step in the evolution of the web itself - work together to make this the perfect time for Silverlight to be the hot technology.

And I do think this works against WPF, because it neither helps us escape the OS, nor does it represent the future of the web. And it works against Adobe, because their vision isn’t big enough, nor their established developer base large enough. And against Google, because they are still trying to shape the stack of hacks that is the browser into something reliable, and I suspect that’s simply unrealistic.

In short, I think Silverlight offers the power needed for smart client business apps, with the best deployment and navigation characteristics of the web. Sure, it needs to continue to grow and evolve (the search issue needs addressing for example), but I really think Silverlight represents the future of development for most of us.

Thursday, February 5, 2009 4:15:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

It has been a month and a half since the release of CSLA .NET 3.6, which was the first release of a major .NET development framework to include Silverlight support.csla_logo1_72

Today I am releasing version 3.6.1 for Windows and for Silverlight. This point release addresses several bugs and issues with 3.6.0, and should include no breaking changes. I recommend that all 3.6 users upgrade to 3.6.1.

You can review the CSLA .NET for Windows change log, and the CSLA .NET for Silverlight change log to get an overview of the fixes and changes.

Some enhancements of note on the Windows side include:

  • The use of “_forceInit” to trigger static field initialization is no longer required
  • Add methods to the ObjectFactory base class to make it easier to build a DAL using ObjectFactory
  • Allow resetting the proxy type used by the data portal, and allow setting the proxy type through code, to make it easier to change the data portal configuration at runtime

Some enhancements of note on the Silverlight side include:

  • The use of “_forceInit” to trigger static field initialization is no longer required if your PropertyInfo<T> fields are declared public in scope
  • The data portal WcfProxy now has better support for various configuration and subclassing options
  • MobileFormatter now supports the DateTimeOffset type

Though 3.6.1 includes these enhancements, the primary focus is on addressing a few bugs and issues that have been discovered in 3.6.0. Whether you need these enhancements or not, you will benefit from the bug fixes.

 

On a related note, I have refreshed the pre-release of 3.5.3, which includes some important bug fixes for the 3.5.2 version. If you are using 3.5.2, I strongly suggest you evaluate 3.5.3 to see if it addresses any issues you are facing. Version 3.5.3 is a “floating test release”, which means it is stable, but will continue to be a catch-all for reported bugs over the next few weeks. You should strongly consider using 3.5.3 if you are facing any of the bug fixes it contains.

As Microsoft rolls out .NET 3.5 SP1 via Windows Update, it is my intent to stop supporting the 3.5.x version, as all 3.5 users should be able to move to 3.6.x. That’ll get me down to dealing with just four versions:

  1. 3.6.x for Windows
  2. 3.6.x for Silverlight
  3. 3.0.x C#
  4. 3.0.x VB

I expect 3.5.3 to be the final release of the 3.5 code line, and I expect that’ll happen sometime in March.

Thank you for using CSLA .NET, see you on the forum!

Thursday, February 5, 2009 1:40:25 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, February 3, 2009

I recently installed the latest version of IE8, bowing to pressure from some of my Microsoft colleagues :)

I don’t regret the decision! IE8 is easily as fast as FF3, and has a lot of really nice, often subtle, features that make it far more useful than IE7.

I was rather excited when I first went to my home page (www.lhotka.net), because it rendered correctly. This page renders nice in FF2, FF3 and now IE8. But it never quite worked right in IE7. I was never able to justify the (probably many) hours it would take to troubleshoot the css. Just getting my site working as well as it does was enough to turn my antipathy toward web UI work into tangible dislike.

(I know some people enjoy web UI work. I’ve only found it to be one of the most frustrating experiences in all the years I’ve been programming… Seriously – could we have invented anything more arcane??)

Anyway, my home page renders nicely in IE8, so I’m excited.

Until I try to navigate using one of the drop-down menus. All that appears is a while box! How can IE8 not render an ASP.NET Menu control?!?!?!?!?!

Well, it turns out that this is a known issue that the IE8 and ASP.NET teams are working on. It also turns out that it is apparently a z-order issue with the Menu control and the way it renders, so it can be argued that IE8 is actually doing the “right thing” (even though other browsers, including FF3 render the way I’d expect).

In talking to Joshua, Brad and Giorgio at Microsoft a workaround came to light, and Giorgio blogged the ASP.NET Menu control workaround.

I just had time to try this on my site. I’ll save you the suspense and say that it now does render correctly :)

In my case, I’m using themes and skins, and so I am using a css style to fix the z-order.

To do this, I added the workaround to my site-wide css style sheet:

.IE8Fix
{
    z-index: 1000;

}

And then I edited my skin file to apply this style to all my Menu controls:

<asp:Menu runat="server" BackColor="#83B8E4"

...
  <DynamicMenuStyle BackColor="#B5C7DE" CssClass="IE8Fix" />
...

</asp:Menu>

This was easy for me, because I already had the skin set up to apply numerous other properties and styles to the elements of the Menu control. I simply added the CssClass property to the existing DynamicMenuStyle element.

I published the project to my web server and just like that my Menu control is displaying correctly in IE8.

Web
Tuesday, February 3, 2009 9:54:59 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 28, 2009

Dunn Training is offering a five day CSLA .NET in-depth training class May 4-8 in San Francisco.

Click for details about the CSLA .NET Master Class.

Wednesday, January 28, 2009 11:01:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

This is one tip that any WPF or Silverlight developer can’t be without. Talk about instant gratification!

http://weblogs.asp.net/fmarguerie/archive/2009/01/29/life-changer-xaml-tip-for-visual-studio.aspx

I wish I’d known about this months ago.

Wednesday, January 28, 2009 10:59:24 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I just ran into an odd “feature” of Silverlight data binding, that I assume must actually be a bug.

I have an object with a string property that has a public get, but private set:

public string Name
{
  get { return GetProperty(NameProperty); }
  private set { SetProperty(NameProperty, value); }
}

You would think that no code outside the business class could call the set block, because it is private. Certainly in .NET this would appear as a read-only property to any code outside the class.

But in Silverlight, data binding is perfectly capable of calling this code. Worse, the reflection PropertyInfo object for this property returns true for CanWrite, so this appears as a read-write property to any code.

I don’t think the problem is in the C# compiler, because if I write code that tries to set the property I get a compile-time error saying that’s not allowed.

Also, it isn’t a problem with reflection, because trying to set the value using the SetValue() method of a PropertyInfo object fails with the expected MethodAccessException (Silverlight reflection doesn’t allow you to manipulate private members). This, in particular, is weird, because if CanWrite returns true it should be safe to write to a property…

Update: I just checked .NET (being the suspicious sort) and it turns out that CanWrite returns true for a read-only set block in .NET too. And of course reflection won't set the property due to the scope issue, just like SL. But WPF data binding also doesn't call the private set block, where Silverlight somehow cheats and does call it - so at least the scope of the issue is narrowed a bit.

Which begs the question then: how is data binding bypassing the normal property scope protections so it can manipulate a private member? With the next question being how can I do it too? :) 

Seriously, this is the first time I’ve found where Microsoft has code in Silverlight that totally bypasses the otherwise strict rules, and it is a bit worrisome (and a pain in the @$$).

Anyway, the workaround at the moment is to use the old-fashioned approach and create a separate mutator method:

public string Name
{
  get { return GetProperty(NameProperty); }
}

private void SetName(string value)
{
  SetProperty(NameProperty, value);
}

This works, because when there’s no set block at all the property is actually read-only to everyone, inside and outside the class. Kind of inconvenient for the other code inside the business class that wants to set the property, because that code must use this non-standard mutator method – but at least it works…

Wednesday, January 28, 2009 3:35:02 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, January 23, 2009

For some years now there’s been this background hum about “domain specific languages” or DSLs. Whether portrayed as graphical cartoon-to-code, or specialized textual constructs, DSLs are programming languages designed to abstract the concepts around a specific problem domain.

A couple weeks ago I delivered the “Lap around Oslo” talk for the MDC in Minneapolis. That was fun, because I got to demonstrate MSchema (a DSL for creating SQL tables and inserting data), and show how it can be used as a building-block to create a programming language that looks like this:

“Moving Pictures” by “Rush” is awesome!

It is hard to believe that this sentence is constructed using a programming language, but that’s the power of a DSL. That’s just fun!

I also got to demonstrate MService, a DSL for creating WCF services implemented using Windows Workflow (WF). The entire thing is textual, even the workflow definition. There’s no XML, no C#-class-as-a-service, nothing awkward at all. The entire thing is constructed using terms you’d use when speaking aloud about building a service.

A couple years ago I had a discussion with some guys in Microsoft’s connected systems division. My contention in that conversation was that a language truly centered around services/SOA would have a first-class construct for a service. That C# or VB are poor languages for this, because we have to use a class and fake the service construct through inheritance or interfaces.

This MService DSL is exactly the kind of thing I was talking about, and in this regard DSLs are very cool!

So they are fun. They are cool. So why might DSLs be a bad idea?

If you’ve been in the industry long enough, you may have encountered companies who built their enterprise systems on in-house languages. Often a variation on Basic, C or some other common language. Some hot-shot developer decided none of the existing languages at the time could quite fit the bill. Or some adventurous business person didn’t want the vendor lock-in that came with using VendorX’s compiler. So these companies built their own languages (usually interpreted, sometimes compiled). And they built entire enterprise systems on this one-off language.

As a consultant through the 1990’s, I encountered a number of these companies. You might think this was rare, but it was not all that rare – surprising but true. They were all in a bad spot, having a lot of software built on a language and tools that were known by absolutely no one outside that company. To hire a programmer, they had to con someone into learning a set of totally dead-end skills. And if a programmer left, the company not only lost domain knowledge, but a very large percentage of the global population of programmers who knew their technology.

How does this relate to DSLs?

Imagine you work at a bio-medical manufacturing company. Suppose some hot-shot developer falls in love with Microsoft’s M language and creates this really awesome programming language for bio-medical manufacturing software development. A language that abstracts concepts, and allows developers to write a line of this DSL instead of a page of C#. Suppose the company loves this DSL, and it spreads through all the enterprise systems.

Then fast-forward maybe 5 years. Now this company has major enterprise systems written in a language known only by the people who work there. To hire a programmer, they need to con someone into learning a set of totally dead-end skills. And if a programmer leaves, the company has not only lost domain knowledge, but also one of the few people in the world who know this DSL.

To me, this is the dark side of the DSL movement.

It is one thing for a vendor like Microsoft to use M to create a limited set of globally standard DSLs for things like creating services, configuring servers or other broad tasks. It is a whole different issue for individual companies to invent their own one-off languages.

Sure, DSLs can provide amazing levels of abstraction, and thus productivity. But that doesn’t come for free. I suspect this will become a major issue over the next decade, as tools like Oslo and related DSL concepts work their way into the mainstream.

Friday, January 23, 2009 5:30:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

One of my kid’s machines just died – hard drive crash. In the past, this has been a pain, because I’d have to reinstall the OS (including finding and installing all the drivers) and he’d have to reinstall all his games, find the keys, all that stuff. It could literally take days or weeks to get the computer back to normal.

However, a few months ago I picked up the HP Windows Home Server appliance. It does regular (at least weekly, if not daily) automatic image backups of all the machines in my house. I bought it because a couple colleagues of mine had machines crash and they were singing the praises of WHS in terms of getting themselves back online quickly and easily.

I am now officially joining the chorus!

Here’s what I did: Pop out the bad hard drive, and put in an empty new one. Boot off the system rescue CD, walk through a simple wizard, wait 90 minutes for the restore and that’s it – he’s totally up and running as though nothing happened. Better actually, because this new hard drive is 3x bigger than the original – WHS simply restored to the new, bigger, drive without a complaint.

I guess it can be a little more complex with nonstandard network or hard drive drivers (How to restore a PC from a WHS after hard drive fails), but even that doesn’t look too bad. But in my case, WHS found the hard drive and network card automatically, so it was a total no-brainer.

The thing is, I’m not used to computers acting like or being like an appliance. But the HP WHS box really is an appliance – the kind of thing a regular home user could install. The machine comes with a fold-out instruction poster. 6 steps to install (things like “plug in power”, “plug in network”, “push on button”, etc). And it does these automatic backups, in a way where it deals with increasing volumes of data by warning you BEFORE the server runs out of space (unlike Vista’s built-in backup, which is terrible).

Start running out of space? Just pop in a new hard drive – without even shutting down the server. I’ve added two since I got the box. All PCs should work this way!!

The backups appear to be very smart. I’m backing up numerous machines, and the total backups are using less space than if you add all the backed up content together. I assume they are using compression, but I also think they are doing smart things like not backing up Windows XP and Vista each time, because those are the same across numerous machines. As are many of the games played by I and my kids.

What’s even better, is that WHS does video and audio streaming. I’ve been putting all our media on the box, and watching it from the xbox or media PC in other rooms.

There are more features, but I don’t want to sound like a spec sheet.

The point is that I’ve been entirely impressed by the simplicity and consumer-friendliness of this product since I took it out of the box (did I mention it is a really nice-looking mini-tower?). The fact that the computer restore feature works exactly as advertised is just further confirmation that it was a great purchase.

I seriously think that every home that has one or more computers with any data that shouldn’t be lost needs a WHS. Yes, that probably means you! ;)

Friday, January 23, 2009 3:35:40 PM (Central Standard Time, UTC-06:00)  #    Disclaimer