I am using a web service. I define an interface in the web service.
Can I use this interface definition in my project that invokes the web service? I know I can use classes defined in the web service.
Do I have to do anything special with the interface like add an attribute?
Before you generate the service client add a reference to the assembly containing the interfaces and enable the option "Reuse types in referenced assemblies" in the client generation interface. It should use the already existing types instead of generating new ones.
Related
I have an ASMX web service which is being called using Soap protocol. The service is using request / response types from one of our shared projects.
The project that consumes this service is also using the shared project. Now, I want that the reference that's been used in the project for that service should reuse the types being used in the shared project.
If that is not possible then can we inherit the service from an interface and then the wsdl tool can generate the implementation of the interface by inheriting from required classes?
Will WCF be an alternative?
I have an ASP.NET project that exposes multiple WCF Services.
Most these services make use of common custom classes in the APP_Code folder used throughout the project.
Consuming these WCF services is a console app I have written.
My question is :-
In the console app I obviously instantiate each of the WCF services I'm using - but some of these services utilise the common classes as parameters to some of the methods.
However on the client side (console app) - those classes are exposed exclusively as part of that WCF Service's namespace and not interchangeable)
Example of syntax error is something like :-
cannot convert from 'ManagementAgent.Computer_ServiceReference.ComputerIdentity' to 'ManagementAgent.WorkloadAnalysis_ServiceReference.ComputerIdentity'.
The class "ComputerIdentity" is a commonly shared class in the App_Code folder.
How do I get this class interchangeable as a parameter across multiple WCF Services?
Your shared classes need to come from the same assembly, not just shared code. Put the classes you want to share into their own class library and reference that in all projects.
In my application, end user can fetch the data from any SOAP based web services and use it in the application. The application provides an option to register the service on fly. The application examine the service, show available operations along with parameter, finally execute the selected operation and use the response, of course everything will be on the fly. There are few steps need to be follow in order to achive that:
Discover the service through WSDL
Examine it and select a method
Build required parameter values
Execute the service
Handle the response
I am able to discover the service on the fly using some WCF classes like DiscoveryClientProtocol, WsdlImporter, ServiceDescription, ServiceContractGenerator, etc. Now, I want to execute them and take the response XML that is available inside SOAP Body.
I am able to execute it by generating the Assembly at runtime using above library and execute a method through reflection. This solution works fine if I have to do everything in single-shot on a box. But it adds complexity when we scale-out. That means, one server generates the proxy, another one use the proxy and consume the services.
Yes, we can keep newly generated assembly somewhere in shared location and use them. But I want to avoid them. We want to keep service definition locally somewhere in DB, execute it without generating assembly and just consume the XML available inside SOAP body.
Appreciate the advice in advance on how to achieve this?
To communicate with WCF services without code generation you use the ChannelFactory< T > where T is the service interface.
Obviously in your case the service interface is not known at compile time so your objective would be to dynamically generate this type, or better yet use a custom ChannelFactory implementation that does not rely on strong typing and lets you call methods in a dynamic or programmatic way.
You can use the WsdlImporter to import the WSDL at runtime and which can give you the ContractDescriptions. From there you might be able to use ContractType as your service interface but I'm not sure. You may need to write your own ChannelFactory...
You can implement ChannelFactory to your abstract generic BaseFactory class which has override CreateDescription method to set Binding and Endpoint for ChannelFactory.ServiceEndpoint. You can pass your configuration interface which has Binding, Endpoint and Credentials to this abstract class. So you can have a dynamic proxy for a wcf service.
I have an asp.net Website that has access to database and has functions which I want to allow 3rd party users to use.
Is it possible to add WCF project/ WCF service to my solution so i could let 3rd party member having access to my methods?
We tried myWebsite->Add New Item-> Wcf service/wcf data service but that doesn't seem to work.
Any help would be great.
It's not working because you are trying to add a reference to an existing service for consuming it. You want the exact opposite.
For this, you will have to create a separete project of type WCF Service in your solution.
More info on creating WCF Services can be found on MSDN.
Keep in mind that if you want to expose certain features through the service, you will have to factor the functionally out of the website to another project that both the WCF Service and the website can consume.
You should be able to add a new WCF service project from the solution root in Solution Explorer...
Right-Click >> Add >> New Project
It's not clear from your question what 'doesn't work' though.
Your newly added project will need to reference the existing project that contains the methods that you want to access. You should perhaps consider if your current design is appropriate - ensure that you have separated out your presentation code (this should be your website project) from the common business functions that you want to share (I would have this as a separate class library project in the solution). Your WCF project can then reference the common 'business logic' project.
To reference your 'business logic' project from the WCF project...
Right-Click (on WCF project) >> Add Reference
Not sure what "doesn't work", but MSDN providers a walkthrough for adding a WCF service to a website here:
How to: Host a WCF Service in IIS
This has the step-by-step of creating a WCF (both markup and code) and adding the relevant web.config entries by hand rather than using the "Add Service" dialog.
If you create a separate project in your solution to run your services, you will need to reference your existing website project using the Add Reference option on the new service project. This will allow you to use the classes and functions defined in the existing project inside your new service project.
Disclaimer: My experience/knowledge of web services is very limited.
There is an existing web service WSDL that I have reverse engineered with wsdl.exe to create a C# proxy class.
Using Visual Studio 2008 I created a default web service template.
How do I reference the generated proxy class so that it will work in the web service?
For example -> calling http://localhost/webservice/service.asmx?WSDL will return the details from the proxy class.
First of all, you should not be using ASMX web services. Microsoft now considers them to be "legacy technology", and suggests that all new development of web service clients or services be done using WCF. Don't start off at a disadvantage.
Secondly, the normal way to make use of a WSDL is to use the "Add Web Reference" command in Visual Studio ("Add Service Reference" if you were using WCF). This generates the proxy classes for you and adds them to your project.
I'm not sure from your question that this is what you want, since you first talk about the WSDL, but then talk about a "default web service template". What do you mean to do with the "default web service template"?
Try using the svcutil.exe program (not WSDL.EXE) as follows:
svcutil YourWsdl.WSDL /language:C# /d:subdirectory
This should produce a number of files in the subdirectory. Take a look at the .cs files, one of which will contain an interface which is the service contract. That is the interface that your service must implement. Look at your "default" WCF service application and you'll see that it does the same thing - produces an interface that is implemented by the service.