I recently built a WCF Service, and now I'm deploying it to Windows Server 2008. Right now, we don't have secure protocol turned on. But we will. I'd like to get it working either way. In the site, I've had Anonymous authentication enabled as well as Forms authentication. The reason I did this was to prevent the authentication popup on the iPad, Android and Internet Explorer. So now they just get to the Login screen. Oh and I did activate WCF in Windows features. If you're also knowledgeable about making this https ready, I'd also like to figure that out. Thanks!!
I'm getting this error when I try pasting in the *.svc PATH into the URL.
System.ServiceModel.ServiceActivationException:
The service
'/WCFServices/Accessioning/QuickDataEntryService.svc'
cannot be activated due to an
exception during compilation
Here is my web.config configuration thus far.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
<!--<baseAddressPrefixFilters>
<add prefix="http://localhost/" />
</baseAddressPrefixFilters>-->
</serviceHostingEnvironment>
<behaviors>
<endpointBehaviors>
<behavior name="AspNetAjaxBehavior">
<enableWebScript />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpGetEnabled="true" />
</behavior>
<!-- Watch this section when adding a new WCF Service! New behaviors will be added; just delete them and use "ServiceBehavior" -->
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="ServiceBehavior" name="A.LIMS.UI.Web.WCFServices.Accessioning.QuickDataEntryService">
<endpoint behaviorConfiguration="AspNetAjaxBehavior" binding="webHttpBinding"
contract="A.LIMS.UI.Web.WCFServices.Accessioning.QuickDataEntryService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
<!--<service name="A.LIMS.UI.Web.WCFServices.Accessioning.IQuickDataEntryService"
behaviorConfiguration="ServiceBehavior">
<endpoint behaviorConfiguration="AspNetAjaxBehavior"
binding="webHttpBinding"
contract="A.LIMS.UI.Web.WCFServices.Accessioning.IQuickDataEntryService" />
</service>-->
<!-- Watch this section when adding a new WCF Service! Duplicate the "QuickDataEntryService" above for an example, but change the fully qualified name -->
</services>
</system.serviceModel>
I have no clue what caused the exception above, but here was the final verdict. There were a lot of things required for WCF and using an SSL certificate (HTTPS protocol). Pardon the formatting.. I don't like how Stack Overflow sometimes puts the code into a block and sometimes it doesn't.
The following were required for the web.config on HTTPS:
Here are some places that required the "requireSSL" attribute:
<authentication mode="Forms">
<forms loginUrl="Login.aspx" timeout="30" protection="All" requireSSL="true" />
</authentication>
<httpCookies httpOnlyCookies="false" requireSSL="true" domain="" />
Notice the "s" in "httsGetEnabled" below:
<behaviors>
<endpointBehaviors>
<behavior name="AspNetAjaxBehavior">
<enableWebScript />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpsGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
Bindings (missing in non-SSL web.config):
<bindings>
<webHttpBinding>
<binding name="webBinding">
<security mode="Transport">
</security>
</binding>
</webHttpBinding>
</bindings>
Services (notice the "s" in "mexHttpsBinding"):
<services>
<service behaviorConfiguration="ServiceBehavior" name="A.LIMS.UI.Web.WCFServices.Accessioning.QuickDataEntryService">
<endpoint behaviorConfiguration="AspNetAjaxBehavior" binding="webHttpBinding" bindingConfiguration="webBinding" contract="A.LIMS.UI.Web.WCFServices.Accessioning.QuickDataEntryService" />
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
</service>
</services>
Last but not least. I'm not using .NET 4.0, but I did try .NET on a different machine. With .NET 4.0 I couldn't get the WCF services to work without having this configured to the actual URL being used. If there were two domains for the same IP, WCF only worked with the domain in this block inside the system.ServiceModel XML block in the web.config. I did not test https in the .NET 4.0, so I'm assuming the protocol on the URL would be https below:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
<baseAddressPrefixFilters>
<add prefix="http://subdomain.domain.com/" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
Oh, I also had to turn on WCF on the Windows Server 2008 box. And it required a server reboot!
Related
I have a running, mature WCF service that I am trying to deploy on Windows Azure as a Web Role (with a custom wrapper, of course). My RoleEntryPoint.OnStart() method creates a ServiceHost instance, where it trips with the zero application endpoints error. The configuration (web.config) service model section is:
<system.serviceModel>
<services>
<service name="Linguasys.QualitativeAnalysis.Processing" behaviorConfiguration="defaultServiceBehavior">
<endpoint address="" behaviorConfiguration="wcfAzureWrapperStoryMapping.StoryMapperAspNetAjaxBehavior" binding="webHttpBinding" contract="Linguasys.QualitativeAnalysis.IProcessing" />
<!--
<endpoint address="soap" behaviorConfiguration="" binding="basicHttpBinding" contract="Linguasys.QualitativeAnalysis.IProcessing" />
-->
</service>
</services>
<behaviors>
<endpointBehaviors>
<behavior name="wcfAzureWrapperStoryMapping.StoryMapperAspNetAjaxBehavior">
<!--
<enableWebScript />
-->
<webHttp faultExceptionEnabled="true" />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="defaultServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<webHttpBinding></webHttpBinding>
<basicHttpBinding></basicHttpBinding>
</bindings>
<protocolMapping>
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<!--
<serviceActivations>
<add relativeAddress="StoryMapper.svc" service="Linguasys.QualitativeAnalysis.Processing"/>
</serviceActivations>
-->
</serviceHostingEnvironment>
</system.serviceModel>
Never mind the activation bits, the basic HTTP binding, etc. They were added later to see whether it will work.
I see that my web.config ends up at the siteroot and approot and all the other places.
What am I missing?
Your RoleEntryPoint.OnStart() method runs in WaIISHost.exe which does not know anything about your web.config. For more info see http://azure.microsoft.com/blog/2010/12/02/new-full-iis-capabilities-differences-from-hosted-web-core/, and for information about how the processes run see http://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx.
Two options:
Move your WCF configuration to WebRole1.dll.config (or whatever your role entry point binary's name is). Make sure you set the .config to Content and copy local.
Instantiate your ServiceHost in w3wp (ie. Global.asax).
Guys I've been looking at a ton of blogs, SO posts this week and I am still unsure as to how I convert my WCF service from HTTP bindings to using Named Pipes.
I think there are different ways to do it, but I am using the web.configs and using a service reference in my code.
Rather than detail everything here I've tried, can I ask this question?
What are the steps I need to take to go from HTTP Binding to Named Pipes?
Do I need this MEX thing I see mentioned in (some) blogs/SO posts?
I know I need to set IIS to enabled protocols: net.pipe... and that IIS Express doesn't support this (that took an afternoon!)
Some relevant code, what I have right now:
in IEmployeeData:
namespace Mobile.ServiceLayer {
[ServiceContract]
public interface IEmployeeData
{ ... }
Calling the WCF service:
string endpointConfigName = "BasicHttpBinding_IEmployeeData";
EmployeeSvcRef.EmployeeDataClient edc = new EmployeeSvcRef.EmployeeDataClient(endpointConfigName);
EmployeeSvcRef.EmployeeListResponse emp = edc.EmployeeList();
WCF service web.config:
<services>
<service name="Mobile.ServiceLayer.EmployeeData">
<host>
<baseAddresses>
<add baseAddress="http://localhost:62734/EmployeeData" />
</baseAddresses>
</host>
</service>
...
<behaviors>
<serviceBehaviors>
<behavior>
<!-- To avoid disclosing metadata information, set the value below to false before deployment -->
<serviceMetadata httpGetEnabled="true" />
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
client web.config:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IEmployeeData" />
...
<client>
<endpoint address="http://localhost:62734/EmployeeData.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IEmployeeData" contract="EmployeeSvcRef.IEmployeeData"
name="BasicHttpBinding_IEmployeeData" />
Like I said I've looked at SO posts and blogs but there's always a piece of the puzzle missing it seems!
EDIT: Client web.config after wizard:
<endpoint address="net.pipe://localhost/EmployeeData.svc/" binding="netNamedPipeBinding"
bindingConfiguration="NewBinding0" contract="IEmployeeData"
name="" kind="" endpointConfiguration="">
<identity>
<certificateReference storeName="My" storeLocation="LocalMachine"
x509FindType="FindBySubjectDistinguishedName" />
</identity>
</endpoint>
Ok this is what I did. You may find it easier to use the built-in tools mentioned in Max's comments. Right click on a web.config and choose Edit WCF Configuration. Get the WCF service done first and, providing the endpoints are set up, running this on the client (right click it's web.config) will present you with a wizard.
SERVER WEB.CONFIG
Service name is the fully-qualified name of the interface e.g. Mobile.ServiceLayer.IEmployeeData
The base address changes to
net.pipe://localhost/EmployeeData.svc
. Notice the port number is removed and the .svc is present(!)
Create an endpoint, the contract being your interface and binding of type netNamedPipeBinding.
Add a second endpoint for MEX which is MetadataEXchange.
Set ServiceMetaData httpGetEnabled to false.
<system.serviceModel>
<services>
<service name="Mobile.ServiceLayer.IEmployeeData">
<host>
<baseAddresses>
<add baseAddress="net.pipe://localhost/EmployeeData.svc" />
</baseAddresses>
</host>
<!-- NetPipe -->
<endpoint
address=""
binding="netNamedPipeBinding"
contract="IEmployeeData" name="MyNetPipe" />
<!-- Mex (Net.Tcp / Net.Pipe ) -->
<endpoint name="EmployeeDataNetPipeMex" address="mex" binding="mexNamedPipeBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
CLIENT WEB.CONFIG
Remove the binding entry from 'basicHttpBinding'
Add the section with an entry named NetNamedPipeBinding_IEmployeeData
Inside 'client' add an endpoint with the address
net.pipe://localhost/EmployeeData.svc
the contract being the 'referencename'.'interface'
<bindings>
<basicHttpBinding>
</basicHttpBinding>
<netNamedPipeBinding>
<binding name="NetNamedPipeBinding_IEmployeeData" />
</netNamedPipeBinding>
</bindings>
<client>
<endpoint address="net.pipe://localhost/EmployeeData.svc" binding="netNamedPipeBinding"
bindingConfiguration="NetNamedPipeBinding_IEmployeeData" contract="EmployeeSvcRef.IEmployeeData"
name="NetNamedPipeBinding_IEmployeeData" />
</client>
BACKGROUND
We have a WCF web service hosted in a Windows Service running with the basicHttpBinding.
PROBLEM
Browsing to the service URL on the local machine works fine, but trying to browse using the external IP address (either remotely or EVEN locally) does not work. Example:
http://localhost:8000/booking.svc (OK)
http://<external-IP>:8000/booking.svc (Not OK)
APP.CONFIG
<system.serviceModel>
<services>
<service behaviorConfiguration="DefaultServiceBehavior" name="HotelManagementSystem.ServiceHost.BookingService">
<endpoint address="" binding="basicHttpBinding" contract="HotelManagementSystem.ServiceHost.IBookingService" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/booking.svc" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="DefaultServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Anyone have any ideas?
Try using useRequestHeadersForMetadataAddress
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<useRequestHeadersForMetadataAddress />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
This will allow the service to insert the URI you used to access the service in to the metadata so the wsdl aligns. Sometimes you'll go to access http://1.2.3.4/service.svc but the metadata will reference http://localhost. Locally that's fine, but remotely that makes grabbing the endpoint information impossible. Instead, now all those localhost references will use 1.2.3.4 instead.
I am trying to configure IIS to host one set of binaries in two IIS websites. So we want to be able to access the urls:
http://external.example.com/ADataService
https://external.example.com/ADataService
http://internal.example.com/ADataService
internal.example.com and external.example.com are set up as different IIS sites to allow us to assign them different application pools. However when I added HTTPS support to our web.config, the internal HTTP support stopped working; http://internal.example.com/ADataService now returns the error:
Could not find a base address that matches scheme https for the endpoint with binding CustomBinding. Registered base address schemes are [http].
Here are the details of our web.config
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<bindings>
<customBinding>
<binding name="jsonCustomMapper">
<webMessageEncoding webContentTypeMapperType="Service.JSONCustomMapper, Service" />
<httpTransport manualAddressing="true" />
</binding>
<binding name="httpsjsonCustomMapper">
<webMessageEncoding webContentTypeMapperType="Service.JSONCustomMapper, Service" />
<httpsTransport manualAddressing="true" />
</binding>
</customBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name="jsonBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="defaultBehavior">
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="Service.Service" behaviorConfiguration="defaultBehavior">
<endpoint address="json" binding="customBinding" bindingConfiguration="jsonCustomMapper" behaviorConfiguration="jsonBehavior" contract="Service.IJSONService" />
<endpoint address="json" binding="customBinding" bindingConfiguration="httpsjsonCustomMapper" behaviorConfiguration="jsonBehavior" contract="Service.IJSONService" />
</service>
</services>
</system.serviceModel>
From what I understand multipleSiteBindingsEnabled="true" and HTTPS do not mix, but I don't understand what resources they would be sharing? If we have internal.example.com and external.example.com hosted in different app pools, I thought they would have process isolation?
seems that adding an HTTPS certificate to the site for "internal.example.com" fixed the issue. Note: without this certificate we were not able to access internal.example.com over either HTTP or HTTPS, with certificate both mechanisms work correctly.
I have a WCF Service programmed in VB.NET that is exhibiting strange behavior. The web.config has the following xml:
<system.serviceModel>
<services>
<service behaviorConfiguration="CentricBasicHttpBehavior" name="OnbaseService">
<endpoint binding="basicHttpBinding" bindingConfiguration="CentRicBasicHttpServerBinding" contract="IOnbaseService">
<identity>
<servicePrincipalName value="HTTP/JFOLKENDT7E" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="CentricBasicHttpBehavior">
<serviceAuthorization impersonateCallerForAllOperations="true" />
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<dataContractSerializer maxItemsInObjectGraph="2147483646" />
<serviceThrottling maxConcurrentCalls="100" maxConcurrentSessions="100" maxConcurrentInstances="100" />
</behavior>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<bindings>
<basicHttpBinding>
<binding name="CentRicBasicHttpServerBinding" maxReceivedMessageSize="5000000">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
When I configure the service in wcf test client, both the Binding Mode and TransportClientCredentialType are coming across as "None". I expected for them to be "TransportCredentialOnly" and "Windows" respectively.
Can someone please share with me how WCF Test Client infers the binding configuration, and how I should go about correcting this issue? The end result is that within the source code of the service, the WindowsIdentity isn't impersonating the user like I expected.
Thanks,
Jason
I work with Jason and we looked at this together. The service configuration needed the name and contact properties to match the fully qualified service class name and fully qualified contact interface name. Otherwise, we were getting the fun new .Net 4.0 defualt bindings for a default service.
In my own experience with WCF, I had modified session Timeouts and connection Timeout settings in the config file but WCF Test Client was not respecting those settings. Seems like WCF Test client just takes up the default values for communicating with WCF services. Hence I test my WCF services using my own custom WCF Test Clients by generating app.config and proxy. cs through svcutil.exe .