I have a set of WCF Services Hosted in IIS7. I'm in the process of moving the services to a different folder in order to start specifying version and environment in the URL. For example:
http://myserver/MyServices/ServiceA.svc
Becomes:
http://myserver/MyServices/QA/1.1.0/ServiceA.svc
I configured the new folder to be an application in IIS, and set it up to run under the same service app pool we've been using. That has all worked fine, I am able to navigate to my .svc URL and view the WSDL or open up the endpoint in wcf test client. However, when trying to consume the service I am getting the following error:
The identity check failed for the outgoing message. The expected identity is 'identity(http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn)' for the 'http://myserver/MyServices/QA/1.1.0/ServiceA.svc' target endpoint.
When I check the WSDL output, I noticed that the identity section seemed to leave out the identity of the app pool, which it usually includes:
<Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<Upn>myappuser#mydomain.local</Upn>
</Identity>
After trying to redeploy and reconfigure the app in IIS, I was able to get the identity to appear in the metadata for only some of the services. Other services still don't include it, which is even more strange than before. There are zero configuration differences between the original stack and the new stack in IIS as far as I can tell. What sorts of issues could I be running in to that would causes these types of identity issues?
The issue was caused by trying to nest the new service stack web application inside of the existing service stack web application. I think that may have caused some confusion for IIS when services in the sub-application were exposing endpoints to the same contracts that the root web application (although in theory this should work just fine). I simply had to move the new service stack into a separate folder structure. Once I did that, I had no problems getting the app pool identity to be exposed in the metadata.
Related
In my VS solution, I created a console project, which I'm using as the client, and an empty project for the WCF service.
I then created the WCF service (created my contract and service type and manually constructed the app.config), and added a reference to the WCF service project in the client project.
However, when I called ServiceHost.Open() in the client, the endpoints weren't loading. I eventually determined that I needed to put all of the config information in the Client's app.config, rather than the service's app.config.
I'm not sure if this is normal, or if I'm doing something wrong. In the past, when I've used the WCF project template, this wasn't the case.
Yes, that is normal. Each .NET application (client, service, web site, etc.) has it's own configuration file. To be precise, there's a hierarchy of them, but the bottom end of that hierarchy is unique to the application.
This makes sense if you think about it -- the client would need to contact the service to ask for it's configuration, but it needs to know the endpoint information in order to even try to do that. So yes, the normal process is that client and service both have very similar information in their configuration files.
If you use Visual Studio's built-in tooling to do everything for you, it will automatically create and/or edit the configuration file for your client when you add a Service Reference to the project, copying from the metadata endpoint that WCF exposes for that purpose. Alternatively, you can use the WCF configuration editor tools to edit your client application.
Also, note that nothing actually enforces that your client and server have compatible settings; e.g. you can change the maximum sizes of many buffers/graphs/etc on one side, and not the other, and see some strange behavior. It's up to you to make sure both ends are working with mutually usable settings.
I have renamed a WCF service and everything works just fine on my test/development environment. However, the service is not accessible on my production environment, which is IIS. When trying to access the service the client receives roughly the following error:
The request failed with the error: The type Old_Service_Name.Some_Type could not be found.
In other words, IIS should be informed about the renaming of the service. How do I tell IIS, preferably using IIS Manager, that the service has a new name?
In the service.svc file, change the Service attribute of the ServiceHost tag so that it suits your new service name. Namely, replace Old_Service_Name.Some_Type with New_Service_Name.Some_Type.
I've been working on a WCF service that is currently hosted on IIS. I need to get the WCF service to access a directory outside of the wwwroot folder.
Am I right in assuming that directory access outside of wwwroot is restricted to WCF apps hosted on IIS as it would be restricted for an ASP.Net application hosted on IIS?
If this is the case, what is the safest way of allowing the WCF service to acccess a set folder outside of the wwwroot?
BTW - I'm running in Mixed Transports Mode, not ASP.Net compatibility mode.
File access is going to be limited based on the identify of the application pool that is hosting your service. Your service will be able to access any file the application pool identity has access to whether it is in the root of your IIS website or not. If you want to access files within the root of your website using relative paths with something like Server.MapPath then you'll have to run your WCF service in ASP.Net compatability mode. See the following page for details on WCF with ASP.Net compatability mode:
http://msdn.microsoft.com/en-us/library/aa702682.aspx
I think that the best approach is to create another application pool for your service and assign a specially created account as the identity of your new application pool. Then give the needed permissions of the account to the folders and file you need to access. You can make the external folder a virtual directory of the site if you want to reference it with a relative path.
I have found some basic information about hosting a WCF service in a Windows service, but not much. All of my experience thus far with WCF has been in Web projects. I have a few simple questions.
I have a project which creates a windows service application. I have done a right click -> add WCF Service. This creates Service1.cs and IService1.cs.
I'm wondering why no SVC file is created in this scenario? When I add services to Web projects i get an SVC file which I can navigate to and use to consume the service.
Adding the service adds some configurations to the app.config under the services element. I'm seeing a default base address of
http://localhost:8732/Design_Time_Addresses/WindowsServiceName.services/WCFServiceName/
What does this mean? It's sort of an odd looking address. Am I supposed to change it to whatever I want?
Navigating to this address in a browser results in an unable to connect message. Does the windows service itself have to be running to talk to the WCF service?
How do I go about consuming this service from another application without an svc file?
I'm taking a guess on this first one, but I'm thinking the .svc file when hosting in IIS is to tell IIS, "Hey I have a WCF service here, please handle accordingly".
The base address is as it should be and yes you can change it if I'm not mistaken.
You can't hit the WCF service unless the Windows service is running, which is one of the dangers of hosting in a Windows service, because if the service dies somehow your WCF service is offline until you get the Windows service running again.
You consume the service the same way you do any other WCF service, just using that base address to get at it.
I've got an MVC web application that is used as an interface to a Console based app that exposes a bunch of ServiceHost/s using the net.pipe protocol.
I would like to use the asp.net membership/role/profile provider to manage my users and their roles and profile information (Inside the Console Application). I've done this in quite a few apps, but normally I reference these providers directly from the web application itself.
This is a good walk-through on doing pretty much what I would like, except I don't want to host the WCF service endpoints in IIS, but inside my console app - which will eventually become a windows service. When I try and host the ServiceHost through my console application I get the following error:
This service requires ASP.NET compatibility and must be hosted in IIS.
Either host the service in IIS with ASP.NET compatibility turned on in
web.config or set the
AspNetCompatibilityRequirementsAttribute.AspNetCompatibilityRequirementsMode
property to a value other than Required.
Now it seems that I won't be able to set that property to anything other than Required.
I've tried another route which is using the wrapper class/interface defined here for my authentication service, which I managed to get wired into in my MVC app without too much trouble, but this doesn't cover my Authorisation (using roles) or profile needs.
Has anyone got a solution to this, I can't be the only one trying to do this? I'm not