WCF Console Application Stand-Alone/Standalone Service

Okay. I'm having some conceptual issues with a WCF service i want to create. In short, I need to create a stand-alone Windows service that provides me with remoting functionality (replacing a .NET 1.1 remoting application).

Some general concepts as I currently understand them:

1. I can do this by first creating a console app that provides the WCF hosting functionality.
2. I would then deploy this console app as a service via the "create a service" mechanism available for .NET (using the IDE it's pretty simple -- this part is not diff开发者_如何学编程icult).

Edit: It might be better just to create a Windows Service and open the service host on the OnStart() and close it in the OnStop(). I will probably do this, but one of the things I'm finding confusing is that some of the examples I'm looking at talk about writing a simple console app versus this mechanism....

Here's the current situation. We have an interface, I'll call it IData which implements our calls to the SQL server. Currently, we implement IData in a class I'll call RemData which has our basic Execute_Query and Execute_NonQuery methods.

Therefore, IData looks like:

[ServiceContract()]
public Interface IData
{
   [OperationContract()]
   int Execute_Query( parameter list....);  // parameter list shouldn't be important here I hope.

   [OperationContract()]
   int Execute_NonQuery( parameter list....);
}

Note how in my interface definitions, I added the attributes for the WCF stuff (Service Contract and OperationContract). This is central to one of my questions below.

RemData implements IData. We build it sepearately as a DLL.

Now, I need to implment the WCF so I create a console app and include a reference to the DLL containing the definition for my interface IData and a reference to the DLL for RemData (yes, they are in two separate assemblies for me).

Here's the tricky part for me. I need to implment the service, so I'm thinking I can do it in this way. First I modify the RemData class and add System.ServiceModel as a reference and then decorate the class with the [ServiceBehavior()] attribute and then add the [OperationBehavior()] attributes to each of the methods matching my Interface.

1. Is this a good plan of attack?

2. If I do this plan, do I then decorate the class with the [ServiceBehavior()] attribute and then each method in the class with the [OperationBehavior()] attribute? Do I even need the OperationBehavior attribute at all? I'm pretty sure I need the ServiceBehavior attribute, though.

3. These would then more or less match the ServiceContract and OperationContract attributes on the interface, right?

4. What if I have multiple overloaded Execute_Query() and Execute_NonQuery() methods in the original (which I do). I know how to define them in the interface using the Name parameter in the OperationContract attribute:

   [ServiceContract()] public Interface IData { [OperationContract(Name="Execute_QueryA")] int Execute_Query( parameter list....); // parameter list shouldn't be important here I hope.

   [OperationContract(Name="Execute_NonQueryA")] int Execute_NonQuery( parameter list....);

   [OperationContract(Name="Execute_QueryB")] int Execute_Query( parameter list....); // parameter list shouldn't be important here I hope.

   [OperationContract(Name="Execute_NonQueryB")] int Execute_NonQuery( parameter list....);

   }

5. But, what do I do for the actual implementation? Do I just leave the [OperationBehavior()] execute as it stands and not add any parameters to it? There doesn't seem to be a name parameter.

I'd appreciate any thoughts on this or links to good articles because I'm not finding a whole lot of useful information that goes beyond the basic "Hey, I created a single call WCF service hosted in IIS ..."

Thank you.

1. Contract definition and implementation can be in two different projects (DLLs)
2. Not sure why you are stuck with adding attributes like ServiceBehavior and OperationBehavior. If you have no behavior to add, better get rid of them.
3. Instead of going for the overloads, you better go with different names

Your plan is fine, but you probably don't need to decorate each method implementation with [OperationBehavior] unless they're doing something special.

Your overloads will need to have unique parameters, though, or else you must give them different names, eg:

[OperationContract()]
int Execute_NonQueryA( parameter list );

[OperationContract()]
int Execute_NonQueryB( parameter list);

The name attribute of OperationContract is not meant to enable multiple overrides of methods that have the same C# signature, it's only meant to rename the method from the perspective of the caller.

For a console app that becomes a stand-alone service, I would suggest Topshelf which works well for me. Also this codeproject.com article on a dynamic loading WCF service framework also works pretty well. Putting them together is the approach I would take.