I am currently using ClientBase to access a web service. This works correctly but I need to log the XML request that is being sent off to the service.
I can see that there are ways of doing this using listeners and other similar methods, but I need to access this XML request in the method from which it is being submitted in my codebase.
Is there any way in which this is supported?
The "XML" is only ever created (serialized) after the control flow leaves your method and enters the WCF code that actually does the call. So if you were theoretically able to get it from within your code, you'd have to get it "after" the actual call. This is also the reason why the intended way to do this, is implement/register a IClientMessageInspector.
The only other thing, which includes some unnecessary manual labor, would be to manually serialize the arguments you pass to the WCF call using the NetDataContractSerializer or DataContractSerializer. Mind you, though that this will only give you the payload, not the complete message (including headers, etc.).
I'd really go for the way that is suggested for this (see link above).
You can try some AOP programming. If you are using Unity for DI, you can try Unity with Interception or Interception alone using Intercept class.
Related
As logmeinrescue doesn't support batch users creation using a simple csv upload or similar and instead offers the ability to create user accounts using http post and get or by using soap I thought I would look into this.
Unfortunately following the code example in this link I have been unable to work out how to utilize the SOAP aspect of the code as I have never had previous experience using it.
So far I have written a fairly basic program that reads in the csv with all the user account data needed for creation and would loop through and assign the values needed.
If anyone could assist it would be greatly appreciated, I have tried to look up some documentation in regards to c# and soap but I was unable to find something that really helped me with configuring for logmein.
The c# example at the bottom of documentation you link to looks helpful but flawed. APISoapClient does not have a CookieContainer property so I would try it without the line of code that tries to set it. Later in the code there is a call to sAPI.createUsers but the example has not defined sAPI, I think they meant to re-use proxy.
To get started the easy way, right-click your project References and select Add Service Reference. Enter their endpoint and click GO:
https://secure.logmeinrescue.com/api/API.asmx
If you change the namespace from Service1 to match the example (APIServiceReference) your code will look like the example. From then on you can perform API operations basically just like you were dealing with classes, the SOAP mess is abstracted away for you.
Question
Is there an up-to-date example showing how to replace the default DataContractJsonSerializer with Json.Net serializer in a WCF 4.5 Service?
Background
As seems to be a common request, I want to replace the default DataContractJsonSerializer with Json.Net serializer. The first approach I came across was provided by Carlos Figueira here. This does work, but as pointed out at the end of the article (paraphrasing somewhat):
this is not production-ready code...tested it for a few contracts...cannot guarantee that it will work for all scenarios…for simplicity sake it doesn’t have a lot of error handling which a production-level code would...it’s not too easy to integrate any new formats in the existing WCF REST pipeline...had to deal with formatters, Message objects, take a dependency on a content type mapper, just to be able to use this different serializer...even after all of this...not completely integrated with the pipeline – UriTemplates aren’t supported...
Which all makes me a bit nervous. However at the end there is a mention of WCF API with a link to an discussion which has these lines of code:
var hostConfig = (HttpHostConfiguration) config;
hostConfig.OperationHandlerFactory.Formatters.Insert(0, new NewtonsoftJsonFormatter());
as well as how to override a formatter. The problem is that I can't get this to work in a WCF service. After including a bunch of additional NuGet packages the formatter compiles, but my service is never called. Each page I come across, seems to have different configuration code. I have tried the approaches outlined here, here, here, here and here (to list a few). Some use HttpHostConfiguration, some use GlobalConfiguration, some use OperationHandlerFactory. I think that part of the problem is that a number of these approaches are old and from different technologies - WCF WEB API, ASP.NET API, ASP.NET MVC.
While I can get the formatter to compile, it is never called, which makes me think that it is a configuration issue. I could post some code, but I am not sure exactly which part is incorrect. I have considered the approach of returning the generic Message object and formatting each object to a Message with json, but I would prefer to only do this as a last resort as it makes the return types for the service less clear. Which brings me to my the question show above.
Can I pass a custom object between AJAX enabled WCF and my asp.net page?
I searched the web but could not find any examples. Most shows simple types like string and integers.
I also do not know how to populate custom object's property through JavaScript on the client side.
We have a browser add on and we have to pass data to that addon from a web service, I researched and looks like AJAX enabled WCF is way to go
Using .net framework 3.5 and VS 2008
You can't pass the actual custom objects, but you can of course pass the serialized version of them through your service and to your page, javascript, etc. Basically, you have to map the fields of your complex custom .NET types to classes decorated with the DataContract attribute. These classes are the types that your service will return. The DataContract-decorated classes will contain fields with primitive types, like strings, integers, etc. The WCF service will serialize these into XML or JSON.
On the client side, jQuery will be your best friend. I personally prefer JSON because the properties of your objects are much easier to get at that way instead having to deal with parsing a bunch of XML. So, setup your service to output JSON.
Also, to make your service URLs easier to read, make sure to use a RESTful approach. It's as easy as decorating your service methods with the WebGet attribute and supplying a UriTemplate. Once you see some examples, it'll blow your mind. Note: if you ever encounter a WebInvoke with Method="GET", just use WebGet instead...it's more compact...no Method specification needed.
This particular article was EXTREMELY useful to me when I was developing my WCF service and the ASP.NET app that consumed it: http://www.c-sharpcorner.com/UploadFile/sridhar_subra/116/
Here's another person asking the same question as you: http://social.msdn.microsoft.com/forums/en-US/wcf/thread/879d46af-9c78-4b5d-b746-82843d742a6f
Hope this helps! Long live WCF!
With .NET 3.5 your best bet is WebHttpBinding which accepts plain old XML (POX) and you need to send XML to the WCF service.
You can also use WCF REST using REST starter kit. For samples have a look here. This supports JSON as well.
If you were using .NET 4.0, JSON-enabled WCF HTTP was the way to go. WCF REST with 4.0 was an alternative although I really do not like it.
What is best practice for creating wrapper for WCF service call? I think it is necessary
to monitor all calls in the same place, I am thinking to use this kind of code, is this right idea?
RetType t = ServiceExecutionContext<IServiceChanel>.Execute(s=>s.GetServiceMethod());
What kind of wrapper are you use in your enterprise applications?Thanks a lot!
WCF has a model that allows you to be in the service call chain. I would use that rather than trying to wrap every service call if all that you are trying to do is some logging (which WCF is already very good at doing if you turn diagnostics on in the config file) and common things like that around your service calls.
Here is a good MSDN article about how to create custom behaviors for WCF services.
If you need to, write your own Message Inspector.
WCF also has message logging builtin. By default, you can log easily to a file using the System.Diagnostics.XmlWriterTraceListener, however if you need to write the log elsewhere (say, a database), you could write your own trace listener.
I would recommend this approach over a message inspector... message inspectors are too easy to write incorrectly and hurt performance without knowing what you are doing.
I'm still new to the ASP.NET world, so I could be way off base here, but so far this is to the best of my (limited) knowledge!
Let's say I have a standard business object "Contact" in the Business namespace. I write a Web Service to retrieve a Contact's info from a database and return it. I then write a client application to request said details.
Now, I also then create a utility method that takes a "Contact" and does some magic with it, like Utils.BuyContactNewHat() say. Which of course takes the Contact of type Business.Contact.
I then go back to my client application and want to utilise the BuyContactNewHat method, so I add a reference to my Utils namespace and there it is. However, a problem arises with:
Contact c = MyWebService.GetContact("Rob);
Utils.BuyContactNewHat(c); // << Error Here
Since the return type of GetContact is of MyWebService.Contact and not Business.Contact as expected. I understand why this is because when accessing a web service, you are actually programming against the proxy class generated by the WSDL.
So, is there an "easier" way to deal with this type of mismatch? I was considering perhaps trying to create a generic converter class that uses reflection to ensure two objects have the same structure than simply transferring the values across from one to the other.
You are on the right track. To get the data from the proxy object back into one of your own objects, you have to do left-hand-right-hand code. i.e. copy property values. I'll bet you that there is already a generic method out there that uses reflection.
Some people will use something other than a web service (.net remoting) if they just want to get a business object across the wire. Or they'll use binary serialization. I'm guessing you are using the web service for a reason, so you'll have to do property copying.
You don't actually have to use the generated class that the WSDL gives you. If you take a look at the code that it generates, it's just making calls into some .NET framework classes to submit SOAP requests. In the past I have copied that code into a normal .cs file and edited it. Although I haven't tried this specifically, I see no reason why you couldn't drop the proxy class definition and use the original class to receive the results of the SOAP call. It must already be doing reflection under the hood, it seems a shame to do it twice.
I would recommend that you look at writing a Schema Importer Extension, which you can use to control proxy code generation. This approach can be used to (gracefully) resolve your problem without kludges (such as copying around objects from one namespace to another, or modifying the proxy generated reference.cs class only to have it replaced the next time you update the web reference).
Here's a (very) good tutorial on the subject:
http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx