I have been following this tutorial to add protobuf-net to my WCF project. I have a shared DTO library. Both server and Client use those DTO classes. I have attributed all my Service methods with [OperationContract] attributes, but i have not assigned any [DataContract] attributes on my DTO classes.
I added the protobuf-net Nuget package and added the configuration to the web.config.
I am using IIS Express to test my service, and thought that i should be ok with what i had done so far. However, after testing a few calls, i noticed that i forgot to add protobuf-net to my client and yet everything worked as expected (ie. no errors from serialization or deserialization).
I suspect that protobuf is not used in my program at all, and that i am missing something. I'd like to avoid using [DataContract] attributes but i could live with adding them, if that is what is need to get protobuf-net working.
What else am i missing?
A year ago I faced the same problem, where protoBuf seems to be an excellent option, with WCF it has some shortcomings.
I created an open source project to overcome these shortcomings, it uses protobu-net library and adds functionality to it, such that you don't need to share assemblies anymore with client. It however again requires you to put DataContract attributes though currently.
You can give it a try: https://github.com/maingi4/ProtoBuf.Wcf
DISCLAIMER: I am creator and owner of the above project.
Related
I'm looking for a way to communicate between different C# (only) apps via gRPC. Is there any way to provide service definitions and contracts by C# interfaces and POCO classes (attributed by ProtoMember, etc.), instead of creating a proto file and generating a code out of it? I need this to work on .net framework 4.7.2, i.e. working with grpc.core rather than grpc.dotnet.
PS: The main idea why I want this is to avoid the code generation part which seems to be excessive here. Also need to be able to specify custom attributes to my POCO classes, like DisplayAttribute and stuff.
Alright, looks like I found the answer https://github.com/grpc/grpc-dotnet/issues/68
protobuf-net.Grpc seems like the lib I was looking for
You can also check ServiceStack gRPC which provides code-first development.
I am having problems in working with the Namespaces in the WCF. I have never done it before. I have tried a lot to find solution on the google. But still I am not able to find a solution for it.
I have written a WCF service which is divided in 3 projects and additionally i have created a models project:
Contracts (ServiceContract)
Service (Codebehind)
Host (ServiceHost)
Models (DataContract classes)
When I am hosting the service in IIS, it is generating the WSDL fine but there are namespaces which I have not defined as below:
http://schemas.microsoft.com/2003/10/Serialization/
http://schemas.datacontract.org/2004/07/My.Models
The problem is that I want to access all my service contracts and data contracts through same namespace only.
Because when the DataContract classes are generated in the proxy class, it is being duplicated. Mean if I have a class ClassA in my Models projects, then it is giving me 2 classes as ClassA and ClassA1.
I saw that in proxy class that these are there in the different namespace. So, I want to avoid that.
I also want to avoid ChannelFactory method, because there are a lot of OperationContract functions. So, don't want to code that much with hand but would like it to be auto generated in right fashion.
Any help is greatly appreciated. Thanks in advance.
I also want to avoid ChannelFactory method, because there are a lot of
OperationContract functions. So, don't want to code that much with
hand but would like it to be auto generated in right fashion.
This makes no sense at all. The ChannelFactory<T>.CreateInstance() method is much lighter than a wsdl-generated service proxy, and the amount of code you will have to write is comparible.
Service references are designed for when you're calling third party services which you have no control over or internal visability of.
There is aboslutely no situation I can think of where using a generated service reference is preferable to using ChannelFactory if you have access to the service definition assemblies.
This is especially the case for your requirement to manipulate the service wsdl in order to control code generation on the client side.
===
I'm new to this, but already having a problem.I have silverlight(5) application with wcf service reference on it. Before using VS2013,proxy class on client generated properly, without implementing IExtensibleDataObject on DataContract types.Now i want build this,after update service references, i taking a lot of errors, that VS cannot implement IExtensibleDataObject, because of it not in System.Runtime.Serialization assembly.
How i can evade implementation of IExtensibleDataObject on my types? In my understanding, silverlight does not support this interface and therefore i cannot build my app.
thanks
It seems that you'll have to manually invoke the slsvcutil.exe tool before the build phase as stated here, rather than the usual svcutil.exe that VS uses by default.
Another ugly hack you can use is having a script that runs between the WCF proxy generation step and the code build that removes the interface implementation and the field inside the proxy class.
We facing a serious issue, but before saying that it's a bug in .net, I'd like to know if someone understand what's happening and why.
That's our configuration :
1 project DAL
1 project proxy
many others project that use DAL with WCF services as well.
They communicate with wcf services.
We have added some properties in one object in the DAL
We havn't updated service references in the proxy project.
(1)In the proxy with a breakpoint, we can see everything is retrieved properly except of course the new properties (service reference not updated => nothing abnormal)
The proxy is returning a JSON with WebMessageFormat.JSON ( we using the default provided serialization)
The response of the method called in proxy that call the (1) one in DAL is empty.
So it's definitely a problem in the JSON serialization ? no ?
Worst, we decided to changed from WebMessageFormat.JSON to WebMessageFormat.XML to see if the same happened, ==> It didn't
Last thing, no problem with other projects that hadn't been updated (they not using JSON ser)
Does someone have faced the same issue, or know why this is happening ?
Any help would be really nice :)
Thanks in advance to everyone and sorry for my english.
(This is not a definite answer, but a suspicion. However, this was too much to include as a comment.)
Note: I am assuming the following from your question (please correct/clarify if wrong).
The proxy project calls DAL through WCF and not the other way around. This would explain (1), and properties not updated through each layer.
A client calls the proxy project, which exposes itself through WCF too (this would explain the proxy project returning a WebMessageFormat.JSON response)
The issue here may be, as you say, with the serialization of the proxy response itself. While it's always advisable that you update your project references, in such a case it is possible that the generated classes are not mapping exactly to the response that they describe.
My take so far is that the changes in the classes had changed the internal responses in such a way that the references can no longer be mapped correctly to the response type, which is likely the ones from the mapped classes. The XML serializer is likely a separate implementation of the serializer, so it is likely that the JSON serializer has the problem failing on this specific case. You could check if this is the case by checking if there are any first chance exception in your internal output, or by adding debugging outside of your own code. This would likely confirm that the JSON serialization is facing an issue.
It may be actually be a bug, or an unsupported scenario when properties to map are not present.
I would advise that you use the DataContractSerializer with JSON if you are going to be consuming serialized JSON data from WCF (Set up your data contracts of course). I've ran into a few problems with JSON serializer, and realized it's a bit iffy with .NET
Another solution is to use this JSON serializer with .NET:
http://james.newtonking.com/json
Do you have object of type date or any other non primitive data type in the response data, I have faced problem when i try to include date object in the response data, for a quick work around I changed the
data type to string, it worked for me.
I am building a test-stub for a webservice, implementing the interface retrieved from the production webservice using svcutil. When calling a method on the stub i get the exception;
Object of type
'Sbsys.Services.HostService.DokumentBoks.DKALWSAfsendService.MaterialeType[]'
cannot be converted to type
'Sbsys.Services.HostService.DokumentBoks.DKALWSAfsendService.MaterialeType[]'.
where 'Sbsys.Services.HostService.DokumentBoks' is the namespace of the consuming client, and 'DKALWSAfsendService' is the namespace containing the generated proxy classes for the service.
Any ideas on whats going on?
Bonus info: When using the production service everything works as intended
Solved: I had a suspicion that it might be a versioning problem, and moved my servicereference to an isolated project, containing nothing else. Referenced this from both the consuming client and the webservice stub, hoping that this would solve any problems with building multiple times or whatever. Presto. Problem gone.
Any chance that the wsdl/contract in prod is different from the one you call against ? If the proxy has been generated against the prod and use on another instance of the service with a different contract, you might have that kind of weird message.
Sometime this error occurs because of Generate Serializable Assembly option in Project properties (especially if you are using per-generated serialization assembly using sgen). Try setting this option in Project properties to Off and see if it works. After you turn this option off you will need to per-generate your assembly using sgen. There is some good discussion and background thread in this Q&A for this.