If I use svcutil, I don't think I can generate server side code because all interfaces generated don't have ServiceContract attribute and all model classes don't have DataContract and DataMember attributes.
So what is the best way I can create my WCF service from existing WSDL?
Related
I have a WCF service that calls another SOAP service (that I don't have control over). I would like to return the dependent services proxy types to my services clients.
I have done this manually by adding DataContract and DataMember attributes to the proxy classes.
Is there anyway to automate applying these attributes to these proxy classes?
So the problem I was having was that when using add service through visual studio 2015, it passes a flag that generates IPropertyChangedNoify on the objects which when trying to reuse a proxy class that has been generated from an external source this would cause WCF test client to throw an exception when adding a service that was returning such type.
My Semi solution so far was to use svcutil manually.
svctuil /namespace:*,<MyNameSpace> path-to.wsdl /out:MyClass.cs
I'm now able to add my service that uses an external proxy class as a return type.
The next problem I'm having now is that WCF test client won't let me call/test the method, because I'm using this type. WCF hover note says "WCF test client doesn't support this method because it uses 'MyCustomType'". And the method is grayed out.
I'm getting closer, to the solution.
Im doing a client server application. The server part is implemented with a WCF service. The WCF service exposes data types via service contract. The client is modularized and uses MEF for DI. In the client I have a infrastructure module that references the WCF service. The infrastructure module knows about the WCF data types. My question is , is it possible to let the other modules that references the infrastructure to know about these data types without adding a reference to the WCF service in every module. Is there any way of of exposing the WCF data types
Normally, you have a contract dll. This contract dll contains the service interface and all dependent classes. Your WCF service and any client component will then reference this contract assembly.
As the contract assembly only contains interfaces and POCOs (Plain Old CLR Object, only data, not methods or logic), it can be referenced from virtually anywhere without giving away anything about your infrastructure.
nvoights answere is probably the correct one here however it is also worth mentioning that if you control both server and client then you can if you want put common objects in a dll consumed by both and ignor the WCF generate types. In some senarios that works out better than managing both the server types and the WCF generated equivalent types.
Whats the use of xsd files generated for xml types, operation contracts and data contracts.
Isn't the information in wsdl file is sufficient to generate all required classes.
By default WCF generated WSDL has reference to external xsd files to describe the types in the SOAP messages. This is a multifile WSDL as opposed to single file WSDL. You can use WCF Extras library to generate single file WSDL if you wish.
It depends on WSDL generator. WSDL always needs XSD description for message types, custom headers, faults and data types. These descriptions are needed on client side to built the proxy and to know what type of data do you need to send or receive from operation. It describes serialization of data types.
Some generators inject these XSD directly into WSDL but other create separate files and only include these external files in WSDL.
Is it possible to add a service reference in visual studio, which generates the local proxy class to call the WCF service when using the netTcpBinding?
As I understood it, the service reference method requires a WSDL to be exposed by the service, which is only supported by the http bindings no?
Perhaps, could I add the service reference locally in development, but then switch the configuration to use nettcp at runtime in production?
The reason I am asking is because I am hosting in a windows service (server 2003, so no WAS, and can't use IIS). And we are unable to change the permissions to do the HTTP namespace reservation ... so we can't use the HTTP bindings. NetTcp works, but in this specific case the object graph we're passing back and forth involves objects generated in the service by an EDMX model ... so we can't share it in a contract assembly.
Thanks in advance!
Simply add a binding using mexTcpBinding.
Is it possible to add a service reference in visual studio,
which generates the local proxy class to call the
WCF service when using the netTcpBinding?
Yes, most definitely!
As I understood it, the service reference method requires a WSDL
to be exposed by the service, which is only supported by the http bindings no?
No, definitely not - WCF metadata (either its own specific format, or exposed as WSDL / XSD files) is definitely available for all SOAP-based calls - regardless of their transport.
Can you show us what you have, in terms of server-side config? Most likely, you're just missing a little config setting or something - if we see what you have, we might be able to pinpoint that and help you more!
All bindings are exposed though WSDL. If you add the NETTCP bindings svcutil will atuo generate the client correctly. I haven't used it in the ADD reference in VS as i have always preferred to generate the class with svcutil.
I need to upgrade our web services to use WCF instead of ASMX. If the signatures of the web services stays the same, will existing clients that already call the ASMX service have to change anything on their end? Is there anyway to still use WCF but not force them to change anything?
Option 1 :
Using the current ASMX's WSDL, generate the client using svcutil.exe
Grab the generated interface and create a WCF service based on this interface
Output : One new WCF endpoint configured with basicHttpBinding. Clients need to update the URL at which they're sending the messages.
Option 2 :
Refactor your ASMX code. Move all the logic into a separate DLL.
Create a WCF service and use the logic in the refactored DLL.
Output : 2 endpoints, one for ASMX and another one for WCF
If you use the BasicHttpBinding for your new WCF service, and implement the same methods with the same message structure, existing callers should be able to call into this new WCF service without any change on their part.
There's also an AspNetCompatibilityRequirements attribute in order to get around some potential compatibility issue - see the MSDN documentation on it.
Marc