I have a win32 application that uses client side plugins and uses a Win32 Service via TCP/IP. I would like to also dynamically load assemblies on the WCF service based on the addition of new plugins. Currently I have to add the the ServiceContract and OperationContract to the Services class and IService interface and then re-compile. Is there a way to dynamically load the WCF assemblies and not have to generate the class and interface references? Can these be moved out of the WCF Win32 service into external classes?
I was wondering about this as well, but came to the conclusion that this was not a question of whether or not its possible, but should you do it? Even if you could generate the contract definitions dynamically, you still need to notify the client of the change, they in turn would need to regenerate the proxy in order to interact with the new service definition, and then provide an implementation dynamically. A better approach is to redesign your service so it implements a particular strategy (read Strategy pattern). The contract remains static, but the implementation changes based on client input. That way your service can dynamically load modules without your client being aware of it.
HTH.
Steve
Related
I am going to write a WCF service and need help in structuring the project for the below scenario:
Client and Service are going to share data contracts assembly-> http://code-magazine.com/Article.aspx?quickid=0809101
WCF is in turn gonna call multiple services to populate data contract using Automapper.
What are the best practices to structure a WCF project? and how to best wire-up automapper in the middle of WCF project?
I like to structure my WCF solutions like this:
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
Service implementation (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
Service host(s) (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:
Client proxies (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 !
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.
Is there any possibility as a client to get a list of contracts a WCF host exposes?
I would like to query a service and to ask what interfaces it implements.
Take a look at WCF Discovery.
This is not supported by WCF.
You can query the service's WSDL contract, but not the WCF contracts or any Interfaces.
The best you will be able to do is to see what is exposed, and assume that is the interface. You will not be able to see all the different interfaces that the class implements. For example, if you had a service which implemented IFooService, and IDisposable, with IFooService exposed through WCF, you would be able to see all the methods of IFooService from the client.
The WCF Test utility will take a given wsdl and generate a client for it, looking at the source for that might be a good starting point. (you'll have to decompile it with something like reflector)
Another idea, You could programatically invoke svcutil to generate a client for a given wsdl, then invoke msbuild to compile it, and use reflection to load the output assembly. It would be a fairly large amount of work, and I'm not sure what you would do with it. You would have to build a fairly complex UI to inspect and invoke the client.
In general (web) services are being described by XML-based protocols such as WSDL. This is used both for discovery of the services and for describing their operations. Also UDDI is sometimes used but mostly for Enterprise Application Integration (internal use).
So you can have your WCF service produce WSDL information and let your client query that.
Is it possible to have the proxy classes that are generated when setting a service reference implement INotifyPropertyChanged?
In this case it's a silverlight app referencing a WCF service?
Update:
The SlSvcUtil.exe commandline utility is part of the silverlight SDK installed {Program Files}\Microsoft SDKs\Silverlight\v4.0\Tools will generate the classes with an INotifyPropertyChanged implementation.
I'll leave this question up, as I live in hope that someone will say this is possible from Visual Studio without haing to launch an external tool.
Proxy classes do not implement that interface, only DataContracts do. If you open .svcmap file generated by adding service reference in XML viewer you can change EnableDataBinding element to true and update service reference from VS. I thought that true is default value and you have to manually changed it if you don't want to use INotifyPropertyChanged. What is so specific in your service?
I have a windows workflow foundation 4 service and a simple client.
When I add the service reference in the client visual studio doesn't generate a proxy class,
only the interface and types.
Anybody have any solution?
What should I do to work with the wf4 service properly? What kind of namespace and classes and contracts I need to use?
Thanks!
When the client project is a workflow project type setting a service reference works a bit different. Instead of generating the standard proxy classes it generates Send & ReceiveReply activities for use on a workflow. Very nice if you are building a workflow, not so when you want to call the service using regular code.
You can either use SvcUtil manually to generate your proxy classes or use the ChannelFactory with the generated interface to create the required proxy object. The last is usually the easier option.