I need to run some methods before the first call of a wcf service, where do i put those methods? Where is the startup method of a WCF Service?
Obs1: my WCF Service will run on a IIS6.
Obs2: i'm using .net framework 4.0.
One way to do this is to self host your WCF services (as in not in IIS). That way you can run whatever code you want to before spinning up the services.
Another way is to add a static method call in the constructor of each service behavior implementation. That static method call would do a check to make sure that the initialization had been performed. Just make sure to deal with multi-threaded concurrency during this call.
Depending upon life time configuration of your service WCF will either instantiate the service class on every call (singlecall), for each client (session) or just once for every call of every client (singleton).
You can implement IInstanceProvider interface and take control of the instantiation process. This way you can get a chance to call methods on the class before actual wcf call is done.
Related
I have a service reference to a WCF service that is hosted by a customer. The service reference has an interface which defines the service contract. I would like to create a service object which implements this interface so that I can add an instance of this to a local Service Host for testing purposes. This way I can fake the data back while still using the same service definition (though making a local endpoint).
The problem I have so far is this: the service only has one method (right now), GetString. The contract auto-generated two methods, GetString and GetStringAsync. It turns out that when I make a service based on an interface, it automatically generates an async method for each of the defined methods. Which means that my new service now has four methods:
GetString
GetStringAsync
GetStringAsync
GetStringAsyncAsync
If you caught that middle section, there are now two GetStringAsyncs, which prevents the service from starting.
Is there a way I can host a service based on a ServiceReference so that I can keep the same interface? If possible, I would like to prevent just duplicating the defined methods of the service reference in a secondary, as then I can just update the definition and the compiler will notify me when there are new things I need to implement. Also if I do that, my client library (which I want to have as much shared code as possible) will have to have two separate service reference instead of just a configurable endpoint and remote host that I can pass into the client constructor.
I want to Dispose of some objects that are created during a WCF service method, but I need to clean them up outside of the scope of the method that created them. When I'm working in ASP.NET, I normally call that code during the Application_EndRequest event.
If the answer is: there is no Application_EndRequest-like event in WCF, how should I go about cleaning up my objects?
You can implement IDisposable for your WCF service. If the service is configured PerSession or PerCall *context mode* dispose method will be called once the channel is closed and the service instance is dropped.
I am trying to implement a generic "IsAlive" capabilities to any wcf service hosted through my api. I tried adding an enpoint to the service host at runtime which uses a IIsAlive interface as its callback.
The problem is that wcf checks and sees that the service implementation class does not implement that contract. I dont mind this, i could resolve it later with runtime proxies or instance provider which will return my implementation of that method. So i need to suppress wcf from shouting at me, is that possible?
If not is there a way to achieve my desired result? ( to expose an api that has a host method and a get proxy method which will add isalive capabilities to the service without the user having to implement it)
Thanks
I created WCF service and faced with a problem. I need to update database periodically, but i couldn't find static method like Main, that whould do it without client interaction. What can i do??? What wold you suggest in such case?
There is no Main method (or similar entry point) in WCF. You need to host your WCF service in another process (such as a Windows service, or IIS or self host) to "activate" it and make it available to other processes.
One of the concepts in WCF is that you write your service code to do the function you need without having to worry about infrastructure and hosting. Once you have written your service logic, you can then decorate and configure your service to expose it to other processes. Using this approach means you can change how your service is exposed to other processes without re-writing the actual service logic - you essentially just change your configuration. Hence, a main entry point is specific to how you choose to host and expose your WCF service to the outside world.
Just Google around for "WCF hosting" and you will find lots of information.
If you don't need to expose your service logic to an external process (which sounds like maybe the case from your question) then maybe you don't need to use WCF and you can just write a plain old Windows Service.
If your wcf service is self hosted then you can do it in your application before publishing the service.
If it is in IIS then there really isn't application_start kind of thing since the host may be created on first request. See WCF application start event
I am relatively new to .Net and C# development and am having an issue decoupling WCF services from an app into a network DLL I am creating. The DLL's goal is to offer a simple way to host and access a service from a server and client application and to add some functionality to the basic service for heartbeat and automatic reconnection without each application having to specify heartbeat methods in their WCF services and witho/ut having the apps manage a timer for automatic reconnection.
The DLL offers a ServiceServer and a ServiceClient class that have these goals:
ServiceServer :
Creates and manages the ServiceHost instance.
Host a service from outside the DLL (passed as a generic).
Add heartbeat operations to the service to be hosted, as well as other operations common to all our client/server apps.
ServiceClient :
Creates and makes the client service reference available to the client application. The service reference (auto-generated) is also passed as a generic from the application.
Add heartbeat methods to the service reference for the client, as well as other operations common to all our client/server apps.
Automatic reconnection using a timer or similar.
So far I have tried to use partial classes, generics and static extension methods without success. The issue is that to make my DLL completely decoupled I obtain and create the service reference and service using generics; I am unable to extend the received generic type using any of these approaches.
I am basically trying to extend the client service reference with additional methods to be able to send heartbeats and such without needing another independent connection and service (which would make the heartbeat ineffective), and without the client application having to know anything about sending heartbeats and automatic reconnection. Likewise, I want to extend the service that the server class receives as a parameter to add operations and the implementation of the server heartbeat code and eventually other common-to-all-apps methods too.
You might want to explore this solution for implemeting hearbeats automatically in a wcf services.
http://weblogs.asp.net/cibrax/archive/2010/05/17/enabling-service-availability-in-wcf-services.aspx
The solution also provides an extension method for the client.
Thanks
Pablo.
No it will not work this way.
When you define the service you first create one or more service contracts (best practice is to use interfaces). Service contract interface has to be marked with ServiceContract attribute and each exposed method used in service has to be marked with OperationContract attribute. Then you create service class which implements these interfaces. Such class can be exposed as WCF service with endpoint for each interface (service contract).
No other approach works. You can't add extension methods, use generic or whatever else to "extend" implemented service. What you can is to inherit existing service class and add additional interface. Obviously this is not no code solution unless you create some very advanced code to generate dynamic data type at runtime (= emitting MSIL at runtime).