UPDATE: For latest version of this article please refer to the related article on CodeProject. Please provide comments and questions there.
This article examines the implementation of upload and download functionality with progress indication (progress bar feature) using the Windows Communication Foundation. Here is a list of what you need:
Sample code consists of three C# projects bundled in a solution. A brief description of these projects follows.
FileService
This is the main server project.
The Server Contract
File Server project includes FileTransferServiceContract.cs file which contains the IFileTransferService. This interface describes the operations provided by our server. No actual work is done in this code file except from describing the operations provided. If you worked with service oriented applications before, you know that this job is important enough to spare a separate file for. Here are the two operations of our file transfer service:
- DownloadFile server method. Accepts a DownloadRequest instance which contains the name of the file to be downloaded by the client and returns a RemoteFileInfo instance, defined in the same code file. RemoteFileInfo contains the name of the file to be downloaded, the file stream and the length of the file in bytes. This instance of the RemoteFileInfo class will be used by the client to download the file. You notice that file name and length are marked with the MessageHeader attribute in RemoteFileInfo class. This is because when a message contract contains a stream, this can be the only body member of the contract.
- UploadFile server method. Accepts an instance of the RemoteFileInfo message contract. This is the same used in DownloadFile, only in this case length property is not required.
[ServiceContract()]
public interface IFileTransferService
{
[OperationContract()]
void UploadFile(RemoteFileInfo request); [OperationContract]
RemoteFileInfo DownloadFile(DownloadRequest request);
}public class RemoteFileInfo
{
[MessageHeader(MustUnderstand = true)]
public string FileName; [MessageHeader(MustUnderstand = true)]
public long Length; [MessageBodyMember(Order = 1)]
public System.IO.Stream FileByteStream;
}
The Server Implementation
File Server also includes the FileTransferService.cs code file which contains the implementation of the contract, i.e. the actual code that does all the work. Apparently the included class implements the IFileTransferService class which constitutes the service contract. If you have worked with streams before in .NET you will find out that the code the handles the stream and related information for upload or download is pretty straightforward. If you are new to .NET streams, please use google for a quick introduction.
Note here that since actual downloading of the file starts after the execution of DownloadFile method is completed (i.e. after the client gets the RemoteFileInfo instance returned by this method), the server must close the opened stream later, after the client completes the process. To do this, the WaitToClose method starts in a separate thread and queries the current position of the stream once in a while. If it detects that the position of the stream remains the same for some time (1 second in our sample code) this means that the client finished downloading, failed to do so or intentionally interrupted the procedure. In any case the stream should be closed. If not, the stream will remain locked and the corresponding file will be locked for writing. (Updated on 2007/09/09) A more elegant approache was suggested by Buddhike) To do this IDisposable interface is implemented by the RemoteFileInfo contract and the stream is disposed on the corresponding Dispose method. If this is not done the stream will remain locked and the corresponding file will be locked for writing.
ConsoleHost
FileService is a class library, hence it cannot start as a window process; therefore it needs another executable file-process that will host it. Several type processes can host a WCF service, such as .NET executables, IIS process, Windows Activation Service (new feature of Vista) and many more. Our example uses a .NET executable to host our service. So ConsoleHost is a console application that does exactly this. Is has a reference to the FileService project, however it is not related in any way with the business our service is doing, i.e. transferring files. Actually the code you will find in Program.cs would be the same even if our service was designed to host an on-line grocery. Take a quick look at this code file to understand how our service is started and closed.
static void Main(string[] args)
{
ServiceHost myServiceHost =
new ServiceHost(typeof(FileService.FileTransferService));
myServiceHost.Open(); Console.WriteLine("This is the SERVER console");
Console.WriteLine("Service Started!");
foreach (Uri address in myServiceHost.BaseAddresses)
Console.WriteLine("Listening on " + address.ToString());
Console.WriteLine("Click any key to close...");
Console.ReadKey(); myServiceHost.Close();
}
Configuration of ConsoleHost is what matters most! It is divided into three sections and configures the way our service will behave and how it will be exposed to the rest of the world. It is not the goal of this article to describe in detail how a WCF service is configured, so please refer to the WCF reference on MSDN for more information. Something noticeable in configuration of our service is that is uses MTOM as message encoding and stream as transfer mode. See also the maxReceivedMessageSize property. This defines the maximum size of messages transferred by our service. Since we are transferring files we want this property to have a large value.
<binding name="FileTransferServicesBinding"
transferMode="Streamed"
messageEncoding="Mtom"
maxReceivedMessageSize="10067108864">
binding>
Client
Client project is a sample consumer of our service. You will notice that Client project includes a folder called 'Service References'. This folder contains a bunch of files created automatically by Visual Studio, by right clicking on the Client project root and selecting 'Add Service Reference'. If you don't see this option apparently you haven't installed VS 2005 extensions for .NET 3.0. Please see the requirements at the top of this document. The files in this folder are the proxy of our file transfer service on client side. Client is using these files to send requests to the server, hiding this way the complexity of Web Service and SOAP protocols.
Again, if you have worked with streams before you will notice that things are pretty simple in the TestForm file, except one small part, which is also the difference in implementing the progress indication when uploading than when downloading. When downloading, client has the control of the procedure. You can see in the TestForm.cs that downloading is implemented using a loop that reads the server stream piece by piece. So the client knows what part of the server stream is read and how many more remains. When uploading, that loop resides on server. In order for the client to know how many bytes the server read, it uses the StreamWithProgress class which inherits the System.IO.Stream. An instance of this class is passed to the server, instead of the original file stream. And since this class overrides the default Read method of the stream (see code bellow), it can report to the client the progress of the uploading process!
public override int Read(byte[] buffer, int offset, int count)
{
int result = file.Read(buffer, offset, count);
bytesRead += result;
if (ProgressChanged != null)
ProgressChanged(this, new ProgressChangedEventArgs(bytesRead, length));
return result;
}
UPDATE: For latest version of this article please refer to the related article on CodeProject. Please provide comments and questions there.
Comments [0]