Silverlight gets the local physical path of the selected file

Recently in making a large file breakpoint continuation of the control, have tried pure C # code to write, but later found to be too inflexible, so consider using the control. However, in the process of control development, it is a big problem to get the physical path of uploading a file, because Silverlight does not support getting the client path, not only Silverlight, but all Microsoft upload controls do not support getting the local physical path. So I looked at the various, and finally found that there is a way to get information about the file.

Let's look at an example.

1 #regionSelect File2 Private voidBt_selectfile_click (Objectsender, RoutedEventArgs e)3 {4OpenFileDialog OFD =NewOpenFileDialog ();//Initialize5Ofd. MultiSelect =true;//settings can be multi-select6Ofd. Filter="Please select File | ' * '";//limit file types and hints7     if(OFD. ShowDialog () = =true)8     {9         foreach(FileInfo fileinchOFD. Files)Ten         { OneUserFile UserFile =NewUserFile ();//Custom File upload information class AUserfile.filename = file. Name;//Get file name -Userfile.filestream = file. OpenRead ();//open a file in read-only mode -Userfile.filephysicalpath = file. FullName;//gets the full path name of the directory or file when called by a trusted application theUserfile.filetime = file. LastWriteTime;//gets the last modified date of the file when called by a trusted application -         } -     } - } + #endregion

Select File

In fact, when we debug, we find that Userfile.filephysicalpath = file. FullName; Userfile.filetime = file. LastWriteTime; These two lines of code will be reported as an error, prompting the discovery of non-debug exceptions. This is because Silverlight does not allow access to the client's files under the Microsoft package, how to solve it? In fact, in the newly released version of SILVERLIGHT5, Microsoft allows developers to gain access to local file operations internally by increasing the trust of the application.

Right-click on the properties of our Silverlight project, under the Silverlight column, we can see

Tick "trust that requires promotion when running in the browser" so that we can manipulate the local files!

Here's a description of what Microsoft did after the tick, because sometimes we checked or couldn't get the path to the file.

When you tick "trust that requires elevation when running in the browser," Visual Studio does the following:

1. Add content to the Silverlight project file (. csproj):<requireinbrowserelevation>true</requireinbrowserelevation>

2. Add a file to the Properties folder of the project: Inbrowsersettings.xml.

3. Add content in the Silverlight project file (. csproj): <inbrowsersettingsfile>properties/inbrowsersettings.xml</ Inbrowsersettingsfile>

See my other article for details Silverlight controls-how to improve application trust and problem resolution

Now we can get the path to the file when debugging.

All right, let's send the project to the server to see it, eh? How can you not get it? This is because debugging is local, but not on the server, after the Internet access, that is, this is a cross-domain behavior. Smart you must have thought of it, yes, we are writing a script that can be accessed across domains. It's really simple, look underneath.

Create a clientaccesspolicy.xml under our web project with the following code:

1<?xml version="1.0"encoding="Utf-8"?>2<access-policy>3<cross-domain-access>4<policy>5<allow- fromhttp-request-headers="*">6<domain uri="*"/>7</allow- from>8<grant-to>9<resource path="/"include-subpaths="true"/>Ten</grant-to> One</policy> A</cross-domain-access> -</access-policy>

ClientAccessPolicy.xml

Save the ClientAccessPolicy.xml file to the root directory of the domain that hosts the service. For example, if the service is hosted on http://fabrikam.com, the file must be located in Http://fabrikam.com/clientaccesspolicy.xml.

In addition, create a crossdomain.xml with the following code:

 1  <?xml version= " 1.0  ? >2  <! DOCTYPE cross-domain-policy SYSTEM  http:// WWW.MACROMEDIA.COM/XML/DTDS/CROSS-DOMAIN-POLICY.DTD   >3  <cross-domain-policy>4  <allow-http-request-headers-from  domain= *   " Headers="  *   "/>5  </cross-domain-policy> 

Crossdomain.xml

Save the Crossdomain.xml file in the root directory of the domain hosting the service. For example, if the service is hosted on http://fabrikam.com, the file must be located in Http://fabrikam.com/crossdomain.xml.

For details, see making services available across domain boundaries

Now we can open the website in other computers to enter the URL, get to our local file path.