Streamed Service - netTCPBinding - Service builds, installs, but will not Start - wcf

I have a WCF service that uses netTcpBinding, transferMode="Streamed", and is installed via installutil via the Windows Process Activation Services method. The service builds and installs just fine. I have all the correct rights for NETWORK SERVICES on the containing folder to access the .exe file. My problem is I keep getting the error:
"The service [ServiceName] on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs."
What is odd is the host installer code is the same as a buffered service I have that runs just fine. In the streamed service, I accounted for passing streams and messages where needed. I am stuck. I can't seem to find out why this service will not stand up. I checked ports, and they are open (no conflict). Does anyone have advice on 'Streamed' netTcp services not starting?
Below is what the App.Config looks like:
<system.serviceModel>
<!--### Service Endpoints: ###-->
<!--Define Bindings-->
<bindings>
<netTcpBinding>
<binding name="netTcpStreamedBinding" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:20:00" sendTimeout="00:10:00"
transferMode="Streamed" maxBufferPoolSize="104857600"
maxReceivedMessageSize="1073741824" maxBufferSize="262144">
<!-- Commented below out to match service that worked to see if this was error - It is not the problem (still no start)
<security mode="Transport">
<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
<message clientCredentialType="Windows" />
</security>-->
</binding>
</netTcpBinding>
</bindings>
<!--Streamer Service-->
<services>
<service name="MyServiceLib.FileStreamer">
<endpoint address="" binding="netTcpBinding" bindingConfiguration="netTcpStreamedBinding" contract="MyServiceLib.IFileStreamer">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:.../MyStreamerService"/>
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<!-- To avoid disclosing metadata information,
set the values below to false before deployment -->
<serviceMetadata httpGetEnabled="False" httpsGetEnabled="False"/>
<!-- 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>
</system.serviceModel>

It appears, even using Visual Studio 2012 I ran into this bug (originally posted for VS 2010):
Bug 571961 (marked as closed) - "Unable to Copy File"
This bug throws the "Unable to copy file... because it is being used by another process" error. The workaround worked for me - clean the project. Close Visual Studio. Re-open VS. Build the project. Following this process allowed me to build my service.
Additionally, on repeated builds, part of the issue was the need to "stop" the service in the Services manager before builds. be sure not to forget this.

Related

WCF web.config file settings for IIS hosting and SSL

After hours of searching for examples, most of which contain only snippets of methods but not the 'whole picture' I am asking for guidance. Starting with the out-of-the-box web.config Visual Studio creates with a new WCF Service, I wrote my basic web service. When you run in debug, WCF Test Client shows the functions that you can test. This is great. Now, wanting to move the code to IIS (first on my local machine, then next to the web server using SSL), I added some code I found on the web. I did have my configuration working at one point but managed to change it so much that I lost the original configurations. So, which that, I have this:
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5"/>
</system.web>
<system.serviceModel>
<protocolMapping>
<add scheme="http" binding="webHttpBinding"/>
</protocolMapping>
<services>
<service name="TaskTrackerAppService.Service1" behaviorConfiguration="">
<endpoint address=""
binding="webHttpBinding"
contract="TaskTrackerAppService.IAppWebService"
behaviorConfiguration="WebBehavior"></endpoint>
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" bindingConfiguration=""></endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="WebBehavior">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="TaskTrackerAppService.IAppWebService"></binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="" binding="webHttpBinding"
bindingConfiguration="TaskTrackerAppService.IAppWebService"
contract="TaskTrackerAppService.IAppWebService"></endpoint>
</client>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<!--
To browse web app root directory during debugging, set the value below to true.
Set to false before deployment to avoid disclosing web app folder information.
-->
<directoryBrowse enabled="true"/>
</system.webServer>
I configure my client desktop application service reference to point to the local IP http:192.168.0.100:90/AppWebService.svc. Then when I run my client application I get an error:
Could not find default endpoint element that references contract 'ServiceReference.IAppWebService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
So I'd like to get the web.config settings corrected. Then deploy to a hosted IIS service where SSL is ready. As a bonus, is there is way to configure the endpoints such that I can still run debugger and get WCF Test Client. In the once working config WCF test stopped working. Can it support both simple and hosted configurations?
Thanks.
The <client> section in the <system.serviceModel> is used by client application to specify the "ABC" properties (Address, Binding, and Contract) of the service endpoint. You should have that section in your desktop application so you can simply remove it from your server configurations.
The <client> section in the app.config of your desktop application should, however, have the same "ABC" properties as the service endpoint. Since your service binding is webHttpBinding the client should also have webHttpBinding as binding but I can see that the bindingConfiguration it is referring to, TaskTrackerAppService.IAppWebService is actually a basicHttpBinding so that is a misconfiguration.
Further, since your production environment is using SSL so your production web.config should have binding configuration for SSL something similar to this:
<bindings>
<webHttpBinding>
<binding name="webBindingHTTPS">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</webHttpBinding>
</bindings>
with the following endpoint configuration:
<endpoint address=""
binding="webHttpBinding"
contract="TaskTrackerAppService.IAppWebService"
behaviorConfiguration="webBindingHTTPS"></endpoint>
The best way to achieve this is to use web.config transformation syntax. In that case, your Release web.config could have the following elements:
<bindings>
<webHttpBinding>
<binding name="webBindingHTTPS" xdt:Transform="Insert">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</webHttpBinding>
</bindings>
<endpoint address="" xdt:Transform="Replace" xdt:Locator="Match(name)"
binding="webHttpBinding"
contract="TaskTrackerAppService.IAppWebService"
behaviorConfiguration="webBindingHTTPS">
</endpoint>
In this way, whenever you project is built in Debug mode it will be configured withoud SSL and whenever is built in Release mode, it will use SSL.

Wcf Http and Https

Help please!!
I had the following set up working perfectly:-
WCF Service Library hosted in web site on local IIS 7
Silverlight Application on a web site on local IIS 7 using above services
The solution I am writing is for intranet and not internet use, however I have been told by my bosses that it needs to be over Https. I am using Windows Authentication.
Below is a chunk of the config file for one of the service endpoints (changed to remove company info etc):-
<services>
<service behaviorConfiguration="stdHttpBehavior" name="WcfServiceLibrary.StaticDataService">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="windowsHttpBinding"
name="StaticDataService" contract="WcfServiceLibrary.ServiceContracts.IStaticDataService" />
<endpoint address="mex" binding="mexHttpBinding" name="" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/WcfServiceLibrary/StaticDataService/" />
</baseAddresses>
</host>
</service>
<behaviors>
<serviceBehaviors>
<behavior name="stdHttpBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<dataContractSerializer maxItemsInObjectGraph="2147483647" />
</behavior>
</serviceBehaviors>
</behaviors>
To experiment with Https I created a 'Self-Signed Certificate'. I then added https to the Default Web Site bindings and changed the two web sites to require SSL and also changed the relvant URIs in the config files. I managed to get this to work but now I want to go back to standard Http and finish the project in that mode as it was easier to work with. I changed all the settings back (and I have checked these extremely carefully).
Now I get this error if I try to downoad the Service definition in the Silverlight project: -
'Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address schemes are [http].'
If I put back the certificate and binding in IIS. The Service definition appears to download OK, however it references an https URI and therefore none of the actual service calls work as they are http adresses!
I tried adding a new web site to host the service but got the same errors.
I have been trying to solve this for the last couple of days but cannot find an answer. It seems as though there is a hidden reference somewhere and not in my project as it continued with a new web site added to IIS.
To use SSL over HTTP under Basic HTTP binding, you need to switch your endpoint to use Transport-level security. In your case you will also want to indicate the client credential type:
<bindings>
<basicHttpBinding>
<binding name="windowsHttpBinding">
<security mode="Transport">
<transport clientCredentialType="Windows" />
<message />
</security>
</binding>
</basicHttpBinding>
</bindings>
It may seem obvious, but did you change the security mode on the windowsHttpBinding binding configuration to BasicHttpSecurityMode.None?
<bindings>
<basicHttpBinding>
<binding name="windowsHttpBinding">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
Related resources:
Transport Security Overview
BasicHttpSecurityMode Enumeration

Exposing WCF Services Via HTTP when not hosted in IIS

Like the title says, we need to set up WCF services between a .NET app, and a Adobe AIR app. We don't want to run IIS on the machine, and would much prefer to install and run the WCF services hosted within a windows service.
However, I am uncertain of doing that will let us use HTTP as the transport, of does that only work within IIS? I was able to set things up to use the TCP transport, but that doesn't interop with AIR nearly as nice as using HTTP.
EDIT: Some test code I've been using to see if this works:
Regular console app:
static void Main()
{
using (ServiceHost host = new ServiceHost(typeof(TestService)))
{
host.Open();
}
Console.WriteLine("Waiting...");
Console.ReadLine();
}
TestService is a simple HelloWorld type service.
In the App.Config:
<configuration>
<system.serviceModel>
<services>
<service name="WCFExample2.TestService" behaviorConfiguration="WCFExample2.TestServiceBehavior">
<host>
<baseAddresses>
<add baseAddress = "http://localhost:8731/Design_Time_Addresses/WCFExample2/Service1/" />
</baseAddresses>
</host>
<!-- Service Endpoints -->
<!-- Unless fully qualified, address is relative to base address supplied above -->
<endpoint address ="" binding="wsHttpBinding" contract="WCFExample2.ITestService">
<!--
Upon deployment, the following identity element should be removed or replaced to reflect the
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<!-- Metadata Endpoints -->
<!-- The Metadata Exchange endpoint is used by the service to describe itself to clients. -->
<!-- This endpoint does not use a secure binding and should be secured or removed before deployment -->
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WCFExample2.TestServiceBehavior">
<!-- To avoid disclosing metadata information,
set the value below to false and remove the metadata endpoint above 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>
</system.serviceModel>
</configuration>
You should have no trouble setting up a Windows NT Service which hosts your WCF service and exposes HTTP endpoints - no need for IIS (but the WCF runtime will use the http.sys kernel mode driver).
Have you tried and failed? If so - can you show us what you had, and how and where it failed?
As a bare minimum, you'd probably want to have something like this config on your service side:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Default">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="Default"
sendTimeout="00:05:00"
maxBufferSize="500000"
maxReceivedMessageSize="500000" >
<security mode="Message">
<message clientCredentialType="UserName" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="Namespace.MyWCFService"
behaviorConfiguration="Default">
<host>
<baseAddresses>
<add baseAddress="http://MyServer:8282/MyWCFService/"/>
</baseAddresses>
</host>
<endpoint
address="basic"
binding="basicHttpBinding" bindingConfiguration="Default"
contract="Namespace.IMyWCFService" />
</service>
</services>
</system.serviceModel>
Of course, you might need to tweak things like the timeout settings, buffer size settings etc. on your binding, the security mode, and quite possibly other settings as you need them to be.
Marc
You could skip all the config and use the WebServiceHost class (which will do it all for you in a fairly standard way). Get that working then look into tailoring the config manually to meet any extra requirements you may have.
All the info you need is here WebServiceHost on MSDN it's a very straightforward way to get started on a custom (i.e. non IIS) hosted http service.
Mike
Apart from the config file settings one more thing to consider.
If you selfhost in a windows service, a http endpoint then
Make the service login account a local admin on the machine
or
You have to register the service account for the http namespace with http.sys.
This step has to be done by a local admin but only once in each machine. You can use the HttpSysCfg tool to do this in XP/win 2003. For vista/win 2008 use netsh.

WCF - Windows authentication - Security settings require Anonymous

I am struggling hard with getting WCF service running on IIS on our server. After deployment I end up with an error message:
Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service.
I want to use Windows authentication and thus I have Anonymous access disabled. Also note that there is aspNetCompatibilityEnabled (if that makes any difference).
Here's my web.config:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<bindings>
<webHttpBinding>
<binding name="default">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
</security>
</binding>
</webHttpBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name="AspNetAjaxBehavior">
<enableWebScript />
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="defaultServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceAuthorization principalPermissionMode="UseWindowsGroups" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="xxx.Web.Services.RequestService" behaviorConfiguration="defaultServiceBehavior">
<endpoint behaviorConfiguration="AspNetAjaxBehavior" binding="webHttpBinding"
contract="xxx.Web.Services.IRequestService" bindingConfiguration="default">
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange"></endpoint>
</service>
</services>
</system.serviceModel>
I have searched all over the internet with no luck. Any clues are greatly appreciated.
So it seems like pretty common issue. The point is to remove mex from your bindings:
<endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange"></endpoint>
Alternativelly you enable Anonymous access in IIS and in your web.config you make sure anonymous access is denied.
Hope this will help some other soul.
(I was 100% sure I tried it with mex removed. :-O )
You may check this one.
I managed to make it work as expected.
<configuration>
...
<system.serviceModel>
...
<bindings>
<basicHttpBinding>
<binding>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
...
</system.serviceModel>
...
</configuration>
just use your service bindings for mex too.
So change your current config :
<endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange"></endpoint>
to
<endpoint address="mex" binding="webHttpBinding" bindingConfiguration="default" name="mex" contract="IMetadataExchange"></endpoint>
That should solve the problem
Anonymous authentication can, and in some cases must be enabled for the service but not for the site.
So check that your site's "root" authentication has only Windows Authentication enabled. Then expand your site, select 'service' folder and make sure that your service has Windows and Anonymous Authentication enabled.
I had identical environment where this worked, only difference in these environments was the service's authentication. Problem in my case was not caused be selected providers (Ntlm or Negotiate) but the authentication settings for site and service.
At least I had identical error message with basic MSSQL Master Data Services web site & service and this was the solution. I did get the error when running just the service but the site worked almost ok, MDS Explorer did not work because service's authentication settings were wrong at first. Cause of this miss-configuration might be a bug in MDS Configuration Manager when creating new MDS site?
So in my case the problem was not to be fixed by doing any special editing to the web.config nor the ApplicationHost.config files, I didn't do any editing the config files. Just selected the correct authentication settings for the web site and it's service in IIS manager. I am not sure that this is the case in here, but maybe worth to try?
It worked for me when I remove 'mex' endpoint and also set clientCredentialType = 'Ntlm'
I was hosting my WCF inside SharePoint.
Yes, it looks like you need to remove the mex endpoint completely. Setting
<serviceMetadata httpGetEnabled="false"/>
alone did not work. Thanks!
Additional solution:
You just have to make sure that the Service name and contract are correct.
Hope it helps in some way.
It appears this MEX binding issue was fixed in .NET 4.0. Changing our server's App Pool .NET CLR version from 2.0 to 4.0 cleared up the issue.

Error in WCF client running under IIS 5.0 with server on Windows 2008

I have a .Net 3.5 SP1 WCF service running under IIS 7 on a Windows 2008 machine. When I try to connect to this service from an IIS hosted WCF service running under IIS 5.0 (Windows XP) .Net 3.5 SP1, I get the following error:
The token provider cannot get tokens for target: http://(URL for WCF service)
I've built a simple console application that can successfully connect to the WCF service using the exact same configuration. I've also built a simple web application hosted under the WebDev server (ASP.Net server that comes with Visual Studio 2008) and it is able to successfully connect to the WCF service. When I configured a virtual directory within IIS (Windows XP) to point at the same directory as the WebDev server, I get the following error:
No credentials are available in the security package
But, if I set the web.config to turn impersonation on using my logon credentials, it works fine. This is not a good long term solution for obvious reasons. The one difference that I've noted between IIS and the WebDev servers are the user that each process is running under. IIS runs under the ASPNet account and WebDev runs under my account.
Here's the config for the WCF section on the client:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="mexBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceThrottling maxConcurrentCalls="200" maxConcurrentSessions="200" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="FABindings" maxReceivedMessageSize="2147483647">
<readerQuotas maxStringContentLength="300000"/>
<security mode="Message">
<message clientCredentialType="Windows" negotiateServiceCredential="false" establishSecurityContext="false" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://<server url>/FinancialAggregator/v3/Services/FAService.svc"
binding="wsHttpBinding" bindingConfiguration="FABindings"
contract="ServiceReference1.IFilteredService" name="FAServiceEndpoint">
<identity>
<servicePrincipalName value="<UsernameRunningTheAppPoolOnW2k8>" />
</identity>
</endpoint>
</client>
Here's the server config (as requested):
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="wsHttpBinding" maxReceivedMessageSize="2147483647">
<security mode="Message">
<message establishSecurityContext="false" negotiateServiceCredential="false" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="mexBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceThrottling maxConcurrentCalls="200" maxConcurrentSessions="200" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="mexBehavior" name="FCSAmerica.Financial.Aggregator.Service.FilteredService">
<endpoint name="FAServiceEndpoint" address="" binding="wsHttpBinding" bindingConfiguration="wsHttpBinding" contract="FCSAmerica.Financial.Aggregator.Service.IFilteredService">
</endpoint>
</service>
</services>
Any thoughts on the cause of this error?
Thanks!
When you access the services via IIS, with impersonate = false, then it is the ASPnet account which is used to access the service on the Windows 2008 machine.
The ASPnet account is a local account and therefore does not have rights on the 2008 machine.
There are 3 ways you could solve this:
Allow annonymous access to the service on the Windows 2008 machine
Use impersonate = true (as you have)
Change the identity of the application pool from aspnet to a domain account with the required access.
I guess the ultimate answer to this question is to simply upgrade to an OS that allows you to set the identity of an application pool, which I have done ages ago.
Thanks for the consideration.
Matt