So in the previous article I discussed what you can do today to run your Silverlight application independent of your web server. These were running your Silverlight application from the file system, or running a Silverlight application Offline.
In this post I am going to talk about the crazy thinking I had when responding to a post today.
Simple Web Server
My idea is quite simple. Essentially if you can run your application locally on local web server then you will have full access to network capabilities (WebClient, WCF etc). This means you will be able to make cross domain calls to local or non local servers. You will also be able to make socket calls to local or non local servers.
As was pointed out in the web server you could run cassini on the local machine but this is a little over the top.
Mega Simple C# Web Server
All we really need is a very simple socket server, which will spew out some http from a web request from IE.
Therefore we could have a little application which we associated with the .XAP file extension, which launches a simple web server process and then calls IE pointing it to our simple web server. Once the html page has been served we can trash the simple web server process and your application now runs on the desktop.
Cross Domain Access
Because our application is essentially an online application (came from a web server you know), we can talk to any web server / (socket server) which allows us via cross domain policies. Lots of Digg clients can be made yay, or when Beta 2 can talk to the new crossdomain.xml format then Yahoo Search etc will be supported.
Local Services
Not only can we talk to internet services but we can talk to intranet WCF / Socket Services (using crossdomain). This means you could potentially have local print services, file services which expose the file system, talk to a time service, talk to your build server, TFS, SQL Server anything really. For sockets (you may need to create a virtual socket due to the port range supported).
Anyways that was my crazy thinking for the day. I haven't written any code to validate this but there is no reason why it wouldn't work in principal. May'be I will have time to play with it one day, or may'be you will.
11 comments:
I'm just hosting in a WinForm's browser object so I get the Silverlight UI, with the power of .net 2.0 api. This way I do not need a web server on client and it works on windows 2000.
,,,Bydia
You probably wouldn't have to spawn a process to be the simple web server, it could probably just be a thread. You could pass the port number in some thread safe storage.
Bydia,
Interesting stuff. V.Cool.
Bill,
I like your suggestion, it really improves the idea. :)
It's a dream, but could it be possible to make a "wrapper" to run SL application directly on .net framework in a wpf application ?
With Bydia's solution, the SL component couldn’t talk directly with his hosting wpf application...
Jean-Philippe
The WinForm can call javascript methods directly in the browser object and access the html dom object for html manipulation. Which means that one could get a handle to the silverlight object and access it's objects too. I have yet to try this. Also, since Silverlight can call javascript methods... then it should be able to call WinForm methods... since javascript methods can. So should be able to have 2 way communication. The WinForm can help us get by Silverlight limitations and have silverlight give us rich media on systems that can't run WPF (like Win2000)
Hi,
For Windows, you can host Silverlight in a HTA as use JavaScript as a bridge to full trust functionalities such as using the file system, etc...
http://blog.galasoft.ch/archive/2008/04/24/silverlight-running-standalone-full-trust-applications.aspx
About the other options: WPF's new WebBrowser (upcoming in SP1) will enable WPF to communicate with the hosted and to invoke JavaScript functions or access the DOM. This will allow existing Silverlight applications to be hosted standalone. I guess however that there will be a careful evaluation to be done and see if it's not better to just port the whole application to WPF instead.
Laurent
Thanks again for the comments. All very very cool stuff.
One of my main points however is to keep with a cross browser application. Really all I am doing is downloading any .xap file onto my desktop and running it (without any porting).
Anon, your Winform idea is interesing but I am effectively bypassing built in silverlight code and using winform to get round the limitations. So I would need to use winform even just to do network communication, whereas with the cutdown web server approach, all my existing silverlight code will just work. I would also be able to easily port the host code to the Mac, or Linux.
Laurent,
I really like your blogpost.
Your method with javascript seems a great way of elevating permission to access the hard disk.
I think I still prefer the idea of running a very mini web server. As I can run any .xap application on the desktop (as long as it has approriate cross domain support), without any coding from the silverlight application developer.
Where as with HTA you are still run by file system mode (and using javascript to get around this), which means the silverlight application has to code around this.
Very Very Cool Stuff however, as I say i like your articles very much, and there is some real interesting stuff that you do.
Thanks to all
(Merci Laurent ;o) )
But, using javascript to talk between the two world, humm how to say ... ;o)
(I will finally do this way anyway …)
My need (and dream) is to use the same component in an asp.net app and in a WPF desktop application, without rewriting the component.
I imagine a WPF component that embedded a SL component an run-it without having Silverlight on desktop computer
(Wrapping Silverlight class into .net 3.5 class…)
Maybe, it will be simplest to recompile a SL component in a WPF one, but I think is not very possible now in a real industrial development process, isn't it ?
Kaxaml uses: document.getElementById("SL").Content.Bridge.ParseXaml(xaml)
to insert xml into silverlight in WPF app.
,,Bydia
Post a Comment