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
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.
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>
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'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.
I am looking for a way to have the generated proxy class for a Web Reference (not WCF) implement a common interface in order to easily switch between web service access and "direct" access to our business layer in the client application, something like:
public IBusiness GetBusinessObject()
{
if (_mode = "remote")
return new BusinessWebService.Business(); // access through web service proxy class
else
return new Business(); // direct access
}
However, custom types (e.g. the CustomSerializableType in the examples below) aren't referenced in the generated proxy class. Instead new, identical types are generated, which makes it impossible for the proxy class to implement the interface.
Is there some way to make the generated proxy class reference these types, or am I going about this all wrong? Should I consider converting the web service to a WCF service instead?
Details
Our solution consists of these four projects:
A business library (contains business logic, accesses data store)
A common library (contains common functionality, including the CustomSerializableType)
A web service (acts as a proxy between remote clients and the business layer)
A windows application
Our client wants the windows application to be able to run in two different modes:
Local mode, where the application simply uses the business library directly to access data
Remote mode, where the application communicates with the web service to access data
In order to do this, we have created an interface, IBusiness, which is located in the common library and contains all business methods.
Interface
public interface IBusiness
{
CustomSerializableType DoSomeWork();
}
Business layer
public class Business : IBusiness
{
public CustomSerializableType DoSomeWork()
{
// access data store
}
}
Web service
public class WebServiceBusiness : IBusiness
{
private Business _business = new Business();
[WebMethod]
public CustomSerializableType DoSomeWork()
{
return _business.DoSomeWork();
}
}
Generated proxy class (a ton of code left out for readability)
public partial class Business
: System.Web.Services.Protocols.SoapHttpClientProtocol
{
public CustomSerializableType DoSomeWork()
{
// ...
}
public partial class CustomSerializableType {
// PROBLEM: this new type is referenced, instead of the
// type in the common library
}
}
Assuming that the default namespace for your client is "Client", and that your web reference is named "Proxy", then do the following;
In the root of your client project, create a folder named "Proxy".
In that folder, create a class named "Business".
Make that class public and partial, and have it implement your IBusiness interface
This way, you do not need to modify the Reference.cs. You should never modify Reference.cs, or any other file produced through code generation.
Note that this violates the principals of SOA by tightly binding your client to your service. At the very least, you should define those interfaces in a separate project, so that you are only sharing the "interface" project between the client and service.