I need to hook up my own XmlSerializer (need to do some custom prepataions). They are all "valid" and easy to do when creating an XmlSerializer, but...
...when using WCF using the behavior am not creating the serializer. So I run into a problem.
Anyone has a reference how to replace the XmlSerialiaztionBehavior of WCF and to "inject" a custom prepared XmlSerializer?
You might want to look into custom message formatters, or here on msdn.
Related
I have ASP.NET webservice(Asmx) which I need to consume in Cocoa/Objective-C. What is the simplest/optimal way to achieve this? I have done the implementation where we have many delegates for XMLParser and connection. like didStartElement, didEndElement....
Is there any other way to achieve this? In .NET I have done a similar implementation where I have a proxy class and when I make a call to the web method I get a response which is the return value of the web method rather than parsing the response xml.
Please let me know.
Try out some of the existing network frameworks before writing your own (RESTKit, AFNetworking, etc.) - They all have good tutorials on how to easily consume webservices.
A little bit off-topic, but it seems that your Webservice returns a XML response. I would (but that's just me!) try to change that to JSON. Cocoa/Obj-C provides built-in functions to deserialize JSONs, and the aforementioned frameworks also work quite well with this format. It's far easier to use than NSXMLParser etc.
I'm engaged in building NServiceBus Gateway handler, and I need to avoid config files so that all configuration is defined inside c# classes. As a result I have to convert the following section to c# code
<GatewayConfig>
<Channels>
<Channel Address="http://localhost:25899/SiteB/" ChannelType="Http" Default="true"/>
</Channels>
</GatewayConfig>
I've found GatewayConfig, ChannelCollection and ChannelConfig in a NServiceBus.Config namespace, but I can not link them together, coz GatewayConfig refers to ChannelCollection, but ChannelCollection has nothing to do with ChannelConfig. Please help
Just create a class implementing IProvideConfiguration of GatewayConfig. That gives you a way to provide your own config. Look at the pubsub sample for the exact details on how to do this.
Well, I've found the way to do it as I installed Reflector and looked into the implementation. There is a ChannelCollection.CreateNewElement() method returning back System.Configuration.ConfigurationElement. NServiceBus overriden the method instantiating ChannelConfig inside it, so all I have to do is to cast ConfigurationElement type to ChannelConfig type which is far from intuitive interface. Looks like this NServiceBus.Config.ChannelCollection is kind of unfinished work, because if you look at other collections like NServiceBus.Config.MessageEndpointMappingCollection you can find there all necessary type-safe methods to work with its child elements NServiceBus.Config.MessageEndpointMapping, so I think NServiceBus team was just lazy to make the same for ChannelCollection.
UPDATE: as CreateNewElement() method is protected, I have to implement my own class inherited from ChannelCollection to make a method adding new ChannelConfig element publicly available
We need to add a new profiling feature to our WCF application, for logging where time is spendt in the application. I'm looking at PostSharp for a convention driven approach of applying the logging and need some input on how to actually log it. I've already created a custom class for logging purposes, using StopWatch and can log the steps through the layers of my WCF application. However I'm wondering if there's a thread safe alternative library I could use in conjunction with PostSharp for this purpose. I've come across MiniProfiler, but it seems to be intended for ASP.NET MVC applications mainly. Any other frameworks I should consider or should I just use my custom class?
Thanks
I did something like that in the past using a IClientMessageInspector implemented on a custom IEndpointBehavior.
Depending on what kind of logging you want, this might just do the trick. There's an example in the following link
IClientMessageInspector Interface
PostSharp itself is thread-safe. The aspects that you write may be thread-unsafe if poorly written, but there's always a way to make them thread-safe.
If you're using OnMethodBoundaryAspect and need to pass something from OnEntry to OnSuccess, store the initial stopwatch value in OnMethodExecutionArgs.MethodExecutionTag.
DataContractSerializer has many constructor overloads, and I'd like to be able to specify how my WCF service should initialize the DataContractSerializer it uses. How would you go about doing this? Is it easier to configure this in the .config file or in C#?
A WCF service always appears to use this one by default.
If possible, please give an example of how to specify DataContractSerializer using this constructor for KnownTypes.
This MSDN forum post shows how to swap the serializer in WCF with another. You could create your own wrapper with the constructor that you want and swap it in.
I figured out how to do this. See
http://blogs.msdn.com/b/youssefm/archive/2009/06/05/introducing-a-new-datacontractserializer-feature-the-datacontractresolver.aspx
and
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.datacontractserializer(v=vs.85).aspx
for guidance. Hope this helps.
I thought that I could create a WCF in and call it in Silverlight. I would inject an interface to the WCF. Then in my unit test I would mock the wcf....
However when I actually got to do this I notice that the interface does not actually have the methods that I am calling.
ie
myWCF.myfunctionCompleted(myhandler);
myWCF.myfunctionAsyc("test");
How to people typically accomplish this?
I would create a MyWCFService class which would wrap all the work calling out to my generated WCF proxies.
This helps in a few ways:
Gives you a single point to keep all of the code related to calling WCF (which can be quite a bit with proper error handling).
Gives you a class you can mock out for calling.
Gives you an opening to easily replace WCF if you need/want too by not avoiding WCF specific code being sprinkled everywhere (unlikely but you never know).