We Keep Coding

Not all namespaces coming across over WCF reference

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 :)

Can we add remove namespace reference (usings) dynamically in C#

I need to invoke WCF service 1 or WCF service 2, based on certain condition evaluated at runtime. Both the services are similar but hosted on different servers.
I have added two service references, NS1 and NS2 pointing to different urls. Current code already uses NS1. Considering this NS1 implementation has already been done at many places. What would be best way to refactor the code, to select dynamically which service has to be invoked ?

In general, it is considered a bad practice to program directly against the proxy generated by the svcutil.exe.
The best way is to wrap it in a class of your own and reference this class each time you require the service. This will also allow you to implement more advanced business logic such as routing (in your case) and other cross cutting concerns.
For example: you can now abstract from the application the strategy you are using to connect to the service, i.e. Service reference or ChannelFactory. You can easily share the service between different assemblies without ambiguity.
You are saying that you have much code written directly against NS1. Grind your teeth and wrap it. It is a lot of dirty work but the risk is very low.
Having said the above, I wonder about the requirement itself, where a service calls another instance of itself on another server (if I got you right). This smells funny, what is the problem you are trying to solve?

Sharing WCF Service Contracts with Unity

I am fairly new with WCF, I'm looking to share a service contract and data contracts between service in one solution and a service consumer in another solution. I have created a seperate project which is shared between both solutions that contains both the service contracts and the data contracts. When i reference my service The data contracts are being shared but not the service contract. My contract looks like the following:
[ServiceContract]
public interface IDistributionService
{
[OperationContract]
[ServiceKnownType(typeof (Distribution))]
bool AddDistributions(Distribution[] oDistributions);
}
When I look at the reference.cs file I is using the Distribution objects but it's generating the IDistributionService contract again, here is an excerpt of the reference.cs file:
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(ConfigurationName="eDistributorService.IDistributionService")]
public interface IDistributionService {
[System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IDistributionService/AddDistributions", ReplyAction="http://tempuri.org/IDistributionService/AddDistributionsResponse")]
bool AddDistributions(mhcb.syd.eDistribution.WebServices.Contracts.DTO.Distribution[] oDistributions);
}
Is there any way of getting the consumer to use the IDistributionService interface without generating the concrete instance in the reference.cs file?
The main reason I want to know is so that I can use dependency injection (unity).
.RegisterType<IDistributionService, DistributionServiceClient>(
new Interceptor<InterfaceInterceptor>(),
new InterceptionBehavior(container.Resolve<IInterceptionBehavior>()))
Thanks again!

Firstly check that you are instructing the service reference tool to 'reuse types'. When you go to 'Add Service Reference...', click 'Advanced' and confirm that the 'Reuse types in referenced assemblies' option is checked.
If this is checked (which I believe is the default behaviour), then you might not be able to do what you want by adding adding a 'service reference'.
Sharing a contract is the preferred WCF pattern (in my opinion), but the implementation I normally take is to use the ChannelFactory class to instantiate the client connection rather than use the generated proxy. The generated proxy is fine - it's quick and easy - but it is clunky and requires maintenance.
Review this MSDN link on Using ChannelFactory vs Proxies in WCF for a discussion, and this CodeProject link for sample usage.

The code artefacts svcutil produces suck. But they are by far the easiest (i.e. cheapest) way to use the decoupling that WCF provides. Reusing contracts and entities is tight coupling of service and consumer.
If you want your container to generate client-side proxies for WCF services you can use an extension for Unity that does the trick. It supports the WCF4 discovery features as well.

WCF - Service Contract from another assembly

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.

WCF Service - Coding Standard - Where to put my class library?

I'm trying to implement a WCF Service in my program , howevery I don't understand something:
According to the book "Programming WCF Services" , Juval Löwy 2007 O'Reilly Media,.
Appendix C. - WCF Coding Standard C2 - Essential :
1. Place service code in a class library and not in any hosting EXE.
I don't understand this, where should I put my code? all my class are defined in my form application , How should I call my classes of the winforms from the Class Library of the service.
Am I missing here something??
Thanks,
Eyal

I like to structure my WCF solutions like this:
YourProject.Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario
YourProject.Service (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
YourProject.ServiceHost (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.
This basically gives me the server-side of things.
On the client side:
YourClient.ClientProxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.
1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.
That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.
This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !

Yes, it's a bit confusing.
We're talking about the service implementation here. What Loewy means here is that the code to implement the service should be in a separate project. The code that hosts the WCF service (i.e. the class that implements your service contract) should do nothing but call that service implementation code.
So your Windows Forms client application uses a proxy, which in turn calls the WCF service application hosting layer, which in turn calls your service logic.
It's a very good idea to go further and have three layers on the UI side and four on the service side. The namespaces might be
Company.Project.UI.WinForms
Company.Project.UI
Company.Project.ServiceClient
Company.Project.ServiceHost
Company.Project.Service
Company.Project.BusinessLogic
Company.Project.Persistence
For simpler projects this would be overkill, but for anything more than (say) one form or two service methods it will make life much easier. Not least, testing each layer in isolation should be fairly straightforward.

Here's a typical project structure following Löwy's recommendation:
MyProject.Data
MyProject.Logic
MyProject.Services
MyProject.ServiceHosts
MyProject.Presentation
Then MyProject.ServiceHosts will reference MyProject.Services and exposes the services defined there. So in Löwy's language, MyProject.Services is the class library, and MyProject.ServiceHosts contains the hosting executable.