Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 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  |  Comments [0]  | 
 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  |  Comments [0]  | 
 Thursday, February 05, 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 05, 2009 9:16:16 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

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 05, 2009 4:15:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

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 05, 2009 1:40:25 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, February 03, 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 03, 2009 9:54:59 AM (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