I am trying to come up with a way to accomplish something but haven't been able to find what I am looking for yet.
4 Developers
1 Development webserver
1 Development WCF server
We each have our own website for testing/debugging on the one server using IIS6. We each have our own port number that distinguishes what site we are connecting to.
When our websites make a request for the WCF server the hosts file on our dev webserver points it at our dev WCF server. Likewise, the production webserver's hosts file points it at our production WCF server. This way we never have to worry about changing the Address of our service references in Visual Studio.
Recently we have a need for multiple developers to be working on multiple branches of the WCF code at the same time. Currently we have to take turns using the WCF server.
We want the ability to have our individual websites on the dev webserver point at individual WCF websites on our dev WCF server.
I have tried several ways I thought of but they all require us to update the Address in the service reference in Visual Studio. (currently if we update/add a service call we point our local machine's host file at the dev site after the new WCF code has been deployed to it.)
Does anyone have any idea, or a direction of where I can find common configurations for this type of thing? I have to assume that Microsoft has a best practices setup for multiple developers with multiple dev environments for websites and WCF sites.
Requirements of the setup:
We only get a single webserver for website testing.
We only get a single webserver for WCF testing.
We need a solution that doesn't require us to update the Address in the service reference in Visual Studio when developing on the WCF code.
If worse comes to worse we may have to think about changing the requirements.
Thank you in advance!
You can simply change the address of the service in configuration file for each deployment. You don't need to change the address of service reference until the service has changed in the way that would produce different client proxy code.
Related
I am setting up our server to handle all our WCF web services. What I want to know is, what is the best practice for proper isolation of each service under one root domain?
I'm using something like http://api.ourdomain.com and I want each of our client's WCF services to be isolated in separate virtual directories like http://api.ourdomain.com/client1.
I'd like it so that if any one fails/bombs they won't affect other live WCF services running.
Normally I isolate them by website, but since these are all under one 'roof' so to speak, Ihave to do some IIS trickery to properly isolate them.
I had setup a virtual directory and had it as it's own 'app' but I was getting the following error:
"It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process."
Which is strange since I had them both set to use .NET 4.0 framework, so, I'm not sure what happened.
i am new in wcf and started learning. i got one confusion like that i create a small wcf service and just do not host it in IIS,console apps or win service but from another apps i can add the service reference of svc file and found it is working. if wcf can work without hosting in any place like "IIS,console apps or win service " then why people would alway host wcf service in IIS,console apps or win service. can anyone tell me the reason.
people use IIS and windows services in general because they are simpler to setup and run more consistently. they can also be hosted more easily on servers where the services can be configured to start automatically, and as usually wcf is used as a server communication method it is usually this that you want to do.
hosting in console applications is generally easier to setup for simple examples for testing purposes, when you want to test your services locally.
Whilst hosting in applications as possible it's a less common scenario to use wcf to communicate between 2 applications on the same machine.
EDIT:
Your original question asked why people always talk about IIS, services etc. The point I was making was that usually wcf is used for web services, and is usually run on a server other than the local machine. Even though it can be used for inter process communication on the same machine this is not the most common use case. This is why you see a lot of examples using IIS and not too many hosting it in a Windows forms app.
My head hurts so much I think I need a bottle of aspirin...
I've created a WCF service and, with help of others from this site and the department I work in, the WCF service is running as a service on my development machine. Tested it with a console app and it works.
But, it's not supposed to be on my development machine. It needs to be on a different server.
This is difficult because the server it is supposed to reside on DOES NOT have Visual Studio installed on it.
So I cannot run the VS 2008 Command Prompt with installutil to run the WCF service as a service on that server.
Broadly speaking, you've got three options, all of which are described on MSDN:
Host the service under IIS
Self-host the service in any managed .NET application
Host the WCF service under a Windows Service
Which one is right for you depends on what your service is for, how it'll be consumed, how scalable and secure you need the set-up to be, and a dozen other things besides. Without knowing a bit more about what your service does and how it'll be used in your organisation, it's difficult to make a recommendation.
IIS hosting is easy to set up and is the way to go if you want to leverage all of the industrial-strength hosting functionality that a full-blown web server offers.
Self-hosting is quick and easy - you can knock out a WCF-hosting console app in two minutes flat - but is the clunky solution. You of course have to run the host application as a particular Windows user. Perhaps not ideal?
Hosting under a Windows service is the middle ground. It gives you that always-available functionality without having to be logged in as a specific user, but doesn't offer the configurability and scalability of the IIS solution. It takes a bit more effort than belting out a quick console app, but not much.
The server that the windows service will reside on will have the .NET Framework. INSTALLUTIL is located in the Microsoft.NET\Framework(version number) folder in the Windows directory.
For example, C:\Windows\Microsoft.NET\Framework\v2.0.50727.
No need to write a console app to host your service now (unless you want to).
You can also host your WCF service under IIS, check this out: MSDN - How to: Host a WCF Service in IIS. It really is just a five minute job :)
I have a web site and build a wcf service in it. I can run the code by calling it from a test page in the web site. The web site is ran by the vs2010 development server.
I do have IIS 7 but never use it.
Now I want to use the NetTcpBinding instead of BasicHttpBinding, everyone says it should be enabled in IIS, but how can this be done without using IIS and keeping everything in 1 project?
Thanks for any help
edit: A Windows service would be a solution, but that would mean adding a project to the solution, I really want to keep everything in 1 website, took me quite some time to get the service in the website in the first place.
This is about my own test version of the website, the production server is out of my reach. The service must be expanded by other developers later on it's bad if they have to run IIS just to test the service.
One way is to host the WCF service in a Windows Service - see How to: Host WCF in a Windows Service Using TCP for sample code.
Are you talking about how to develop without using IIS7 or how to put the service into a production environment without IIS7?
If it's the latter, then Stuart's answer is correct, but otherwise I would suggest that you start to develop using the web server that you will eventually be hosting the web site/service on.
Hosting in IIS7 has several advantages over hosting in a Windows Service such as fault tolerance and process isolation already built in.
Thanks for the replies guys, it looks like I have 3 options:
1. Host the service in a seperate project.
2. Host the website in IIS.
3. Use HTTPS, also secure.
PS: My development environment is very different from production :(
In development I have unit testing and in production there are old ASP pages, that I can't even acces, but sometimes must refer to...
So, I previously posted about my troubles in moving a working WCF service from my local machine to the development server. The problem was that when moving it over all of the references were by machine name rather than ip. Since i was not accessing it on the domain, I couldn't see the machine name and couldn't access the references. Here was my previous post (.NET WCF service references use server name rather than IP address causing issues when consuming).
I found a solution, but wanted to make sure that this is the proper solution to my issue. And also ask if anyone else had any other input? The solution was to change the IIS site binding. I found the solution at (http://blogs.msdn.com/wenlong/archive/2007/08/02/how-to-change-hostname-in-wsdl-of-an-iis-hosted-service.aspx). The only thing is that I may have to do this for every site as the application that i work with is not hosted and is a web-based solution installed at each site. So i'm possibly going to have to include a script in the build for each site.
I would think that I would be able to make this change in the .config file?
The right way to handle this is to set and explicit host-header in IIS for the Web Site instance. Now, assuming you've only got one host-header applied to the Web Site instance that should be all that you need. However, if you have multiple host-headers configured you will also need to explicitly tell WCF which host to expose itself via. This is done with the configuration element under the element to bind the service to that specific domain.