I have tried googling for an answer since last week and haven't found anything. Maybe I'm just searching with incorrect key words...
Basically, we have a running WCF service and then we have a separate dll with another ServiceContract in it. We want to know if it is possible to expose the separate dll in the current running service and if one can, how?
We are still new to WCF, so please excuse if this is a stupid question. :(
We are working with .NET 3.5 SP1 and C#.
Regards
EDIT:
We want to separate our service into "modules". So the service implementations (Methods, ect) and contracts (Interfaces) are all in separate libraries. So lets say you have a module called "Clients". We want everything related to Clients to be in the same separate library (DLL) instead of one big base class that inherits from multiple interfaces. This is a huge service and we need multiple developers to work on different sections of the same service at the same time. This is what I've been instructed to figure out, but if it can be done then it can't. I hope this makes more sens??
Assuming you are asking how you can implement a service contract declared in one DLL in a service running in a separate DLL/Application:
Edits to match post edits
add a reference to the DLL with the service contract to the application containing the service
In the .cs file with service implmentation add a using statement for the namespace of the service contract
derive the service from the service contract (you will have problems if you define your service contracts as concrete classes rather than interfaces and you want to expose multiple contracts on your service
If self hosting then create a ServiceHost passing the type object of the service in the other assembly, if IIS hosting create an .svc file referencing the class in the other assembly as the service
Add a service element in the config file naming the fully qualified name of the service
Add an endpoint to the service at a unique address for the new contract
When you take the other assembly (dll) as a reference in the "main" project, then add a using directive to the file where the WCF service is instantiated. Then you can simply use the referenced service contract to set up a running service with the right endpoints and binding(configuration).
I guess one work around is you have a main ServiceHost hosting your WCFMainLib and then all your clients will connect to WCFMainLib.
WCFMainLib then acts like a proxy to connect to all other WCFModuleLib on localhost (or other servers) to fetch data.
WCFMainlib will implement the IWCFModuleLib1, IWCFModuleLib2 etc service contract interfaces and expose them to the WCFClient. Actual implementation of interfaces will then be a call to the actual WCFModuleLibs.
This may introduce some overhead, but overall also introduces several "features" that may benefit your boss or service availability.
OR, if you are just wanting to delegate programming work, maybe you can tell each team to work with partial classes for your WCFLib with each service contract on a partial class then do a nightly compile.
Related
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 have 3 projects in my solution.
A common class library named ReportBuilderLib
A WPF application named ReportClient that contains a service reference to a 3rd project -
A WCF web service which contains web methods for my application to call upon.
Initially when setting up both the service and the application i added the common library to references on both projects so that i could use the classes i needed to in both.
It quickly cam clear that in the process of generating the code to use the web methods in my client application, it was automatically importing certain namespaces that i had used in service application.
This was throwing me conflicting reference warnings as they were effectively being imported from two separate resources.
I then removed the reference to the library in my report client, i could see that VS was only importing one out of the two namespaces my client requires. Both of which are returned by methods in my ServiceContract!
Having looked at the generated code for the client, it seems to be re-creating the classes i have included in the library and providing only the public properties for access.
Is it possible to use librarys like i am trying to with WCF. Or should i scrap the common library idea and simply create some data transfer classes on the service end?
You should be able to reference the common library on both ends, but it may be useful and less of a headache to implement data transfer classes like you suggested. Using special classes (or serialization like JSON) to send and receive data from the service would make it easier for you to re-use the service for multiple client projects.
Any time you decrease the coupling between layers of an application you make it easier to implement changes/upgrades in the future :)
I have some member functions in three custom classes already created in my service. My objective is to use these custom classes on the client side to access the the member functions in the service. How do I expose these classes with all the member methods in them to the client?
I created these three classes in my service and marked them as "DataContract", and the member functions as "OperationContract". I created an Interface that defines these custom classes as OperationContracts returning an object of each of the classes through implementing them on a separate class.
Unfortunately, I couldn't achieve my objective because two of the classes have a constructor that takes some parameters, whereas the class with no constructor was accessible on the client side but I couldn't see the member methods in the class.
I need your hints on what to do.
That won't be easy to do. One way would be to share the DataContract-decorated types between the WCF server and its clients, i.e. add a reference to your service assembly in the client project and bind the service reference to that assembly reference.
However, that breaks contract implementation independence, as the exact same service assembly will need to exist on both the client and the server, and be kept synchronized every time it changes.
See here for more details.
By default and by design, WCF will only share contracts between client and server, e.g. your services ([ServiceContract]), their methods ([OperationContract]) and the data structures they operate on ([DataContract]).
WCF is a message passing system, so all the client and the server share in terms of the data being passed around is a XML serialized message format. When you add a service reference, the client-side proxy will generate a class for each [DataContract] that will look identical in XML serialized format - only the data is being moved back and forth - no behavior (no methods).
Basically, if you want to expose functionality, you need to have a service method decorated with a [OperationContract] attribute. Methods on your data classes will never be visible to the client - and that's by design.
If you control both ends of the communication and both are .NET based, you can "trick" your way around this limitation:
put all your service and data contracts into a separate class library assembly
use a reference to that common, shared assembly to create your service
before you do an Add Service Reference, add a reference to that common assembly on your client
In that case, the WCF runtime will reuse existing types from that common assembly, instead of re-creating them from the service description. And since that assembly contains the shared code that the server also uses, your classes also have their methods present.
It works ok in a .NET only scenario, but it's really kind of a dirty trick behind the proper service separation facade.
We have lots of WCF services that are only used by our own code; the code that uses them is mostly in the same solutions files that contains the services.
However they do not use a shared assembly for the contracts, so each time a data contract is change the reference to the service has to be updated by hand in all projects that use the service. (Then the code needs to be fixed up by hand)
So how do I do a simple refactoring like renamed a data item in a data contract?
Is there a way to update all references to services in a single solution with one command, rather then having to click on each reference in each project?
You may have already answered you own question here.
Move your data contracts to a shared "Contracts" project, which will allow you to use the built in Refactor -> Rename option in Visual Studio to change the name, with the change being reflected in all of the projects in the solution.
Update
To clarify, the Contracts project is an internal "organisation" of your contracts. It allows many of your projects to reference one set of contracts. For example...
WCF service exposes "List GetCustomerById(int id)".
WCF service may call down to a processing layer, which might need to calculate something using another project etc. All of thes projects can use the single "Customer" definition from your Contracts project.
Any consumer of the WCF service would get the definition of the Customer via the service reference. You wouldn't share your Contracts project or send the dll for their use.
With your current settings you can't do it because you are regenerating the proxy each time. This is good from SOA perspective as data contract should not change very often. But if you are controlling both client and service and it is all .Net you can do as Shonee suggested. Use the /r option in svcutil to generate the proxy from the common assembly. Then you can refactor easily.
In C# (other .Net OOP languages as well), I have 2 webservices. Svc1 returns a complex datatype which becomes the parameter for svc2. Note that it is the same complex type.
Now, I create the 2 proxy classes of these 2 webservices. Which means the same type gets generated twice.
How can I make sure that in 2 proxies only one copy of that type is there? You may assume same or different namespaces of 2 webservices.
Generate the two proxies at the same time:
svcutil http://example.com/svc1?wsdl http://example.com/svc2?wsdl
If the type is really the same (name and namespace) in both services it will generate only a single proxy class for the client.
Yet another possibility is to generate the proxy class for the first service:
svcutil http://example.com/svc1?wsdl
compile the generated .cs file into an assembly for example MyAssembly.dll and use the /reference option when importing the second service:
svcutil /reference:MyAssembly.dll http://example.com/svc2?wsdl
This will look for same types in the WSDL and the supplied assembly.
I've run into a similar issue recently; I haven't tried Darin's advice.
Miguel Castro of IDesign gave a great presentation on "WCF the Manual Way… the Right Way" at the March 2009 DevConnections. In that he showed how to reuse service contracts and proxies. From my notes:
One assembly for Service/Data Contracts
Shared between client & server
One assembly for services
Permits changing host and reusing
One assembly for proxies
Reuse among clients
Separate application for hosting
Do not use "Add Service Reference"
Service (POCO) project references Contracts (interfaces) project and System.ServiceModel
Client Proxies assemblies reference Contracts assembly but not Service project
Client applications instantiate proxies
Our company hasn't made the move to WCF yet, but this looks like the way to go (to me).
EDIT: I found an article by Mr. Castro on this.