Many of you know that I’ve been a big advocate of smart client applications and whenever possible to avoid building complex interfaces in HTML and rather rely on rich client applications that communicate over the Web using Web Services or raw XML interfaces.

While I think the tools to do this are out there I also think that we’re a long way off from making this a reality. Microsoft is trying really, really hard to make .Net sound like the solution to the HTML vs. smart client dilemma by trying to make .Net Windows Forms application act like Web applications from a deployment perspective.

In theory this sounds really cool: You have a rich client application that downloads and then runs locally with all the power of the client available. You get rich graphics, all the UI toys you want (drag and drop, rich data representations, toolbars, imagelists, trees)  and most importantly you can properly cache data without having to worry extensively about the stateless nature of Web Development. It’s infinitely easier to build complex and good looking UIs with WinForms than with Web forms.

To facilitate this process Microsoft has made creating and consuming Web Services in .Net very straight forward (to the charign of some of the original XML purists who hate the RPC model) and have provided what Microsoft calls the ‘one click deployment’ model.

And here is exactly where things start to get tricky. The concept of one click deployment is straight forward and logical. The idea is that you can launch a smart client app directly off a Web Url just like you can a Web page. You simply point at an EXE on a Web Server and the EXE downloads and installs and then runs locally. Next time you run this same application you go back to the same URL and the application runs either from the Internet Explorer Cache or if it has been updated or the cache expired/cleared a fresh version is downloaded. If your app contains satellite assemblies that get loaded as the app runs they get downloaded as well.

So far this sounds awesome. You get a desktop application that gets most of the benefits that a Web application offers – always up to date and automatically installed without actually installing anything locally (app really installs into the cache).

But there’s a catch. A really big catch: The catch is security. When you download and run an application in this fashion the application is seriously limited in what it can do. And rightly so – you wouldn’t want your (not so) favorite porn site that you ‘accidentally’ ended up on to automatically redirect you to such an auto-install URL and install some nasty screen saver you will never be able to uninstall again, right?

Security is a fact of life, but it’s a double-edged sword. With .Net and one-click deployment the problem is that automation of this step is next to non-existent, which means you pretty much have to manually set the security setting using either the CASPOL command line tool (yeah, right) or by using the .Net Configuration tool. The process involves giving the URL or Web site rights to allow execution of the appropriate code. For any application that wants to anything a typical business application needs to do this most likely means assigning full trust to the application’s URL.

As of right now the problem is that you can’t easily automate this process and certainly not for an application that comes down over a URL. Fully installed applications can choose to ship a ‘Security policy’ along with the application, but this process is very limited (at least from the default policy configuration tools) as it takes an all or nothing approach. And it cannot be used for a Web run application because there’s no place where you can ‘hook’ the policy installation – the app itself has no rights to do this.

For an excellent introduction to auto-deployment of an application through a URL check out Hector Correa’s article in Code a while back.

So, this leaves having to either pre-configure a computer manually using the .Net tools (or a third party tool) or downloading and installing a policy file. So now we’re really back to downloading something in order to establish trust – kind of the same scenario we had with ActiveX controls in the browser where you had to approve of whether you want to install something.

Even with the manual process you can often get into trouble due to permissions related to satellite assemblies. One major example of the trouble I’ve personally had with this is with Microsoft’s own GotDotNet Workspaces site.  GotDotNet Workspaces provides a source code store for .Net applications that are shared source. It’s Microsoft’s answer to SourceForge. It’s a great idea to help build community and get people to share code – there’s a lot of great stuff available to get access to and if you so choose participate in.

However, the whole thing hinges on Web hosted .Net applications. One is a Visual Studio plug-in and the other is a Windows Form application, both of which require Web access to communicate with the GotDotNet source system.

I, and apparently countless others that post messages in the GotDotNet support forums, have had major problems getting the applications to run properly. The installers are supposed to install security policies (automatically? You gotta wonder about the arrogance in that!!!)  which actually never did get installed. I had to manually make the changes to set trust to the GotDotNet site. But then, even with full trust assigned I had been unable to get either the VS plug in or the Windows form application to run.

When I went to GotDotNet I had a real need for one of the projects and because the projects wouldn’t load I was now locked out. There’s no alternative to get this content.

It turns out the problem was caused by multiple versions of the .Net framework installed. I have the Whidbey build installed so even though I configured the version 1.1 of the .Net framework I didn’t configure 1.2 which is what the code was actually running. I was lucky to catch that particular error because the site actually echos back the error message. I then manually changed the security settings for Version 1.2 of the framework and I got past the security error – followed by another non-security failure most likely because there’s a compatibility problem in runtime versions.

So how do I get GotDotNet to run on this machine? Answer from Tech support: Uninstall V 1.2 of the framework. Ok, how’s that for DLL hell??? It cracks me up – this is exactly the sort of thing .Net was supposed to avoid, but here we are again where a newer version of the framework is actually messing with an install of a tool that needs to run on a lower version. So much for version compatibility.

Does this sound like fun? Now imagine you’re a typical end user just trying to use an application and get her work done! Obviously we still have a ways to go before smart clients are as easy and self-configuring as Web applications…