unable to run wcf service app with a renamed service? - c#

I have a basic solution and I've added a WCF service lib. I can view the default service created in the browser after the initial wcf service app has been added to the solution. However, after I rename the default wcf service and its interface class and then view the service in the browser, the web page displays the following runtime error:
The type 'MyNewService.Service1', provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.
However, if I search the project structure for 'Service1' then no references to 'Service1' are returned. Any idea what the root cause of this error might be? It seems like I've been able to do this successfully several times in the past and I don't think that I've ever encountered this roadblock before.

Look in the app.config, look at endpoint->contract, im guessing thats where need to update it.
<system.serviceModel>
<services>
<service name="WcfServiceLibrary1.MyService1">
<endpoint address="" binding="basicHttpBinding"
contract="WcfServiceLibrary1.**IMyService1**">

By default, WCF is configured and exposed via the App.config file of your library. Do a search within your App.config to find the old name and change it to the new.
When you want to change the name of your service in the future, use the refactor name (default ctrl+r, r) operation and it will find the name in the config file for you as well.

Related

project that references another project with WCF service reference - default endpoint not found

I have a project called "AppCore" that I am reusing/referencing in several other projects. AppCore had a method for sending mail via system.net that simplifies emailing. However, I created a WCF service reference (to a service that sends mail in a queue) in the AppCore project, created a test form and was able to use the service just fine. When I create a new project (project name "FeedReader") and reference the AppCore project, however, I get an error: "Could not find default endpoint element that references contract" when attempting to access the WCF service. I think this has something to do with the compiler looking for endpoint info in the FeedReader project app.config file and not getting it from the AppCore project app.config file.
If I reference the WCF service directly from the FeedReader project, the endpoint is found. This would be just fine, however I have a dozen or so other projects I wish to have make this same reference and creating a service reference for all of these and future projects makes management difficult and there's no code reuse (something I wish to avoid).
Is this not possible to do (reference a project that references a WCF service)?
In the AppCore project app.config file, you can see the endpoint (it works fine)
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ISendMailService" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://mailservice:9999/SendMailService.svc/SendMailService"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISendMailService"
contract="Service_SendMail.ISendMailService" name="BasicHttpBinding_ISendMailService" />
</client>
</system.serviceModel>
Naturally, the other projects don't have endpoints defined as they are referencing AppCore (of which there is a definition). NOTE: I plan on having another few service references in AppCore - but am stuck at just one for now until I can solve this dilemma.

Use same WCF service reference in multiple projects

I have multiple projects in my solution which consume the same WCF service. As such they each have a service reference to the WCF service. All's well so far.
When these services are combined into the solution they naturally get the service model from the app.config of the exe. This is where things get interesting. Even though both of the service references point to the same WCF service it looks like I need to expose two end points:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="SecureHttpBindingEndpoint">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address=".../LocalAuthentication.svc" binding="basicHttpBinding" bindingConfiguration="SecureHttpBindingEndpoint" contract="Webservice1.ILocalAuthentication" name="SecureHttpBindingEndpoint" />
<endpoint address=".../LocalAuthentication.svc" binding="basicHttpBinding" bindingConfiguration="SecureHttpBindingEndpoint" contract="WebService2.ILocalAuthentication" name="SecureHttpBindingEndpoint" />
</client>
The only difference between the endpoints is the contract - due to the fact that the service references were added with different names.
My question is Is it possible to only have one endpoint which both services use?
(Note that the projects are used independently in other solutions so it isn't really feasible to factor out a wrapper project just containing the service reference).
The comments given, and in particular the clarification of #Tim explain why it is not possible for my two projects to both use the same endpoint. If any one else is having this issue and really needs to resolve it there seems to be two potential approaches:
Create a Wrapper project actually containing the service reference and have both other projects use that.
Rename the service references in the projects so that they have the same 'namespace'. When defining a service reference you can specify the 'namespace' which is used as the qualified name in the endpoint. If both projects have the same 'namespace' then they can use the same endpoint.
Note that I'm using the '', as the 'namespace' defined in this way is not the full namespace of the service reference, but rather is appended onto the namespace of the project that the service reference is added to. This means that there will not be any namespace conflicts if multiple projects have a service reference with the same 'namespace'.
In my case I was not able to take approach 1., but after some thought (and speaking to other code owners) I was able to take approach 2 by simply deleting and recreating one of the service references. Of course I could have just left it, having two endpoints for the same webservice in a config isn't the end of the world, but it just didn't seem neat.

Using class library with WCF service in ASP.NET 5

In my project I have a class library that contains connections for WCF services.
In old ASP.NET MVC in order to use service methods I only needed to add bindings in my web.config and it would work properly.
The issue that I am having now is that when I call web service in ASP.NET5 I get this exception:
InvalidOperationException: Could not find default endpoint element that references contract 'xxx' 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.
Is there a way that I can add my binding in a similar way as I would do in old MVC apps?
I'm using the configuration below from an MVC app. When you add a reference to your WCF service using the add service ref dialog. A client section will get added to your System.ServiceModel section in your web.config. It should specify the endpoint which what seems to be missing based on the error you're getting.
Hope this helps
<client>
<endpoint address="http://address.to.your.service.com:8080/V3/ConfigService.svc"
binding="basicHttpBinding"
bindingConfiguration="ConfigService.V3.ConfigHttpServiceBinding"
contract="ConfigService.IConfigService"
name="ConfigService.V3.ConfigHttpService"/>
</client
I was able to run by programattically config bindings. thanks to #wiktor-zychla comment.
var documentService = new DocumentServiceClient(
new BasicHttpBinding(BasicHttpSecurityMode.None),
new EndpointAddress("http://localhost:60205/DocumentService.svc"));

WCF Service Can't Be Activated - Service Attribute Value

I have the following service directive, in a project in Visual Studio 2012:
<%# ServiceHost Language="C#" Debug="true" Service="TMO.SA.VMS.Library.ServiceContracts.VMSService" %>
I can clearly see the TMO.SA.VMS.Library project, as well as the ServiceContracts folder and the actual c# service file. And yet I get the following error when I call the service:
The type 'TMO.SA.VMS.Library.ServiceContracts.VMSService', provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.
I get this error from the test project:
The requested service, 'http://njpara-lp4306p5.gsm1900.org/TMO.SA.VMS.Service/VMSService.svc' could not be activated. See the server's diagnostic trace logs for more information.
My endpoint in the test project's app.config.
<endpoint address="http://njpara-lp4306p5.gsm1900.org/TMO.SA.VMS.Service/VMSService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IVMSService" contract="WCF_VMSService.IVMSService" name="BasicHttpBinding_IVMSService"/>
I am at my wits end, because I don't recall making any change to the service, or the way I call it. Any suggestions on what may be causing this are most welcome.

Invoking a Web Service via DLL getting this error

I get this error when invoking my dll with SAP B1 Integration Framework:
Could not find default endpoint element that references contract
'MobiService.AccountsSoap' in the Service Model 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.
But when I invoke the DLL via another .NET application it works.
My app config is set:
<client>
<endpoint address="http://191.211.42.100/MobiVendWSTest/accounts.asmx"
binding="basicHttpBinding" bindingConfiguration="AccountsSoap"
contract="MobiService.AccountsSoap" name="AccountsSoap" />
</client>**
You need to copy the entire service configuration from the DLL's app.config to your application's app.config, as DLLs can not have their own app.config.
The application will read its app.config and the DLL will automatically find the settings even though there's no separate config file for it.

Categories

Resources