I'm wondering if it is possible to EXPORT an WCF client proxy to use IOC with MEF. And how to do that ?To make the wcf client proxy i used "add service reference". Any suggestions ?
Thanks for help.
Since the class is generated, you have two solutions :
1) you can edit the class and add the MEF export attribute, but it's not a good practice to modify generated classes
2) you can copy the generated class and create a new one with that, on which you have a total control and can add the MEF export attribute.
The client class generated when you add the service reference is marked as Partial. Just create a second definition in a non-generated file and add the ExportAttribute to that.
This is another solution. ... exposing the service functionality as a shared service.
Related
within our per-session WCF services hosted in ISS, we would like to use Ninject to IOC different data access component through the interface.
Where would be the best place to declare the binding once? is it in Application_Start of Global.asax?
If it is, how could I obtain the instance through the inferface from Ninject?
I know in StructureMap, we can call something like ObjectFactory.GetInstance()?
What is the equivalent in Ninject?
Thanks
I assume you have looked at the official WCF extension? I usually define my own service factory (referenced in the .SVC file) and reference my Ninject module from there.
As for getting an instance from an interface (i.e. the opposite of having it injected), you do so via the kernel. (You can always have an instance of IKernel injected into any of your classes by adding it to your constructor.) Once you have it, you just use:
kernel.Get<IYourInterface>();
Our third party API provides two different web services but have identical methods, models. Nevertheless they only differ on URIs (Web Service Path, Action Path [Operation Contract].
So I have decided to:
Generate the code from their wsdl using VS.
Edit the namespacing to use the same and to be "Common" and not use the service reference instead i use the Reference.cs edited code.
Create a new proxy that will handle the correct URI of the service to use (wrapped the Reference.cs inside of it).
Now, I having an issue with the "Method1", because they have different Action Name. Having an exception of:
"Server did not recognize the value of
HTTP Header SOAPAction:
http://www.api.com/service/Method1"
I just notice that it the correct action name is: http://www.api.com/service1/Method1
The question now is, is there any configuration or behavior that i can use to correct the action name for each method for each service?
Or as long as they keep on adding contracts for each implementation of the API, i should also keep on adding the contracts for each, and just use the ChannelFactory for this?
Please help, thanks.
I ended up directly using the ChannelFactory when faced with the same problem
In my implementation, I had a base interface that had all the common methods to the 2 APIs. Then I had 2 seperate intefaces - one for each 3-rd party API version - that inherits from the base interface and adds methods and [OperationContract] attributes that varied between the two implementations.
When instantianting ChannelFactory<> I used one of the child interfaces. Helped to keep the consumer code clean and maintainable
I'm creating a service reference to a web service written in Java. The generated classes now follow the Java casing convention used in the web service, for example class names are camelCase rather than PascalCase.
Is there a way to get the desired casing from the service reference?
CLARIFICATION:
With WSE based services, one could modify the generated Reference.cs to provide .NET standard casing and use XmlElementAttribute to map to the Java naming presented by the external web service, like this:
[System.Xml.Serialization.XmlElementAttribute("resultType", Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
[System.Runtime.Serialization.DataMember]
public virtual MyResultType ResultType
{ ... }
Not terribly maintenance-friendly without writing custom code to either generate the proxy code or modify it after it's been generated.
What I'm after is one or more options to present a WCF generated client proxy to calling applications using the .NET casing conventions, achieving the same as I did previously with WSE. Hopefully with less manual effort.
Well, since your WCF client proxies are partial classes, you could always add a second file for the same class, which implements the PascalCasedMethodName for each javaCasedMethodName and then just call the Java method from your new method.
public partial class MyClientProxy
{
......
public MyResultType GetResultType(string inputParam)
{
return this.getResultType(inputParam);
}
......
}
Seems a bit redundant - but that should really work, I think. Since your code is stored in a separate file, it won't be overwritten if you re-create the client proxy - and since it's the second part of a partial class, it will be "merged into" the class definition for your client code to call.
I have a custom data entity (data object) that is exposed via a WCF webservice. The WCF service lives in a web application. I then have a Silverlight application with a service reference to that WCF service. When i add the service reference a proxy is generated, and that includes a version of the custom data entity.
How should i structure my code so that the data entity is declared in one place, and shared amongst the project containing the WCF service and any Silverlight applications that reference it? I want to eliminate the version of the data entity that is generated with the proxy.
There is a good example of how to do this here by Pete Brown. Using that approach you can use the same classes in both the Silverlight client and in the WCF service without having to use the generated objects.
Declare the data entities in the WCF service or a project that the service refereneces, then from the Silverlight project add the entities as links and make sure the "Reuse types in referenced assemblies" checkbox is selected from the Service Reference Settings dialog.
You can put the types in either the Silverlight or WCF side.
I have tried doing things this way and found that using DTOs instead and mapping them to the entities in the Silverlight side to be much cleaner and easier to work with although I did write a bunch of mapping code to get the DTOs into the entities and vice versa.
I´m not quite shure why anybody want to do that. You have to understand that the type you find in the proxy is a projection of the Type you have at Service server site. It´s defined in the *.g.cs files and gets generated new if you update the service reference.
In my opinion it´s the best way to have it declared in a single location, and project it. You need it in two places and it´s single defined.
I may be wrong anyway .....
I am just curious to know that what is ClientBase class in WCF, and how can i use it.
I surfed the internet and i found that this class is used to create proxies to call service methods , but no example.
Please anyone explain it with example , it will help me undestand this class...
It's the base class for your client proxies being generated by either "Add Service Reference", the svcutil.exe command line utility, or by your custom code if you don't want to use any of those methods.
It's a generic type that takes the generated client-copy of the service contract as its type parameter.
It can be extended, if you wish to do so - e.g. see IDesign's download page for a few samples of what can be done, things like:
AsyncClientBase for safe asynchronous calls
HeaderClientBase for simplified support of custom headers in your messages
Marc
It's there for autogenerated proxies which are created when service references are added to your project, not really for your own use.