===
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.
Related
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.
I wish to use proxy objects in c#. I will probably implement the networking through Windows Communication Foundation. So far I've just made a very basic WCF service which works on different processes of on the same computer. I want the client class to be able to use the real object on the same process and use a proxy object to access the real object across the internet. Now I can manually make an interface for all the methods, I want to use across the internet, manually make a proxy class which calls a service foe each of those methods, and manually create each of those services on both the service host and service client.
However is the any way I can get WCF or any software to automatically create the interface and the proxy class?
It sounds like what you want to use is svcutil.exe, which is intended to read a service's metadata and create C# classes.
Documentation is here: http://msdn.microsoft.com/en-us/library/aa347733.aspx
and more specifically here: http://msdn.microsoft.com/en-us/library/aa751905.aspx
There are a broad (very broad!) range of options controlling the proxy classes that are generated. At its simplest
svcutil http://service/metadataEndpoint
will read the metadata and create C# classes in one go.
Alternatively, if you're using Visual Studio 2005 or above, right-click on a project, choose "Add service reference..." and follow the dialogs to generate client proxies. This allows you to easily customise the proxy classes.
Note that you will need to publish metadata of some kind for the utility to work. See here: http://msdn.microsoft.com/en-us/library/ms734765.aspx for details on enabling this.
I have a class as DataContract in my webservice and it inherit from IEquatable.
But my siverlight webservice generated proxy class does not have equals. Can any one tell me why this is happening and is there a way achieve this?
WCF serializes only data from data contracts - no methods or behavior.
That's by default and by design - after all, WCF is a message passing system - you pass around serialized messages only.
WCF is NOT a "remote-procedure call" or "object remoting" system and thus, when creating a proxy, it will make sure the data signature on the wire will be identical (by means of XML serialization) - and that's all it does.
The only option to achieve what you're looking for would be to:
create a separate class library assembly that contains the service and data contract classes
reference that common contract assembly from both your server-side service code, as well as your client-side Silverlight app
when creating a service reference now, Visual Studio will reuse the common, shared classes in the assembly, and not re-create proxy data classes (and loosing the methods in the process)
I've got a situation where I have several web services that I need to consume. I need the ability to perform custom actions in the constructor of the proxy before any calls are made (assigning the configured URL, assigning the SOAP header, etc.).
My first solution is to create a child class that derives from the generated proxy, then make those actions in the constructor of the child class. That way, app code can call the constructor of the child, and get a valid proxy that has the stuff I need.
I'm trying to prevent the app code from calling the constructor of the generated proxy, so people don't accidentally instantiate the proxy without doing my custom stuff. My first thought is to move the generated code into a separate assembly from the child, and make sure the app code only has a reference to the child assembly. This works for the most part, but...
The services contain complex types, defined in the proxy. I need the app code to reference these classes, which means the app code needs a reference to the base assembly anyway, which means they now have access to the generated constructor.
I've tried an overly-complex solution of wrapping each of the generated complex types in an interface, and then hiding the real calls and replacing them with copies of the object as the interface type. This worked once or twice, but it gets ugly really quick.
It seems that the only way I can have everything I want is to remove the public constructor of the generated proxy, and replace it with a protected constructor, then allow a reference to this assembly - they'll be able to work with the complex types, but won't be able to call the constructor. My problem is that the only way I can think of to do this is to manipulate the generated code to change the constructor.
Any ideas? I'm using WSDL.exe to generate the proxies, and there's no option there to hide the constructor. Is there another way that I'm just missing? I suppose I can write a tool to automatically modify the proxy immediately after it's generated, but that just feels ugly to me.
Thanks
Are you stuck using .NET 2.0? If not, then you shouldn't be using WSDL.EXE. You should be using SVCUTIL.EXE or "Add Service Reference".
Instead of creating a derived class, you should create your own wrapper classes, which use the proxy classes. One would use something like MyWrapper.CreateProxy(), which would return a properly-configured instance of the proxy class.
BTW, WSDL.EXE creates proxies using the legacy "ASMX" technology, which has no ability to use the types from the service.
I ended up going with modifying the proxy generated code to make the constructor protected instead of public. The call to WSDL.exe was handled in an automated project already, so it wasn't that big of a deal. This was really the only way I could get everything I wanted.
Instead of doing that, why can't you override the GetWebRequest method? It will be called before the service method call anyways.
If you have added a service reference, implementing message inspector will do same thing.
I'm currently trying to call a WCF service dynamically See here, therefore, I'm trying to understand what happens behind, when I add a service reference by the GUI of Visual Studio... What's generated..? An object is created and an implicit reference is created...
Are the references contained in a specific container, a sort of pool?
When you add a service reference, VS generates a proxy class for the service. This class implements the interface defined by your service endpoint as its ServiceContract, so it appears to consuming code as if it were the actual object performing the operations, but it contains and uses the communication channel defined by the endpoint and bindings to call the exposed service methods.
If you do not have classes that conform to the signatures of the DataContracts required by the service, VS will generate those classes as well, but if you have already referenced classes that are marked identically to the DataContract (usually because you've referenced the project containing the DataContracts in the project with the client-side code) it will simply use those. Svcutil (the command-line tool) can be given a reference list of locations for these DataContracts as well.