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.
Related
I have a solution with the following structure:
Domain (.NET 4.6.1)
DAL (.NET 4.6.1)
BLL (.NET Core 2.0)
API (.NET Core 2.0)
I have a requirement to submit data to an external WCF service. I personally do not have a lot of experience with WCF as I have been working with REST APIs. So to try out consuming a WCF service, I have set up a .NET core console application in and added a connected service reference to it. This resulted in a generated Reference.cs with the following classes:
IWebService
IWebServiceChannel
SendResponse
GetResponse
WebServiceClient (implementing IWebService)
I was thinking about creating a SubmissionService class in the BLL layer to submit data to the WCF service, so I moved IWebService from the console app to the BLL layer to inject into the class and perform unit testing. The attributes defined on the IWebService requires a reference to System.ServiceModel which comes with a lot of baggage and it does not make sense to reference it in my BLL layer.
I am not sure where to put the WCF client in my project structure. I have been investigating this issue and the only viable solution I can think of is to create a class library project purely for the WCF client and reference that in my BLL layer to have access to IWebService and mock it for testing. Has anyone been in the same situation? Any help is greatly appreciated.
You are missing a 'layer', namely the Composition Root. (for a more detailed explanation, see section 4.1 of this book).
You can define your own application-specific abstraction that allows the BLL to talk with the WCF service (through that abstraction). That abstraction can be located in the BLL.
Within your Composition Root, you can create an adapter on top of that application-specific abstraction that calls into the WCF service, using the WCF client, which can be generated inside the Composition Root as well.
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?
Let me try to make this as simple to understand.
I have three components:
Class
WCF Service
Console application for testing
The class is your standard constructor/properties/fields/methods.
The WCF Service references the class. One or more of its methods will return an object of the class.
The application references the WCF Service. Application invokes method that will return object of class.
How do I use the class at the application level without referencing it directly? Is there some code or attribute for the class that will permit this action?
I have one WCF service with multiple endpoints. Each endpoint has it's own configuration.
My problem is that I'm trying to figure out what will be the best.
1 - Add to my MVC application a service reference to each of the endpoints
2 - Create new DLL that will have the references to each of the endpoints and then add in my MVC application a reference only to this DLL.
I could really use your help to figure if there are any downsides to each of the approaches?
UPDATE
i forgot to mention that i have multiple MVC applications and each one uses only one or two of the WCF services.
to be more accurate, i now have 6 MVC applications and 7 WCF services. each MVC application uses only 2 WCF.
in the future the number of MVC apps and WCF will grow.
I would not use a server reference but just point svcutil to all three at the same time. It will generate one set of proxies and one configuration. It also allows you to share data contracts between the services.
Personally, I always put my web references and service references in a standalone assembly called SharedServices. That way; multiple assemblies can share the same references and datatypes can be shared among assemblies. Attaching a web reference to an assembly could lead to many projects being dependent on that assembly solely for the web service defintions.
You can write a service agent that is responsible for accessing the services, abstracting away this logic for your MVC application. The service agent would also be the place to implement other logic like caching, if you would ever need it. See http://tinyurl.com/cbcepgl, below under 'service agent' for some demo code.
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.