This article examines the implementation of upload and download functionality with progress indication (progress bar feature) using the Windows Communication Foundation. For this sample, you will need Visual Studio 2008.
The sample code consists of three projects bundled in a solution. A brief description of these projects follows. The attached sample code is available in C# and VB.NET (conversion to VB.NET was made by Lee Galloway of Project Time and Cost).
This is the main server project.
The Server Contract
The File Server project includes FileTransferServiceContract.cs file, which contains the
IFileTransferService interface. This interface describes the operations provided by our server. No actual work is done in this code file except in describing the operations provided. If you've worked with service-oriented applications before, you'll 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
DownloadRequest instance that contains the name of the file to be downloaded by the client. It 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
length are marked with the
MessageHeader attribute in the
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 as used in
DownloadFile, only in this case the
length property is not required.
public interface IFileTransferService
void UploadFile(RemoteFileInfo request);
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;
<servicecontract() />Public Interface IFileTransferService
Sub UploadFile(ByVal request As RemoteFileInfo)
Function DownloadFile(ByVal request As DownloadRequest) As RemoteFileInfo
Public Class RemoteFileInfo
Public FileName As String
Public Length As Long
Public FileByteStream As System.IO.Stream
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 that 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 the
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. An elegant approach was suggested by Buddhike. To do this, the
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.
FileService is a class library and hence it cannot start as a window process. Therefore it needs another executable file-process that will host it. Several types of processes can host a WCF service, such as .NET executables, IIS processes, Windows Activation Services (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. It 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 online 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
Console.WriteLine("This is the SERVER console");
foreach (Uri address in myServiceHost.BaseAddresses)
Console.WriteLine("Listening on " + address.ToString());
Console.WriteLine("Click any key to close...");
Public Shared Sub Main()
Dim myServiceHost As New ServiceHost(_
Console.WriteLine("This is the SERVER console")
For Each address As Uri In myServiceHost.BaseAddresses
Console.WriteLine("Listening on " + address.ToString())
Console.WriteLine("Click any key to close...")
The configuration of
ConsoleHost is what matters the most! It is divided into three sections, configuring 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 the configuration of our service is that it 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"
Client project is a sample consumer of our service. You will notice that the
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." The files in this folder are the proxy of our file transfer service on the client side.
Client is using these files to send requests to the server, hiding in 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 for one small part, which is also the difference in implementing the progress indication when uploading rather than when downloading. When downloading, the client has control of the procedure. You can see in 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 remain. When uploading, that loop resides on the server. In order for the client to know how many bytes the server read, it uses the
StreamWithProgress class, which inherits
System.IO.Stream. An instance of this class is passed to the server, instead of the original file stream. Since this class overrides the default
Read method of the stream (see code below), it can report the progress of the uploading process to the client!
int Read(byte buffer, int offset,
int result = file.Read(buffer, offset, count);
bytesRead += result;
if (ProgressChanged != null)
ProgressChanged(this, new ProgressChangedEventArgs(bytesRead, length));
Public Overloads Overrides Function Read(ByVal buffer As Byte(), _
ByVal offset As Integer, ByVal count As Integer) As Integer
Dim result As Integer = file.Read(buffer, offset, count)
bytesRead += result
RaiseEvent ProgressChanged(Me, New ProgressChangedEventArgs(_
- Updated on 2007/09/09: A more elegant approach for the server implementation was suggested by Buddhike.
- Updated on 2007/10/24: Code now also provided in VB.NET. Conversion made by Lee Galloway of Project Time and Cost</a />.
- Updated on 2009/02/03:
- Upgraded projects to Visual Studio 2008 (.NET Framework 2.0 is still the target framework).
- Properly closing read stream on client when download is done. Failure to do this was causing the client to throw timeout exceptions after 2 or 3 downloads.