We Keep Coding

Find all references with WCF OperationContract and DataContracts

I'm trying to figure out if there's a way to "Find all references" (using the VS feature, as opposed to Control+F entire solution). when it comes to WCF Data and OperationContracts. In case that is unclear:
namespace WcfTestReferences
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world");
DoStuff();
ServiceReference1.Service1Client client = new ServiceReference1.Service1Client();
var results = client.GetData(42);
Console.WriteLine(results);
}
static void DoStuff() { }
}
}
namespace WcfTestReferences.WCFApp
{
[ServiceContract]
public interface IService1
{
[OperationContract]
string GetData(int value);
}
public class Service1 : IService1
{
public string GetData(int value)
{
return string.Format("You entered: {0}", value);
}
}
}
Solution looks like this:
Now, if I look at DoStuff() with code lens, I can see that it in fact has a reference to it:
But the same does not hold true for the methods being called in the wcf service:
In the above, the only references to the interface/method is the interface/method. I understand that the reference that I was hoping would be there (from the main method):
var results = client.GetData(42);
is not there, because the client is generated, and is not actually my Service1 implementation... but is there a way to change this?
In the real world, we have a WCF layer with thousands of methods, many of which are not used - but I cannot rely on Code Lens/Find all references to make this determination. Is there any way to change this behavior?

because the client is generated, and is not actually my Service1
implementation
This is the root of the problem.
You are correct - there is no way for your code analyser to determine that the GetData() call you are making from your client is semantically the same thing as the GetDate() service operation you have defined on your interface, because from a binary perspective they are defined in two completely different types.
The root of this is that you're using a service reference. WCF provides service references as the default way of connecting to a service, but in my opinion service references are problematic and should be avoided.
Luckily, WCF provides another way of consuming and calling a service via the user of ChannelFactory<T>. One of the many benefits you will get when using this instead of a service reference is that your client will have use of the service interface via a binary reference to the assembly containing your service definition.
This will allow tools like code lens to resolve references to your interface methods directly to your consuming clients.

Using a client proxy with rest in C#

Running into a block trying to follow the logic of an example program. The example is used to demonstrate creating a contract, create a rest web service and then consume the rest service.
What throws me is I have the interface defined in the contract
namespace ProductDetailsContracts
{
[ServiceContract]
public interface IProductDetails
{
[OperationContract]
[WebGet(UriTemplate = "products/{productID}")]
Product GetProduct(string productID);
}
}
then used in the web service
using ProductDetailsContracts;
public class ProductDetails : IProductDetails
{
public Product GetProduct(string productID)
{
//do something
}
}
The code is then consumed in the client
using ProductDetailsContracts;
namespace ProductClient
{
class ProductClientProxy : ClientBase<IProductDetails>, IProductDetails
{
public Product GetProduct(string productID)
{
return this.Channel.GetProduct(productID);
}
}
}
I feel ClientBase<IProductDetails> is the key but I don't see how it is associated with the web service ProductDetails. My real goal to understanding this will be to run a client application that can add and update records in a SQL Server.

The interface you defined is the contract you pass to your client which tells them what services you provide, in your case you provide a GetProduct method.
Then, you create a concrete implementation of that contract, so when client code calls on your interface, they will end up invoking that concrete implementation, which will probably access some external resource (a database or a file) containing the product.
Your ProductClientProxy, which inherits from ClientBase<IProductDetails> is responsible for settings up the channel that will allow the client to make calls to your service. ClientBase is part of the WCF infrastructure, and is the class that actually reads the settings from your app.config and is responsible for settings up communication.
I suggest you read more about ClientBase and even look at the source code

UriTemplate prefix for RESTful WCF web service

I have various interfaces (endpoints) in a WCF service host, each for a completely different concern. In a classic soapy web service, I'm able to define a base host address (e.g. http://myhost.com/) and map each interface to a relative URI (IServiceContract -> service/, IMaintenanceContract -> maintenance/) so I can call them by e.g. http://myhost.com/service/mymethod.
Now I'm taking my first steps towards a RESTful WCF service using JSON as message format for CRUD web requests and the only thing I see to address an operation is by using the UriTemplate field from WebInvoke (or WebGet) attribute. Unfortunately, it doesn't seem that I can put this on the interface, just on operation contract methods.
How can I map each interface to a different relative URI?

Yes, you'll put the base url on the [OperationContract] methods. This is OK though, because you can specify any base url you want. Here is a sample interface that gives you this control.
namespace MyHostApi
{
[ServiceContract]
public interface IMyHostApi
{
[OperationContract]
[WebGet(BodyStyle = WebMessageBodyStyle.Bare,
UriTemplate = "WhateverYouWant/HelloWorld/{name}")]
string HelloWorld(string format, string name);
}
}

Adding ServiceContract interface

I have some interface that is marked as a [ServiceContract] for WCF service.
But it's also used in two different non WCF locations in my code.
The problem is that I am using a interface that is marked as a [ServiceContract] in not WCF projects.
Is there a way to have a this attribute only in a WCF context without duplicating code ?

Why are you using a WCF contract definition in places that are not WCF? the fact that its an interface is a WCF implementation detail. Define an interface that is not WCF related in your other code and then if it needs to talk to the WCF one then write an adapter that forwards to the WCF interface.
The additional benefit of this is that you provide an isolation boundary in that changes to the WCF contract do not have to bleed into your other code
interface IFoo
{
void DoSomething();
}
[ServiceContract]
interface IWCFFoo
{
[OperationContract]
void DoSomething();
}
class FooAdapter : IFoo
{
IWCFFoo wrapped;
public FooAdapter(IWCFFoo wrapped)
{
this.wrapped = wrapped;
}
public void DoSomething()
{
wrapped.DoSomething();
}
}
also it allows different types to be used on IFoo and IWCFFoo so the DataContract DTOs don't bleed in to the rest of your code

You could use conditional compilation directives:
#if WCF
[ServiceContract]
#endif
public interface ...
Then only define the WCF token in your WCF project.

Why does WCF generated proxy wrap contract interface methods with new methods with different signatures?

I'm subcsribing to the SQL Server 2008 SSRS web service ( .../reportserver/ReportService2005.asmx?wsdl) using WCF, with default WCF config options as far as I can tell.
It does something weird when it generates the local proxy classes though.
I'll use the ListChildren method as an example:
On the client side, WCF generates an interface like this, as you would expect:
public interface ReportingService2005Soap {
ListChildrenResponse ListChildren(ListChildrenRequest request);
}
It also generates a 'client' proxy that implements that interface:
public partial class ReportingService2005SoapClient :
System.ServiceModel.ClientBase<ReportingService2005Soap>, ReportingService2005Soap
{
[EditorBrowsableAttribute(EditorBrowsableState.Advanced)]
ListChildrenResponse ReportingService2005Soap.ListChildren(ListChildrenRequest request)
{
return base.Channel.ListChildren(request);
}
public ServerInfoHeader ListChildren(string Item, bool Recursive, out CatalogItem[] CatalogItems) {
ListChildrenRequest inValue = new ListChildrenRequest();
inValue.Item = Item;
inValue.Recursive = Recursive;
ListChildrenResponse retVal = ((ReportingService2005Soap)(this)).ListChildren(inValue);
CatalogItems = retVal.CatalogItems;
return retVal.ServerInfoHeader;
}
}
As you can see, the client proxy implements the interface and then 'hides' it from being used by explicitly implementing the interface (so you have to cast to get to the interface method) and additionally with a EditorBrowsableState.Advanced attribute.
It then adds an extra wrapper method that uses 'out' parameters.
Is there a way to stop if from doing that, and just have it implement the interface directly?
What its doing here leads you down the path of using the wrapper methods with 'out' parameters, and then you find you can't mock the service very easily because the wrapper methods aren't virtual, and aren't defined in any interface.
NB: I'm using the SSRS web service as an example here but I've seen WCF do this on other services as well.

This probably happens if your service is using MessageContracts. Proxy creation by default tries to unwrap these message contracts so that exposed operations accept their content directly. If you want to use message contracts on the client as well you need to configure it in advanced settings of Add service reference by checking Always generate message contracts.