browse by category or date

WCF Service Application

This project type is a more proper ASP.NET web application project compared to WCF Service. More proper because first, it has a project file (.csproj). Second, it generates .dll files. Which means we will not include the source code when deploying the service.

Below is the structure of a brand new WCF Service Application project:

│   IService1.cs
│   Service1.svc
│   Service1.svc.cs
│   WcfServiceApplication1.csproj
│   WcfServiceApplication1.csproj.user
│   Web.config
│   Web.Debug.config
│   Web.Release.config
│
├───App_Data
├───bin
├───obj
│   └───Debug
│       │   .NETFramework,Version=v4.7.2.AssemblyAttributes.cs
│       │   DesignTimeResolveAssemblyReferencesInput.cache
│       │   WcfServiceApplication1.csproj.AssemblyReference.cache
│       │
│       └───TempPE
└───Properties
        AssemblyInfo.cs

To deploy the service, we first build the project, then publish it.

After we click Publish, Visual Studio will prompt us the publishing wizard. The wizard will first asks for the publish destination.

For flexibility, let’s choose publish to a folder. Enter the folder, then click Finish to complete the wizard.

Click the Publish button to publish the project:

Here’s how the publish output folder structure:

└───app.publish
    │   Service1.svc
    │   Web.config
    │
    └───bin
            WcfServiceApplication1.dll
            WcfServiceApplication1.pdb

Now let’s host this WCF Service Application in IIS. We can do so by creating a new Application (right-click on the Default Website, click “Add Application”)

Enter the alias, then point the physical path to the publish folder:

That’s it. The service is now accessible.

What about the Temporary ASP.NET Files? It’s slightly different compared to WCF Service website.

└───wcfapp
    └───0675c2d5
        └───d171ecc4
            │   preStartInitList.web
            │   service1.svc.cdcab7d2.compiled
            │
            ├───assembly
            │   ├───dl3
            │   │   └───3238ffdf
            │   │       └───aca18044_49c2d701
            │   │               WcfServiceApplication1.DLL
            │   │               __AssemblyInfo__.ini
            │   │
            │   ├───temp
            │   └───tmp
            └───hash
                    hash.web

Hopefully this will help us understand the difference and similarity between WCF Service and WCF Service Application project in Visual Studio. The similarity is both must served in IIS. The difference is WCF Service deploys the source code, the latter is deploying compiled binary.

Next post I will explore the most versatile among these three, WCF Service Library. Stay tuned! Cheers.

About Hardono

Howdy! I'm Hardono. I am working as a Software Developer. I am working mostly in Windows, dealing with .NET, conversing in C#. But I know a bit of Linux, mainly because I need to keep this blog operational. I've been working in Logistics/Transport industry for more than 11 years.

Possibly relevant:

WCF Service

WCF Service project type will create a ASP.NET website. Below is the folder structure of a brand new WCF Service project:

│   Service.svc
│   Web.config
│   Web.Debug.config
│
├───App_Code
│       IService.cs
│       Service.cs
│
└───App_Data

To host WCF Service, we can just create an application, then point it to the project’s folder.

How the project looks in a browser:

Whenever the service being called, .NET runtime will first check if there’s a change to the source code. If it is changed, the runtime will then compile the website. I found this out by monitoring Temporary ASP.NET Files (which is configurable from web.config):

<system.web>
	<compilation targetFramework="4.7.2" tempDirectory="D:\projects\wcf\WCFService1\WCFService1_Temp" /> 
</system.web>

Structure of Temporary ASP.NET Files (D:\projects\wcf\WCFService1\WCFService1_Temp)

└───wcfservice
    └───b4011030
        └───a40309e8
            │   App_Code.compiled
            │   App_Code.w2tcshyi.dll
            │   preStartInitList.web
            │   service.svc.cdcab7d2.compiled
            │
            ├───assembly
            │   ├───dl3
            │   ├───temp
            │   └───tmp
            └───hash
                    hash.web

Simple console program consuming the service:

D:\projects\wcf\WCFService1\WCFService1Client\bin\Debug> WCFService1Client.exe
Enter number: 123
You entered: 123
Enter number: 12355
You entered: 12355
Enter number:

To use external library, we can need to create a bin folder, then drop the .dll into it. In this experiment, I use the dll generated from Robert Greiner’s NumberText.

The folder structure after adding the .dll:

│   Service.svc
│   Web.config
│   Web.Debug.config
│
├───App_Code
│       IService.cs
│       Service.cs
│
├───App_Data
└───Bin
        NumberText.dll

I also modified Service.cs to utilize the new library:

// .. SNIP ...
using NumberText;

// NOTE: You can use the "Rename" command on the "Refactor" menu to change the class name "Service" in code, svc and config file together.
public class Service : IService
{
	public string GetData(int value)
	{
		return string.Format("You entered: {0} ( {1} ).", value, value.ToText());
		 
	}
	// .. SNIP ...
}

The result is shown in the client:

D:\projects\wcf\WCFService1\WCFService1Client\bin\Debug> WCFService1Client.exe
Enter number: 19823
You entered: 19823 ( nineteen thousand eight hundred twenty three ).
Enter number: 1982
You entered: 1982 ( one thousand nine hundred eighty two ).
Enter number: 123
You entered: 123 ( one hundred twenty three ).
Enter number: 11
You entered: 11 ( eleven ).

The updated structure of Temporary ASP.NET Files (D:\projects\wcf\WCFService1\WCFService1_Temp):

└───wcfservice
    └───b4011030
        └───a40309e8
            │   App_Code.compiled
            │   App_Code.lvuilxx9.dll
            │   preStartInitList.web
            │   service.svc.cdcab7d2.compiled
            │
            ├───assembly
            │   ├───dl3
            │   │   └───a1784ffb
            │   │       └───24224434_efc1d701
            │   │               NumberText.DLL
            │   │               __AssemblyInfo__.ini
            │   │
            │   ├───temp
            │   └───tmp
            └───hash
                    hash.web

That’s it for today. Next, I will look into WCF Service Application. Cheers!

About Hardono

Howdy! I'm Hardono. I am working as a Software Developer. I am working mostly in Windows, dealing with .NET, conversing in C#. But I know a bit of Linux, mainly because I need to keep this blog operational. I've been working in Logistics/Transport industry for more than 11 years.

Possibly relevant:

Windows Communication Foundation (WCF) service exposes contracts to its clients. Contract here refers to the platform-neutral and standard way of describing what is available/can be done in the service. Below are the types of contracts:

1. Service contracts

It describes what operations the client can call/perform on the service.

[ServiceContract]
interface ILibrary
{
   [OperationContract]
   bool Borrow(Book arg1, User arg2);

   [OperationContract]
   bool Return(Book arg1, User arg2);
}

2. Data contracts

It defines the data-type which will be passed, to and from the service. Built in types (int, string) will be implicitly defined. But complex/custom data type must be explicitly defined. The custom/complex data type must be serializable.

[DataContract]
struct Book
{
   [DataMember]
   public int Id;

   [DataMember]
   public string Title;

   [DataMember]
   public string ISBN;
}

3. Fault contracts

It defines what errors will be raised by the service, how it handles and propagates the error to its clients. Fault contract can only be declared on operation contract which returns value.

[ServiceContract]
interface ILibrary
{
   [OperationContract]
   [FaultContract(typeof(InvalidArgumentException))]
   bool Borrow(Book arg1, User arg2);

   [OperationContract]
   [FaultContract(typeof(InvalidArgumentException))]
   bool Return(Book arg1, User arg2);
}

4. Message contracts

A message is the packaged information which is sent to/from service. The package’s outer layer is the envelope. Inside the envelope, there is a header, and a body (similar to data defined by data contracts). A message contract allows the service to interact directly with messages (e.g. accessing information defined in the header)

[MessageContract]  
public class BankingTransaction  
{  
  [MessageHeader] public Operation operation;  
  [MessageHeader] public DateTime transactionDate;  
  [MessageBodyMember] private Account sourceAccount;  
  [MessageBodyMember] private Account targetAccount;  
  [MessageBodyMember] public int amount;  
}

Which will generate the following SOAP envelope:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">  
  <s:Header>  
    <h:operation xmlns:h="http://tempuri.org/" xmlns="http://tempuri.org/">Deposit</h:operation>  
    <h:transactionDate xmlns:h="http://tempuri.org/" xmlns="http://tempuri.org/">2012-02-16T16:10:00</h:transactionDate>  
  </s:Header>  
  <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">  
    <BankingTransaction xmlns="http://tempuri.org/">  
      <amount>0</amount>  
      <sourceAccount xsi:nil="true"/>  
      <targetAccount xsi:nil="true"/>  
    </BankingTransaction>  
  </s:Body>  
</s:Envelope> 

Message contracts sample is taken from HERE.

About Hardono

Howdy! I'm Hardono. I am working as a Software Developer. I am working mostly in Windows, dealing with .NET, conversing in C#. But I know a bit of Linux, mainly because I need to keep this blog operational. I've been working in Logistics/Transport industry for more than 11 years.

Possibly relevant: