If null is returned, this indicates that an error has occurred.

If you pass a callback method to the asyncCallback parameter of this method's corresponding BeginUploadFile method, you must call this method in the passed callback. If you pass null to the asyncCallback parameter (or call a version of BeginUploadFile that has no callback parameter), a default callback is used in which the appropriate "End" method is called. In this case, you must not call EndUploadFile yourself; otherwise, an exception will be thrown.

This method should be used in conjunction with the static versions of BeginUploadFile.

The HttpWebResponse object returned when the method is successful holds network resources. You must call the HttpWebResponse.Close method to close the response stream and release the connection. Failing to do so may cause your application to run out of connections.

If an error has occurred during the upload operation, an exception corresponding to that error will be thrown when you call this method. A common exception will be System.Net.WebException. You can check the Message and Status properties of the exception to get details about what happened.

If you enable unlimited uploads (see Uploading Unlimited Amounts of Data in a Single Operation), which causes the component to use the internal XceedHttpWebRequest class, but neglect to properly configure the server as described in the Setting Up IIS 6.0/ASP.NET to Receive Unlimited Uploads topic, a WebException will be thrown with the Status property set to WebExceptionStatus.ConnectFailure.

Furthermore, when unlimited uploads are enabled, the HttpWebResponse object returned by this method is Xceed's implementation, not Silverlight's. The stream returned by HttpWebResponse.GetResponseStream is also implemented by the component.

Finally, when unlimited uploads are enabled, and only then, the Stream.Read method from the response's stream cannot be called on the main application thread. You must instead use BeginRead/EndRead. This is because the Socket class that is used internally needs to perform its asynchronous operations on the main application thread (probably because it needs to communicate with the Web browser). Stream.Read would need to block, waiting for the Socket object to complete, which would never happen because control of the main thread would never return to Silverlight or the Web browser, resulting in a deadlock. Xceed's internal implementation of Stream.Read detects whether it is called from the main thread and will throw an InvalidOperationException. You need to work asynchronously and call BeginRead/EndRead and let program control return to Silverlight and supply a callback method with BeginRead.

This method can be called from the main application thread or a background thread.