To pass the culture information from client to WCF service, I have created a custom behavior using the custom inspector. The inspector class implements IDispatchMessageInspector and the IClientMessageInspector.
My client is the silverlight application. And now I'm facing the problem with the IDispatchMessageInspector since it's not available in the System.ServiceModel.Dispatcher.dll is not available to add as an assembly reference to Silverlight 4 project.
Can someone help me out ? How to handle the custom behavior to send message from SILVERLIGHT to wcf. ?
The IClientMessageInspector needs to be implemented and used at the client (silverlight in this case) side whereas IDispatchMessageInspector needs to be used at the service side.
Following posts are really helpful:
Automatic Culture Flowing with WCF by using Custom Behaviour
Automate passing valuable information in WCF headers
Processing custom WCF header values at server-side
Related
I have a net.tcp binding example that apparently dates back to .NET 2.0 runtime version. The client code of the WCF Net.TCP binding example has an interface marked as "System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "2.0.x.x") or so.
it also defines some Request & Response classes where the request apparently wraps the parameters of the service operation contract and the Response class wraps the result/return value. And it also defines a controller class for the service.
Now, in a WCF hosted by winform with net.tcp binding, I have found no way to autogenerate these classes myself. I wonder, is that an old way of doing things? is it required? or can I just include in the client app a reference to the DLL that contains the service?
I made some changes and now nothing works and wondered if I can just get rid of those "autogenerated" classes (or if not, HOW can I regenerate them?).
I use Visual Studio 2012 Ultimate for .NET 4.5 under Windows 7 Ultimate. My application are two winforms (client and server) that use WCF with netTCP binding.
Apparently I have to point svcutil o the base address rather than that of the service or endpoint. Then it will generate the client code and config.
I have an application service layer (which all return serializable viewmodels). Some of these app services need to be callable via AJAX by client code in the Web UI. I'm currently wrapping them in ASMX files that do nothing but dictate the response format as JSON delegate each call to the application service class with the same signature.
Is it advisable to try to save a few lines of code by exposing the appropriate application service classes as WCF services? Can someone point me to an example? Any potential pitfalls for usage in WebForms client code?
Microsoft now considers ASMX services to be "legacy technology". You should not use them for any new development. They have been completely replaced by WCF. For instance, see the top of this article: http://msdn.microsoft.com/en-us/library/bb885203.aspx:
This topic is specific to a legacy
technology. XML Web services and XML
Web service clients should now be
created using Windows Communication
Foundation .
I'm developing a .NET 2.0 client application that needs to connect to a WCF service. I add a web reference to a basicHttpBinding WCF service that we've developed and VS creates the proxy class and the config paraphenalia which is fine. The problem is that I only want to use a small fraction of the methods that the WCF service implements and not carry around the extra implementations that the client app doesn't need.
I was thinking of creating a different basicHttpBinding endpoint and put the methods there. Is there a way for only one endpoint of a WCF service to be referenced by a .NET 2.0 project?
Regards,
Frank
When you add a web reference to a service, you always get all the service methods. It's the service (implementation) that defines the scope of what ends up in the WSDL.
The only option to limit the scope of the method your client generates would be to create a second WCF service on the backend, which only implements those few methods that you want in your client - just having a second endpoint won't really help.
Is it possible to have the proxy classes that are generated when setting a service reference implement INotifyPropertyChanged?
In this case it's a silverlight app referencing a WCF service?
Update:
The SlSvcUtil.exe commandline utility is part of the silverlight SDK installed {Program Files}\Microsoft SDKs\Silverlight\v4.0\Tools will generate the classes with an INotifyPropertyChanged implementation.
I'll leave this question up, as I live in hope that someone will say this is possible from Visual Studio without haing to launch an external tool.
Proxy classes do not implement that interface, only DataContracts do. If you open .svcmap file generated by adding service reference in XML viewer you can change EnableDataBinding element to true and update service reference from VS. I thought that true is default value and you have to manually changed it if you don't want to use INotifyPropertyChanged. What is so specific in your service?
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.