Saving a file to the local disk in Silverlight

All user code in Silverlight runs in a sandbox. Hence, for security reasons, there are no APIs to directly open local files from disk. However, there is a OpenFileDialog class which allows a Silverlight app to open files on disk. Human intervention is required to interact with the dialog box. This ensures that the user trusts the app to open the files selected in the dialog box.

However, currently there is no equivalent to writing to a file to disk, even if the user wants to allow such an operation. This is unfortunate. If you implemented a text or image editor in Silverlight, the user would not be able to save the edited file to disk. However, there is a workaround - but at the cost of extra network traffic. The solution involves the following steps:

  • The Silverlight client app running in the browser sends the data that needs to be saved to disk to the web server using a POST operation using System.Windows.Browser.Net.BrowerHttpWebRequest::GetResponse

  • The web server saves the data to a temporary file and returns a URL for the temporary file in the response

  • The Silverlight client app reads the URL that is returned in the System.Net.HttpWebResponse object.

  • It navigates to the URL using System.Windows.Browser.HtmlPage::Navigate.

  • This will result in the browser invoking the default action for the given file type. This is often to prompt the user to save the file to disk. If the browser opens the file directly, the user could then have the browser save the file to disk. If multiple files need to be saved, the web server could save them all in a zip file using System.IO.Compression.GZipStream.

This solution is obviously not ideal as it result in unnecessarily sending the data back and forth over the network. For large files, this could be prohibitive. For small files, its a reasonable solution until there is a SaveFileDialog API in Silverlight.

I do not know if there will be a SaveFileDialog in Silverlight 1.1, but I hear that the Silverlight team is looking into it...

Comments (7)

  1. jackbond says:

    I’ve made a few posts on the forums regarding the lack of a FileSaveDialog that would allow the user to be prompted for a path outside of protected storage. Ideally, once the user provided the path, an output stream would be returned to the caller. There are tons of applications, in addition to the text or image editors that you mentioned, that could use this feature.

  2. shrib says:

    Yes, I agree that save functionality would be quite useful. Will pass along the comment to the Silverlight team

  3. 花间蕊 says:

    SavingafiletothelocaldiskinSilverlight AllusercodeinSilverlightrunsinasandbox.H…

  4. 花间蕊 says:

    SavingafiletothelocaldiskinSilverlight AllusercodeinSilverlightrunsinasandbox.H…

  5. Since XP SP2 IE blocks the automatic presentation of the Save As dialog box for anything but when the user directly clicks on an element. IE doesn’t treat (as it shouldn’t) the call to System.Windows.Browser.HtmlPage::Navigate from Silverlight as a direct user click, so it show’s a warning bar on the top of the screen. The onerous problem is that it refreshes the page when you click on the bar. This makes sense for an HTML page but sucks for a LOB app written in Silverlight (returning the user to the login page in my case.)

    Furthermore it doesn’t remember the user’s setting on a site by site basis (as is available for the pop up blocker.) You can of course change the settings for IE, but this is beyond most of my users (in fact some of them won’t have the authorisation to change these settings.)

    So I really really want a Save as Dialog box like the Open As dialog box from which I could stream a file to disk with. But I’d settle for a button which encapsulated the whole thing and just saved a file to disk from a server.

    The former is better for me because I can do clever things like decrypt the file in Silverlight using a private key which is never sent to the server etc. I think if you only allow the Save As Dialog from a direct user click then it’s more secure than all these hacks people will resort to in future.

Skip to main content