I have a WCF service composed by two projects:
WCF service library
WCF Web application
The First project has a service call IMyService implemented by MyService. It is configured by using WS binding and if I press F5 on this project the WCFTestClient render the WS binding.
In the web app I have an .svc file with this markup with the same name
<%# ServiceHost Language="C#" Debug="true" Service="[Namespace].MyService" %>
If I press F5 on this project it renders a BasicHttpBinding. Same in the Client.
Why?
I have just checked that WCF Service Library project by default creates app.config with WSHttpBinding used for default service. When you run WCFTestClient it always uses this local config. If you want to use WCFTestClient to test additional services you must add their configuration to this config. This config is never used for anything else.
WCF Service application uses web.config. In WCF 4.0 it uses simplified configuration which adds endpoints based on some predefined conditions. By default it adds BasicHttpBinding endpoint to all services exposed over HTTP with common ServiceHostFactory.
How is your config file configure? If you configure the endpoint to use the wshttpbinding, this is the one that should be used.
Would you mind adding some code here (including the binding and endpoint details from the config file), so we could take a look?
Thanks,
Roberto Lopes.
I believe the original question was very poorly posed, to get a satisfactory answer you need to clearly state all the details.
First which version of Visual Studio are yo using? Since nothing is said, I'll assume it's the latest version VS2010 with SP1.
Let's say you have a visual studio solution that has two projects, one is a WCF Service Library, another is a WCF Application, both created using the default project template without any manual tweaking.
The WCF Service Library will have a app.config file with the following line:
in short, Visual Studio 2010 (SP1) uses wsHttpBinding for WCF Service Library projects by default.
The WCF Service Application project, however, will have a web.config file that contains no explicit endpoint definition, in which case, the default endpoint binding used is basicHttpBinding.
The OP said "When I pressed F5 on this project ....", this is a very misleading statement.
What does it mean to "press F5 on a project"? Do you mean you selected the project node in the solution tree, then pressed F5? if that's the case, what happens will always depend on which project is set as the start-up project in the solution (not on which project node is currently selected in Visual Studio UI).
If the WCF Service Application project is the start-up project, pressing F5 will NOT cause the WCF test client to run, instead, it will cause the folder of the project to be displayed in IE.
If the WCF Service Library project is the start-up project, the WCF test client will be run, and this is only because in the debug section of the project's properties window, the start options has the following by default:
/client:"WcfTestClient.exe"
Related
I have a silverlight business application which access to a web service. I've created WCF service (in RIA part) which access this web service, and then added Web service reference in SL project. Using this way (proxy), I got service address like this: localhost:7777/... When I deployed application to IIS, this port number was not the same (expected, but...).
Since I couldn't configure this port number, I made separate service (not in the same solution) and deployed to IIS. After that, I added service reference to SL project. Similar like before, but now service is not in the same solution, but independently deployed on IIS. This approach doesn't work. In Fiddler all I could see is HTTP 500.
Could someone please tell me how to deploy SL Business Application which has an access to a WCF service which is deployed separately?
Best,
Joksimovic
What you'll want to do is create separate versions of your ServiceReferences.ClientConfig file (which resides in your Silverlight application and contains the service endpoints for the application).
We create a separate ServiceReferences.ClientConfig for each possible deployment location and then base them on the Silverlight project's build configuration. So, when the project is built and it's build configuration is set to "Debug", we have a ServiceReferences.Debug.ClientConfig whose contents are copied into the project's local ServiceReferences.ClientConfig. Ditto for our Test, UAT, and Release builds.
Here is a link which talks about choosing the correct config based on your build configuration: How to use Visual Studio 2010 config transform when running/debugging locally?
I've got a WCF service using the netTcpBinding, and no other binding. It works great when I manually deploy the files to IIS, and my client application can consume the service when I enter the net.tcp://localhost(etc) url. Now I'm trying to get the project to run in Visual Studio, so I can have the service and client in the same solution, and reference the service directly instead of going through IIS, and having to redeploy files manually.
Neither IIS Express nor the Visual Studio Development Server can use net.tcp, so they're out. In the Web tab of my service project, the "Use Local IIS Web Server" or "Use Custom Web Server" looked like good options, but neither of them will accept a URL that doesn't begin with http.
Is there some way of making my WCF service use IIS, and having my client reference the service directly (so that I don't have to deploy files to IIS, and then update service reference, every time I compile)?
Start the service in WcfSvcHost, then try to add a reference to the hosted URL.
Unfortunately, the VS IDE has no technique to start services automatically, except for when you're debugging.
Also, you always need to update service references explicitly. You need to decide which of your changes are ready to be applied to which clients of your service. It would be bad to assume that all clients should be updated as soon as you make a change then compile your service.
You could add a project, which you don't deploy, but only use during development, that self-hosts the service.
I've been working with about a dozen WCF Services that have been deployed to various machines with IIS. All binding/configurations have been kept in the usual "web.config" file that was created to keep the services more configurable and keep the service code itself more clean. However, I've just recently been tasked with creating a Windows Service to host these WCF Services. One question that I have is, do I just copy all the settings from the web.config file to the App.config file for the windows service? Or do I need to reconfigure all the endpoints/bindings/etc. using a different format in the App.config file? I've never created a windows service before and not 100% sure what I need for setup once I've created the Windows Service Host. Thanks in advance.
The WCF configuration elements in web.config should translate directly to app.config. I've cut and pasted web.config elements like this in the past. The only thing to watch out for is that neither web.config nor app.config like certain elements repeating, so if you're merging configuration data from multiple web.config files, you'll have to ensure that you don't repeat sections that should only exist once.
I always thought the .NET config model didn't fit well with WCF service configuration.
There's a way to teach WCF to retrieve its configuration from an alternative location. I like to set it so that the WCF service retrieves its configuration information from ServiceName.config rather than web.config or AppName.exe.config. This solves the problem of repeating elements mentioned by Harper Shelby.
Here's a full explanation and some code.
Using that custom service host, moving a WCF service from IIS to a self-hosted model is really simple.
See also, WCF Configuration - Split it out of app.config
I have a solution in VS2010 with 3 projects:
WCFServiceLib - a project created with the WCF Service Library template.
ServiceHostConsole - a project created with Console Application template.
ServiceClientConsole - a project created with Console Application template.
The VS template created an app.config in the WCFServiceLib that contains all the settings for the services I want to expose.
The ServiceHostConsole has WCFServiceLib as a reference and hosts the service but does not have it's own app.config file.
If I try to run the host project without an app.config, it fails to host the services, so I moved the app.config from the WCFServiceLib to the ServiceHostConsole.
The ServiceClientConsole has a Service reference to a service inside WCFServiceLib. But once I move the app.config from the Lib project to the Host project, I can no longer Update Service Reference or add new services that I added to the lib project.
In order for the client project to see the service references I have to move the app.config back to the lib project, do the updates/additions to the service references on the client, and then move the app.config back to the host project.
Note that I cannot leave a duplicate app.config file in both the Service Lib project and Host project as this will cause the host to also fail to start. This would be a bad solution anyway as it would create duplicate config in different places. A change to just one of them could create issues that are difficult to track.
It seems very strange that this moving around of the app.config file needs to happen to make things work for both the host and the client, and that they can't both work at the same time.
I'm sure this must be an issue with the way I set things up (although I set them up with the default templates), and I guess there must be a better way to solve this.
This problem becomes very annoying when you are actively developing the services and need to constantly run the host and test the client with the updated services, hence the title of the question:
How do you maintain a WCF Service Library in VS2010 for both a Host and Client projects?
WCF service library creates a config because it is used by a tool called WcfServiceHost.exe. This tool hosts your service if you try to test it without your own hosting application and based on your description it also hosted the service when you added a service reference in the client (because of that you cannot update the reference when you move the config from the library). The config in the library is never used by a hosting application and it doesn't collide with a config used by the hosting application.
A hosting application always needs its own config and there should be no problem to have a config in both the host and the library. You should not create a service reference from the library itself. Once you have your own host use it when you add service reference and maintain only the config in the host.
There is one little problem. To add service reference the service must run. If both the client and the host are part of the same solution you must run the service without debugging (or outside of visual studio) to be able to add service reference to the client.
I have created a WCF service library (not a WCF service application).
The project output is a dll.
How can I host this on IIS 7.5/WAS?
I believed that creating a service library was the way to go so that it could be used on a variety of hosts, whereas the service application is limited to IIS.
I'm getting lost in MS mumbo jumbo here, so I'd appreciate any help on getting this service deployed.
Thanks!
Edit
I got the service hosted by following these instructions:
http://msdn.microsoft.com/en-us/library/ms733109.aspx.
It seems like there has to be a better way to host service libraries. Deployment shouldn't require taking settings from app.config and moving them into web.config. Is it standard to wrap them in service applications? Is that even possible?
How are other people handling this?
Yes, creating separate library is good practice because hosting code is not coupled with your services. But you still have to write a host. In WAS, host is in a Web application. To host service in WAS you have to create .svc file and configuration for each service. That is the reason why you have to copy configuration from app.config to web.config. In .NET 4.0 this can be simplyfied with configuration based activation (no .svc is needed) end default endpoints.