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.
Related
I'm consuming a SOAP web service. The web service designates a separate service URL for each of its customers. I don't know why they do that. All their functions and parameters are technically the same. But if I want to write a program for the service I have to know for each company is it intended. That means for a company called "apple" i have to use the following using statement:
using DMDelivery.apple;
and for the other called "orange"
using DMDelivery.orange;
But I would like to my program to work for all of them and have the name of the company or the service reference point as a parameter.
Update: If I have to write a separate application for each customer then I would have to keep all of them updated with each other with every small change and that would be one heck of an inefficient job as the number of customers increase.
Can anyone think of a solution? I'll be grateful.
If you have a base contract (interface) for all your services you can use a kind of factory to instantiate your concrete service and only have a reference to your interface in your client code (calling code).
//service interface
public interface IFruitService{
void SomeOperation();
}
//apple service
public class AppleService : IFruitService{
public void SomeOperation(){
//implementation
}
}
Having for example a kind of factory class (you can put your using statements here)
public static class ServiceFactory{
public static IFruitService CreateService(string kind){
if(kind == "apple")
return new AppleService();
else if(kind == "orange")
return new OrangeService();
else
return null;
}
}
And in your calling code (you just add an using statement for the namespace containing your interface):
string fruitKind = //get it from configuration
IFruitService service = ServiceFactory.CreateService( fruitKind );
service.SomeOperation();
You can also use the Dependency Injection principle.
If everything is the same and it's only the endpoint address that is different, maybe you can try changing only that before invoking the web service methods.
MyWebServiceObject ws= new MyWebServiceObject();
ws.Endpoint.Address = new System.ServiceModel.EndpointAddress("http://www.blah.com/apple.asmx");
Use any one client in your implementation. ex. Apple
Write a message inspector and attach this into the out going point
In message inspector replace the name space of the type with appropriate client name space.
EX:
Before Message inspector :MyClinet.Apple.Type
After Message Inspector : MyClient.Orange.Type, if the Provider is Orange.
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 have an interface in C#, something like this:
interface ITest
{
int Method1(int something);
}
All methods have parameters of basic types (integer, string, enum).
Now I want the implementation and the client to run on different machines communicating over a socket. What I could do manually is to make an implementation like this:
class Test : ITest
{
int Method1(int something)
{
m_Serializer.Serialize(something, m_Socket);
int result = (int)m_Serializer.Deserialize(m_Socket, typeof(int));
return result;
}
}
Is there a way to automate it, i.e. to generate such a wrapper for a given interface automatically?
I could generate it manually via Reflection.Emit, but that's quite complex. Any easy way?
WCF (Windows Communication Foundation) would be what you're looking for. It does pretty much exactly this - it does however have a somewhat steep learning curve.
I like to think of it as a framework that automatically generates a network "protocol" that is defined by your interface - the service contract. The "protocol" is also independent of the underlying network transport - there are bindings for raw TCP, HTTP, HTTPS, all with different use cases in mind.
You never have to actually care about what the network traffic actually looks like at the protocol or byte level - the whole lot is done for you seamlessly.
Clever stuff, worth learning.
Complete example of a WCF client and server over plain TCP, with no config files (all programmatic)
Create a class library which will be shared between two other programs, your client and server, containing an interface.
[ServiceContract]
public interface IMyApi
{
[OperationContract]
string SayHello(string s);
}
In program one, the server:
Add a reference to the class library above.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class MyApi : IMyApi
{
public string SayHello(string s)
{
return "Hello " + s;
}
}
static void Main()
{
var api = new MyApi();
var svcHost = new ServiceHost(api, new Uri("net.tcp://localhost:12345/MyService"));
svcHost.Open();
Thread.CurrentThread.Join();
}
Program two, the client:
Add a reference to the class library above.
static void Main()
{
var binding = new NetTcpBinding();
var endpoint = new EndpointAddress("net.tcp://localhost:12345/MyService");
var cf = new ChannelFactory<IMyApi>(binding, endpoint);
var client = cf.CreateChannel();
Console.WriteLine(client.SayHello("Tom")); // output on the console should be "Hello Tom"
}
While you could just serialize the data yourself (see Serialization) and deserialize on the other side, there are better options.
Windows Communication Foundation is a technology in the .NET framework which handles this for you. It automatically manages all of the communication (sockets) as well as the transfer of objects across multiple transport technologies.
I have a WCF Host with something like this:
[ServiceContract]
public interface IMountToOs
{
[OperationContract]
char GetMountDriveLetter();
[OperationContract]
MyTestClass MyTest();
}
public class MyTestClass
{
public string A { get; set; }
public string B { get; set; }
}
Client
private IMountToOs _proxy;
public IMountToOs Proxy
{
get
{
if (_proxy == null)
{
NetTcpBinding binding = new NetTcpBinding();
binding.MaxReceivedMessageSize = 2147483647;
binding.OpenTimeout = TimeSpan.FromMilliseconds(50000);
EndpointAddress address = new EndpointAddress("net.tcp://localhost:1234/MountToOsHost");
//_proxy = new MountToOsClient(binding, address);
ChannelFactory<IMountToOs> factory = new ChannelFactory<IMountToOs>(binding);
_proxy = factory.CreateChannel(address);
}
return _proxy;
}
}
While I can access
MessageBox.Show("Okay - " + Proxy.GetMountDriveLetter());
I can't call this method:
MessageBox.Show("Okay - " + Proxy.MyTest().A);
The complete extension is not working. But only while using it in an extension. Even if I insert a Messagebox in the first line of the extension it is not hit. I don't know why. It seems to run a pre-check and find the call of the custom class which is refused or so...
If I use a winform or so there is no problem.
.net 3.5
curious is that I have a break-point and a message of the hosts side. So I see that the method is not called
Update
now I moved the wcf-call in the Load Method of the extension and get a exception:
System.MissingMethodException: method not found:
"Contracts.Interfaces.MyTestClass
Contracts.Interfaces.IMountToOs.MyTest()".
My winform test and this extension use the same interface so that the method should known from both. no contract or so is outdated
According to what I found here and in the comments of the post: "For creating dynamic service proxy using client channel factory method, you will need datacontracts of the service. If you don't have datacontracts but you have the service URL, then you could use reflection to create proxy at runtime and call the service method."
Seems that the MyTestClass type is not known on the client side, so I think you could use reflection, or share the class between the client and server or much more simple, use the datacontract attribute.
Also, found something on MSDN that says something like this:
"When to use a proxy?
We create proxy using svcutil.exe. The output of this tool gives a proxy class and makes corresponding changes to the application configuration file. If you have a service that you know is going to be used by several applications or is generic enough to be used in several places, you'll want to continue using the generated proxy classes. We use proxy in WCF to be able to share the service contract and entities with the client. Proxies have several restrictions like they need to have gets and sets , contructors can't be exposed , methods other than the service contract cannot be exposed, repetition of code, everytime that we add/modify a service contract/data contract/message contract we need to re-generate the proxy for the client.
When to use ChannelFactory
The other option is using the ChannelFactory class to construct a channel between the client and the service without the need of a proxy . In some cases, you may have a service that is tightly bound to the client application. In such a case, it makes sense to reference the Interface DLL directly and use ChannelFactory to call your methods using that. One significant advantage of the ChannelFactory route is that it gives you access to methods that wouldn't otherwise be available if you used svcutil.exe..
When to use a ChannelFactory vs Proxy class?
A DLL is helpful if the client code is under you control and you'd like to share more than just the service contract with the client -- such as some utility methods associated with entities and make the client & the service code more tightly bound. If you know that your entities will not change much and the client code is less, then a DLL would work better than a proxy. If the client to your service is external to the system, such as API, it makes sense to use a proxy, because it makes sharing the contract easier by giving a code file rather than a DLL."
We cant see the class
MountToOsClient: IMountToOs
So we can only assume it is ok.
[DataContract] // Missing
public class MyTestClass
{
[DataMember] // Missing
public string A { get; set; }
[DataMember] // Missing
public string B { get; set; }
}
MountToOsClient can not expose Mytestclass without these attributes.
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.