i have created wcf service and client. both wcf service and client are implemented using c#. i have hosted this wcf service in both iis and windows service. while i am hosting it, i need to specify the base address either in web.config file or in design time. is it possible to specify base address at run time. how to provide it at run time?
like this can i change the service reference address at client side. how to do it in c# ?
If you're using self-hosting, then you can specify the base address in the constructor of the ServiceHost class:
Uri baseAddress = new Uri("http://........");
ServiceHost host = new ServiceHost(typeof(YourServiceClass), baseAddress);
With IIS, things get a bit trickier.... you might be able to provide a custom factory to create your service host - but that seems like a whole lot of work. In addition, with IIS, the virtual directory where your *.svc file exists really dictates the URL of your service - so providing a base address really isn't of much value.
Related
Is there a way to host a wcf service:
without extension
with relative endpoint addresses (the server address should be known automatically)
without metadata (the contract is available for the client)
basicHttp binding
If something is not achievable i will accept that. Already tried a approach but got
no metadata -> Other Question.
If you're hosting a WCF (SOAP) service in IIS, you need a service.svc file (or at least an endpoint with the .svc extension using file-less service activation in .NET 4) so that IIS understands that this is a WCF SOAP endpoint and routes requests accordingly. In IIS, the virtual directory where your service lives basically determines your service endpoint's address, therefore you can use relative addresses (relative to the virtual directory) to define your service's endpoint address.
If you self-host your WCF service in a managed application (Windows NT Service, or just a plain .NET console app), then you don't need a .svc file - your managed app handles the requests - but at the same time, since there is no "hosting infrastructure" in place, you need to define a **fully qualified" endpoint address - you cannot just use a relative address (relative to what??)
So you can either have relative addresses (in IIS, but with a .svc file), or you can have no extension (with self-hosting, but then you must supply a fully qualified service endpoint address). You cannot have both at the same time.
Whether or not your service endpoint has and exposes metadata is just a question of adding (or not adding) the ServiceMetaData service behavior to your service definition.
I have a service and I need to communicate with it so I started investigating WCF. I setup the service to listen and created a client. All communication is working fine.
The service will be used by several customers. Instead of having them setup a client and go through the WCF learning curve I figured I would just wrap the client and hide all the WCF implementation. I found that inorder to get this to work they still have to include in their app.config file the service model with endpoint information.
Is there a way to completely hide the service model information? I would prefer them to simply reference my dll and start making calls. It seems unnecessary for libraries beyond my client to have to know about endpoint information.
Thanks
You can create the endpoint programmatically rather than through configuration, as in the example shown in the answer to this SO question: How do I add WCF client endpoints programmatically?
If you don't want to have wcf client settings inside your web config you will need to create settings using code. Here is sample code how to create instance to wcf client (in this case using BasicHttpBinding) without web.config:
BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress("http://someServer/DemoWcfService");
TestServiceClient client = new TestServiceClient(binding, address)
But I would suggest you to stay with web.config wcf client configuration because it's easy to reconfigure.
I have a single WCF service but, until runtime, I don't know the correct address of the service. It may be :
http://example1.com/MyService.svc
// or
http://example2.com/MyService.svc
The service is used by a class library (DAL). I have two options:
Add a service reference to the
service (Visula Studio 2010) and
change the address at run-time. This
way VS-2010 will create WSDL and
other stuff for me (I'm not sure if this is even possible).
Create the proxy on the fly and set
the base service address. This needs
more work and if I make any change
to service, I need to generate WSDL
myself. Maintenance of this code is
not as easy as option one.
Which option to use? Also if option two is recommended by you, then should I my client wrapper class be singleton or I can create all the connection stuff on each call?
you can point to localhost or any other address in development then in production if the url changes you simply modify the web.config or the app.config where you have configured the WCF end point.
Option 1 - you get all the advantages and none of the pain. Just use something factory-oriented (i.e. Don't do new MyProxy(), but instead stick that code somewhere central like a static CreateMyProxy() method, or consider an IoC/DI container).
How to consume WCF web service through URL at run time?
I have a WCF service I use for configuration stuff hosted in a windows service that will be used to maintain a database. Is there any way that I can access the WCF service inside of the hosting service? Or should I move the database functionality to another WCF service and host them both inside of a windows service?
The service class (the one implementing your service interface) has a property
OperationContext.Current.Host
which gives you access to the ServiceHost instance which is hosting your service. You can access that service host pretty easily.
There's no built-in way to reach beyond the service host and manipulate or query the NT service containing the service host. But you could always create your own custom ServiceHost descendant class which would give you the necessary access to the NT service itself, and then use that custom service host for your service implementation.
With a custom service host, you can basically do whatever you feel is necessary and useful - just create a descendant from ServiceHost and do whatever you need to do!
If by "access" you mean to ask whether you can call the service, then yes, the service can be a client of itself.
What might be better would be for you to separate the service into those parts that are specific to the fact that it's a web service, and all the other parts that do the real work. Have the Windows Service call the latter parts.
The way I do this is to pass a shared object into the constructor of the WCF Service by using a custom InstanceProvider (this allows you to use non-default constructors for the WCF Service).
The shared object then allows the WCF Service to "talk" with the Windows Service (or any other object that can get access the shared object).
As I'm currently learning to use WCF Services, I am constantly encountering tutorials on the internet which mention using a ServiceHost when using a WCF Service.
What exactly is this ServiceHost ?
In my current project I am using a WCF Service and having a reference to it from my app and whenever I want to consume it from my app I just instantiate its ServiceClient like such:
new MusicRepo_DBAccess_ServiceClient(new InstanceContext(instanceContext), customBinding, endpointAddress);
And then access my web methods (OperationContracts) from that instance (obviously opening it before consuming the method and closing it afterwards with Open and Close)
My WCF service is host in my IIS and I just access the .svc from my app to instantiate the ServiceClient.
So why and where is ServiceHost used?
A ServiceHost basically provides you everything you need to host a WCF service in a non-IIS or WAS setting. A common place for a ServiceHost would be in a console app or Windows service. See the example code from MSDN for how to setup a ServiceHost in a console app.
Your service implementation is just a .NET class - you need to have a runtime environment for it, so it can be executed somehow. That's what the ServiceHost is for - it will load your service class, set up the endpoints and channel listeners and all that stuff, and thus give your service class an "ecosystem" to live and operate in.
You can either instantiate a ServiceHost class yourself in a console app, a Windows service, or even a Winforms app, and thus make your WCF service class available to the outside world - or you can delegate that work to IIS or WAS. Even IIS or WAS will use a ServiceHost to host your WCF service - they just do it automagically behind the scenes, and "on demand" - whenever a request for your WCF service comes in.
Marc