I've a WCF service which is referenced into an assembly. This Assembly has been referenced in a BizTalk project.
While calling the WCF method via Orchestration it gave following error:
Could not find default endpoint element that references contract 'SubscriberService.ISubscriber' in the ServiceModel client configuration section.
I've googled it and it is a known issue if you try to call the WCF via assembly in a Window project or web application. This can be resolved if we adds configuration in the project which is calling the assembly. And I've tested the scenario in sample project and copying the client configuration to my test project resolves the issue but this is not working in BIZTALK project.
Configuration in App.Config file of assembly:
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="CustomerMain.HelperAssembly.CoreProcess.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<system.serviceModel>
<protocolMapping>
<add binding="basicHttpBinding" scheme="http" />
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ISubscriber" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:81/SubscriberService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISubscriber"
contract="SubscriberService.ISubscriber" name="BasicHttpBinding_ISubscriber" />
</client>
</system.serviceModel>
</configuration>
Configuration in Biztalk Project's App.Config file:
<configuration>
<system.serviceModel>
<protocolMapping>
<add binding="basicHttpBinding" scheme="http" />
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ISubscriber" bypassProxyOnLocal="true" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:81/SubscriberService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISubscriber"
contract="SubscriberService.ISubscriber" name="BasicHttpBinding_ISubscriber" />
</client>
</system.serviceModel>
</configuration>
Thanks
Because this is a BizTalk project, the answer begins with do not do this.
While you can, it is not the correct way to call a Service in a BizTalk app.
So, the correct way to address this is to add that Service to your app using the BizTalk WCF Adapter.
If anyone on you team raises any objections, we're happy to help you address those. There is no scenario where what you describe is the right thing to do.
Related
I'm trying to deploy a WCF service as a Windows Azure Role using wsHttpBinding.
When the client tries to connect to it, it keeps getting the following exception:
[SynchronizingContextState.Process] [System.Net.WebException: The remote server returned an error: (415) Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'..]
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
This would seem to indicate that the service is using basicHttpBinding instead. However, I checked my Web.config many times and can't seem to find anything wrong. Plus, the same service works perfectly when being hosted outside Azure.
I connected to the Azure VM and confirmed that the correct Web.config is deployed, but it looks as if it's just being ignored, because I cannot get the service metadata either, even though it's supposedly enabled.
Here's my Web.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
</entityFramework>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<customErrors mode="Off" />
</system.web>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="BackendServiceBehavior">
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="BackendServiceBinding" maxReceivedMessageSize="655360">
<security mode="None" />
</binding>
</wsHttpBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<services>
<service name="MyNamespace.BackendService" behaviorConfiguration="BackendServiceBehavior">
<endpoint name="Backend" address="" binding="wsHttpBinding" bindingConfiguration="BackendServiceBinding" contract="MyNamespace.IBackendService" />
<endpoint name="BackendMex" address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/BackendService.svc" />
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
</configuration>
Am I missing something here? Thank you very much.
Did you try adding to the endpoint behavior?
<behavior name="web">
<webHttp />
</behavior>
(if you want MEX to be working do it for it to too)
Ok, I finally fixed it, it was a bad case of PEBKAC. =/
I've seen somebody have the same problem because he didn't include the namespace in the service name so I suspected it was a namespace issue, but I've looking at the wrong place all the time.
Turns out the Azure implementation for the service was defined in the wrong namespace. I corrected it and voilá, now it works.
Hope this is useful to somebody else, at least.
I have a WCF service that I'm using in my Silverlight project. I've followed pretty much any information on how to set up https and ssl for WCF services. The service can be called perfectly fine if SSL in not required but I noticed while examining the communications with fiddler that the WCF service was still in http protocol. Further more if I enable SSL the WCF service cant be browsed in a browser (right clicking in VS2010 -> selecting browse) .
My suspicion is that the service is still being called on some internal method with the http protocol.
Any suggestions to how to fix this?
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<customBinding>
<binding name="AuthService.customBinding" >
<binaryMessageEncoding />
<httpsTransport />
</binding>
</customBinding>
</bindings>
<services>
<service name="AuthService">
<endpoint address="" binding="customBinding" bindingConfiguration="AuthService.customBinding" contract="AuthService" />
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
</configuration>
Thanks
Any specific reason on why you are using a custom binding. Also your service name attribute and contract attribute needs to be fully qualified.
You can use simple basicHttpBinding if you want your WCF service to be compliant with basic profile 1.1 which allows non .NET clients to access as well.
I am attempting to create a dummy security token service using the WCF Security Token Service website template. When creating the website, if I specify a file system URI and host the site in the ASP.NET Development Web Server then everything appears to be fine. However, I want the STS to use SSL and I would also like to avoid the cross-domain issues that arise when using the dynamic ports assigned by the ASP.NET Development Web Server. So I recreated the same website but specify an HTTPS URI to a preconfigured web application in IIS 7.5 (e.g. https://localhost/SecurityTokenService/) instead of a file system URI. Now all attempts to navigate to the Service.svc file result in a forceful connection reset.
Below is my web.config file although the fact that it works when hosted in the ASP.NET Development Web Server makes me think the problem is with an IIS setting. What are some things I might try to figure out what's going on?
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<configSections>
<section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<appSettings>
<add key="IssuerName" value="ActiveSTS"/>
<add key="SigningCertificateName" value="CN=STSTestCert"/>
<add key="EncryptingCertificateName" value=""/>
</appSettings>
<connectionStrings />
<location path="FederationMetadata">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
<system.web>
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</assemblies>
</compilation>
<authentication mode="None"/>
<pages>
<controls>
<add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</controls>
</pages>
</system.web>
<system.web.extensions>
<scripting>
<webServices>
</webServices>
</scripting>
</system.web.extensions>
<system.serviceModel>
<services>
<service name="Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract" behaviorConfiguration="ServiceBehavior">
<endpoint address="https://localhost/SecurityTokenService/Service.svc/IWSTrust13" binding="ws2007HttpBinding" contract="Microsoft.IdentityModel.Protocols.WSTrust.IWSTrust13SyncContract" bindingConfiguration="ws2007HttpBindingConfiguration"/>
<host>
<baseAddresses>
<add baseAddress="http://localhost/SecurityTokenService/Service.svc" />
</baseAddresses>
</host>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<bindings>
<ws2007HttpBinding>
<binding name="ws2007HttpBindingConfiguration">
<security mode="TransportWithMessageCredential">
<message establishSecurityContext="false" clientCredentialType="UserName" />
</security>
</binding>
</ws2007HttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
<microsoft.identityModel>
<service>
<securityTokenHandlers>
<remove type="Microsoft.IdentityModel.Tokens.WindowsUserNameSecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add type="CustomUserNamePasswordTokenHandler, App_Code"/>
</securityTokenHandlers>
</service>
</microsoft.identityModel>
</configuration>
UPDATE: I can navigate to other files in the web application. Just not the *.svc file. I don't have anything to work with except for the 101 statuc code so this is kind fo frustrating.
UPDATE: Further experimentation indicates that the problem only exists with WCF services that are STSs and hosted in IIS. If I host a regular WCF service in IIS there is no problem. I downloaded a variety of example projects containing custom STSs and they all exhibit the same behavior. This leads me to believe that there is something wrong with the configuration of my IIS that prevents it from playing nice with an STS. Beats me how I might figure out what the problem is ...
The base address in your service is configured to be HTTP not HTTPS. Also, if you are browsing to it using HTTPS and expecting to see the service definition I think you would need httpsGetEnabled not httpGetEnabled. Could these be the problem?
I opened a support case with Microsoft about this. After digging through a lot of log and trace files, we determined that the physical path of the virtual directory in IIS was not correct. This is weird because Visual Studio created the virtual directory on my behalf when I added the project to my solution. I deleted and recreated the virtual directory manually and everything started working.
yet another failed attempted to get a WCF Rest (no svc file) service using basicHttpBinding deployed to IIS 7.5. I believe I have the website configured properly along with IIS. I'm sure the problem resides in my config. The response I'm receiving is a 500 Error. I have a MVC 3 web running fine on this box.
The WCF Rest service is using basicHttpBinding with security mode of Transportcredentialonly. Here is my config;
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
<handlers>
<add name="UrlRoutingHandler" preCondition="integratedMode" verb="*" path="UrlRouting.axd" type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</handlers>
</system.webServer>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="AuthBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic"></transport>
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="NamedService">
<endpoint contract="Namespace.IService" binding="basicHttpBinding" bindingConfiguration="AuthBinding"></endpoint>
</service>
</services>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" helpEnabled="true" automaticFormatSelectionEnabled="true" />
</webHttpEndpoint>
</standardEndpoints>
</system.serviceModel>
Current web and IIS config based on other posts;
I have a v4.0 app pool created for the web
I have a website created associated with the above app pool
I have both 32bit and 64bit .NET v4 ISAPI filters enabled
I register v4 again with Aspnet_regiis.exe -i
I have HTTP Redirect installed
I have basic authentication enabled
Any help would be greatly appreciated. I've been at this for a day now. BTW... I'm not seeing any event messages. I know DNS is configured properly because I can strip away the WCF stuff and put a temp html page in the web and it works.
---------------- UPDATE ---------------------
Still having issues even after using this stripped down config. The couple things I left out is this is a x64 OS and I'm using castle as an IoC. I did run the Frameword64/aspnet_regiis.exe.
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="castle" type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor"/>
</configSections>
<connectionStrings>
<add name="Main.ConnectionString" connectionString="data source=blah;initial catalog=newdatabase;User ID=web;Password=testing;persist security info=False;packet size=4096;" providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<compilation targetFramework="4.0" />
<httpModules>
<add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.Windsor" />
</httpModules>
</system.web>
<castle>
<properties>
<myConnStr>data source=blah;initial catalog=newdatabase;User ID=web;Password=testing;persist security info=False;packet size=4096;" providerName="System.Data.SqlClient</myConnStr>
</properties>
<components>
<component id="RestService" service="Namespace.Rest.IRestService, Namespace.Rest" type="Namespace.Rest.RestService, Namespace.Rest" lifestyle="PerWebRequest"/>
<component id="Repository" service="Namespace.Domain.Interfaces.IRepository, Namespace.Domain" type="Namespace.Domain.Repository, Thumbfound.Domain" lifestyle="PerWebRequest">
<parameters>
<connectionString>#{myConnStr}</connectionString>
</parameters>
</component>
</components>
</castle>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
</system.webServer>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
<standardEndpoints>
<webHttpEndpoint>
<!--
Configure the WCF REST service base address via the global.asax.cs file and the default endpoint
via the attributes on the <standardEndpoint> element below
-->
<standardEndpoint name="" helpEnabled="true" automaticFormatSelectionEnabled="true"/>
</webHttpEndpoint>
</standardEndpoints>
</system.serviceModel>
</configuration>
yet another failed attempted to get a
WCF Rest (no svc file) service using
basicHttpBinding deployed to IIS 7.5.
There's your problem right there - WCF REST must use the webHttpBinding - not basicHttpBinding (that's a SOAP binding).
Turns out this was a Castle Windsor configuration issue.
The resolution to my problem was removing the <httpmodules> section within <system.web> and placing my PerRequestLifestyleModule config in the <modules> section of <system.webServer>. I guess IIS 7 doesn't like httpmodules in integrated mode.
I am trying to add a WCF service reference to my web application using VS2010. It seems to add OK, but the web.config is not updated, meaning I get a runtime exception:
Could not find default endpoint
element that references contract
'CoolService.CoolService' 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.
Obviously, because the service is not defined in my web.config. Steps to reproduce:
Right click solution > Add > New Project > ASP.NET Empty Web Application.
Right click Service References in the new web app > Add Service Reference.
Enter address of my service and click Go. My service is visible in the left-hand Services section, and I can see all its operations.
Type a namespace for my service.
Click OK. The service reference is generated correctly, and I can open the Reference.cs file, and it all looks OK.
Open the web.config file. It is still empty!
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.serviceModel>
<bindings />
<client />
</system.serviceModel>
Why is this happening? It also happens with a console application, or any other project type I try. Any help?
Here is the app.config from my WCF service:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true" />
</system.web>
<!-- When deploying the service library project, the content of the config file must be added to the host's
app.config file. System.Configuration does not support config files for libraries. -->
<system.serviceModel>
<services>
<service name="CoolSQL.Server.WCF.CoolService">
<endpoint address=""
binding="webHttpBinding"
contract="CoolSQL.Server.WCF.CoolService"
behaviorConfiguration="SilverlightFaultBehavior">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8732/Design_Time_Addresses/CoolSQL.Server.WCF/CoolService/" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<endpointBehaviors>
<behavior name="webBehavior">
<webHttp />
</behavior>
<behavior name="SilverlightFaultBehavior">
<silverlightFaults />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<webHttpBinding>
<binding name="DefaultBinding"
bypassProxyOnLocal="true"
useDefaultWebProxy="false"
hostNameComparisonMode="WeakWildcard"
sendTimeout="00:05:00"
openTimeout="00:05:00"
receiveTimeout="00:00:10"
maxReceivedMessageSize="2147483647"
transferMode="Streamed">
<readerQuotas maxArrayLength="2147483647"
maxStringContentLength="2147483647" />
</binding>
</webHttpBinding>
</bindings>
<extensions>
<behaviorExtensions>
<add name="silverlightFaults"
type="CoolSQL.Server.WCF.SilverlightFaultBehavior, CoolSQL.Server.WCF" />
</behaviorExtensions>
</extensions>
<diagnostics>
<messageLogging logEntireMessage="true"
logMalformedMessages="false"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="false"
maxMessagesToLog="3000"
maxSizeOfMessageToLog="2000" />
</diagnostics>
</system.serviceModel>
<startup>
<supportedRuntime version="v4.0"
sku=".NETFramework,Version=v4.0" />
</startup>
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging"
switchValue="Information, ActivityTracing">
<listeners>
<add name="messages"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\messages.e2e" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
I discovered how to work around this. My WCF service was implemented in its own project, and hosted in by a separate console application in the same solution. If I run the WCF service as the solution's startup project (eg. let VS host it for me) then adding the reference works fine and the correct lines are added to the client web.config. But if I host service from within my console application, while I can still add the reference, the client's web.config does not get modified. So, a workaround is to first let VS host the service, then add the reference, then change the service to be hosted (at the same address and port) in the console application.
This is surprising behaviour, and I am curious if anyone can shed any light on it?