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.
Related
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.
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
I am using C# Visual Studio 2012 to create a wcf service.
I had the WSCF.blue tool generate the wsdl from the xsd-s. Then I generated the web service code using the same tool. WSCF.blue does not create a Service Contract and a Data Contract. It creates an interface and a .svc file that contains a class that implements the interface.
When generating the web service code I selected the option to create the abstract classes because I want to be able to keep the implementation of these classes in a separate file.
The abstract class looks like this:
[KnownType(typeof(WebMobileImplementation))]
public abstract class WebMobile : IWebMobile
{
public abstract PutLocationsResponse PutLocations(PutLocationsRequest request);
}
The implementing class (in a different file) looks like this (for now):
public class WebMobileImplementation : WebMobile
{
public override PutLocationsResponse PutLocations(PutLocationsRequest request)
{
PutLocationsResponse response = new PutLocationsResponse();
return response;
}
}
When trying to browse the service I get the message: "Service implementation type is an interface or abstract class and no implementation object was provided"
I thought that adding the knowntype to the implementing class will do the trick but it seems that the implementation is not 'seen' when running the service. What else can I do to 'connect' them?
In WCF 4.0, you can define virtual service activation endpoints that map to your service types in Web.config. This makes it possible to activate WCF services without having to maintain physical .svc files.
<serviceHostingEnvironment>
<serviceActivations>
<add relativeAddress="WebMobile.svc"
service="WebMobileNamespace.WebMobileImplementation"/>
</serviceActivations>
</serviceHostingEnvironment>
Where I was
I'm trying to convert some WCF services to use ServiceStack instead. For the most part it's achieving what I want but there's definitely differences. eg with WCF I had something like:
interface IMethod1{ ResultDTO Method1(InputDTO input); }
interface IMethod2{ ResultDTO Method2(InputDTO input); }
interface IMethod3{ ResultDTO Method3(InputDTO input); }
interface IMyService : IMethod1, IMethod2, IMethod3
then implement with:
public class MyService : ServiceBase, IMyService { /* ... */ }
Where I'm at
With ServiceStack it's more like:
public class Method1{
// parameters for method as properties
}
public class Method2{
// parameters for method as properties
}
public class Method3{
// parameters for method as properties
}
I've tried various thing and the latest dead-end I've hit was with:
public class MyServiceHost<T> : AppHostBase
{
public MyServiceHost(string version)
: base("My Service v" + version, typeof(T).Assembly)
{ }
public override void Configure(Funq.Container container){
Routes.AddFromAssembly(typeof(T).Assembly);
}
}
protected void Application_Start(object sender, EventArgs e) {
new MyServiceHost<Foo.Bar.V0101.MyService>("1.1").Init();
new MyServiceHost<Foo.Bar.V0102.MyService>("1.2").Init();
new MyServiceHost<Foo.Bar.V0201.MyService>("2.1").Init();
}
where it complains that AppHost has already been initialised.
Where I want to be
I want to expose something like this:
http://www.sandwich.com/example/v0101/sandwichservice.wsdl
http://www.sandwich.com/example/v0102/sandwichservice.wsdl
http://www.sandwich.com/example/v0201/sandwichservice.wsdl
or
http://www.sandwich.com/example/sandwich_v0101.wsdl
http://www.sandwich.com/example/sandwich_v0102.wsdl
http://www.sandwich.com/example/sandwich_v0201.wsdl
ideally hosted in the same service process.
So is there a simple answer I'm missing or am I approaching the whole thing fundamentally wrong? Or in a nutshell: using ServiceStack, is it possible to and how can I expose multiple endpoints and WSDLs for versioned web services in the same host service?
See this answer for recommended versioning strategies with ServiceStack.
You can't expose multiple versions of SOAP/WSDL's in ServiceStack, you're encouraged to evolve the same DTO's which means there are no previous type versions to create an older version of the WSDL. You would need to host older versions of ServiceStack project for the auto-generated WSDL to match up with older types.
You could also take a snapshot of a WSDL and host it statically, but whether a new SOAP endpoint accepts a client sending an old SOAP version is up to .NET's WCF Message class doing the parsing. But as SOAP is a brittle format, YMMV.
I know when you create a service you can create a generic DataContract:
[DataContract(Name = "Get{0}Request")
public sealed class GetItemRequest<T>
where T : class, new() { ... }
[DataContract(Name = "Get{0}Response")
public sealed class GetItemResponse<T>
where T : class, new() { ... }
[ServiceContract]
public void MyService : IMyService
{
[OperationContract]
GetItemResponse<Foo> GetItem(GetItemRequest<Foo> request);
}
This generates a GetFooRequest and GetFooResponse definition for my WSDL. Now, what I'm curious about is if it is possible to go in the other direction?
Is it possible to create a client that uses the Generic DataContracts and pass those to the server as a concrete object? I attempted this after adding a Service Reference and it didn't really work out so well. So this is more of me wondering if there is any way (even if it means not adding a Service Reference) to do this?
Ultimately, WCF is going to look at the contract class. If that is generated from WSDL/MEX it won't have this (since this isn't how it is expressed in the metadata) - but if your client has the code as above, then sure it should work fine.
If you add a library reference (i.e. a dll / project reference) to your DTO dll from the client, and ensure WCF has shared-assemblies enabled, it should work. If it still baulks, then cheat: use a service reference just to get the config data. Then delete the service reference but keep the configuration (those config files are a pain otherwise). Then it should locate the type from the library.