服务没有应用程序(非基础设施)端点

我最近创建了一个 WCF 服务(dll)和一个服务主机(exe)。我知道我的 WCF 服务工作正常，因为我能够成功地将服务添加到 WcfTestClient。

但是，当我从服务主机(exe)使用 WCF 时，似乎遇到了一个问题。我可以将对 WCF (dll)的引用添加到我的服务主机(exe) ，并为 exe 创建必要的组件; 比如服务安装程序、服务主机和 app.config，然后编译并使用 InstallUtil 最终安装 exe。但是，当我试图在 Microsoft管理控制台中启动服务时，服务在启动后立即停止。

因此，我开始调查究竟是什么原因导致了这个问题，在事件查看器的应用程序日志中出现了这个错误。

描述:

无法启动服务。 例外情况: 服务“服务”应用程序为零 (非基础设施)端点 可能是因为没有配置文件 找到你的申请，或 因为没有匹配的服务元素 服务名称可以在 配置文件，或因为没有 端点是在服务中定义的 元素。

当我执行这个调用 ServiceHost.Open()时，这个错误实际上是在我的 exe 的 OnStart中生成的。我看到过许多其他个人遇到这个问题的帖子，但是大多数(如果不是全部的话)都声称没有指定服务名或协议; 名称空间和类名。我在配置文件中检查了这两个条目; 在 exe 和 dll 中，它们完全匹配。我让办公室里的其他人在我身后仔细检查了一遍，以确保我没有一度失明。当然，他们和我得出了同样的结论，即所有东西看起来都是正确指定的。我真的不知道现在到底发生了什么。有人能帮我解决这个问题吗？

出现这种情况的另一个可能原因是 app.config 从未被读取; 至少不是我认为应该被读取的那个。这就是问题所在吗？如果是这样，我该如何着手解决这个问题。再说一次，如果你能提供任何帮助，我将不胜感激。

116727 次浏览
小开

One thing to think about is: Do you have your WCF completely uncoupled from the WindowsService (WS)? A WS is painful because you don't have a lot of control or visibility to them. I try to mitigate this by having all of my non-WS stuff in their own classes so they can be tested independently of the host WS. Using this approach might help you eliminate anything that is happening with the WS runtime vs. your service in particular.

John is likely correct that it is a .config file problem. WCF will always look for the execution context .config. So if you are hosting your WCF in different execution contexts (that is, test with a console application, and deploy with a WS), you need to make sure you have WCF configuration data moved over to the proper .config file. But the underlying issue to me is that you don't know what the problem is because the WS goo gets in the way. If you haven't refactored to that yet so that you can run your service in any context (that is, unit test or console), then I'd sugget doing so. If you spun your service up in a unit test, it would likely fail the same way that you are seeing with the WS which is much easier to debug rather than attempting to do so with the yucky WS plumbing.

小开

I just had this problem and resolved it by adding the namespace to the service name, e.g.

 <service name="TechResponse">

became

 <service name="SvcClient.TechResponse">

I've also seen it resolved with a Web.config instead of an App.config.

小开

The endpoint should also have the namespace:

 <endpoint address="uri" binding="wsHttpBinding" contract="Namespace.Interface" />
小开

I had the same problem. Everything works in VS2010 but when I run the same project in VS2008 I get the mentioned exception.

What I did in my VS2008 project to make it work was adding a call to the AddServiceEndpoint member of my ServiceHost object.

Here is my code snippet:

Uri baseAddress = new Uri("http://localhost:8195/v2/SystemCallbackListener");


ServiceHost host = new ServiceHost(typeof(SystemCallbackListenerImpl), baseAddress);


host.AddServiceEndpoint(typeof(CsfServiceReference.SystemCallbackListener),
new BasicHttpBinding(),
baseAddress);
host.Open();

I didn't modify the app.config file. But I guess the service endpoint could also have been added in the .config file.

小开

Just copy the App.config file from the service project to the console host application and paste here and then delete it from the service project.

小开

I just worked through this issue on my service. Here is the error I was receiving:

Service 'EmailSender.Wcf.EmailService' has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.

Here are the two steps I used to fix it:

  1. Use the correct fully-qualified class name:

    <service behaviorConfiguration="DefaultBehavior" name="EmailSender.Wcf.EmailService">

  2. Enable an endpoint with mexHttpBinding, and most importantly, use the IMetadataExchange contract:

    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
小开

My problem was when I renamed my default Service1 class for .svc file to a more meaningful name, which caused web.config behaviorConfiguration and endpoint to correspond to old naming convention. Try to fix your web.config.

小开

I just ran into this issue and checked all of the above answers to make sure I wasn't missing anything obvious. Well, I had a semi-obvious issue. My casing of my classname in code and the classname I used in the configuration file didn't match.

For example: if the class name is CalculatorService and the configuration file refers to Calculatorservice ... you will get this error.

小开

This error will occur if the configuration file of the hosting application of your WCF service does not have the proper configuration.

Remember this comment from configuration:

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.

If you have a WCF Service hosted in IIS, during runtime via VS.NET it will read the app.config of the service library project, but read the host's web.config once deployed. If web.config does not have the identical <system.serviceModel> configuration you will receive this error. Make sure to copy over the configuration from app.config once it has been perfected.

小开

I got a more detailed exception when I added it programmatically - AddServiceEndpoint:

string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));


host.AddServiceEndpoint(typeof(MyNamespace.IService),
new BasicHttpBinding(), baseAddress);
host.Open();
小开

To prepare the configration for WCF is hard, and sometimes a service type definition go unnoticed.

I wrote only the namespace in the service tag, so I got the same error.

<service name="ServiceNameSpace">

Do not forget, the service tag needs a fully-qualified service class name.

<service name="ServiceNameSpace.ServiceClass">

For the other folks who are like me.

小开

I ran Visual Studio in Administrator mode and it worked for me :) Also, ensure that the app.config file which you are using for writing WCF configuration must be in the project where "ServiceHost" class is used, and not in actual WCF service project.

小开

One crucial thing to remember for those working with a Console application to host the WCF service is that the Web.config file in the WCF project is completely ignored. If your system.serviceModel configuration is there, then you need to move that section of config to the App.config of your Console project.

This is in addition to the answers concerning ensuring the namespace is specified in the right places.

小开

As another clue, that indeed fixed this issue in my case.

I'm migrating some WCF services from a console application (that configures in code few WCF services) to an Azure WebRole to publish them in Azure. Every time I add a new service VS edits my web.config and adds this line:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">

Well, with all the advices and answers above I couldn't make it work until I removed all the attributes in the serviceHostingEnvironment element. As you can see I'm not a WCF rockstar but I made it to work with the first Service just by configuring it as:

<service name="FirstService" behaviorConfiguration="metadataBehavior">
<endpoint address=""
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_WcfServicesBinding"
contract="IFirstService" />


</service>

but when I added the second Service it stoped working and I realized that those attributes where there again.

I hope it saves you time.

小开

I had this error in a Windows Service when my WCF Service Library that I created was not connected for hosting, but was connected for connection. I was missing an endpoint. (I wanted both connection and hosting in my Windows Service so that I could serve up the WCF Service to other connections, as well as have the main process of my Windows Service use it as well to do various tasks on a timer/schedule.)

The fix was that I rightlcicked my App.config file and chose Edit WCF Configuration. Then, I did the steps for Create Service so that I could connect to my WCF Service. Now I had two endpoints in my App.config, not just one. One endpoint was for the connection to the WCF Service Library, and another was for the hosting of it.

小开

Today i ran into same issue, posting here my mistake and correction of it so that it may help someone.

While Re-structuring code, I had actually changed Service class and IService names and changed ServiceHost to point to this new Service class name (as shown in code snippet) but in my host applications App.Config file i was still using old Service class name.(refer config section's name field in below snippet)

Here is the code snippet,

 ServiceHost myServiceHost = new ServiceHost(typeof(NewServiceClassName));

and in App.config file under section services i was referring to old serviceclass name , changing it to New ServiceClassName fixed issue for me.

  <service name="ProjectName.OldServiceClassName">
<endpoint address="" binding="basicHttpBinding" contract="ProjectName.IService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<host>
<baseAddresses>
<add baseAddress=""/>
</baseAddresses>
</host>
</service>
小开

As others have mentioned, my problem was that I didn't have the system.serviceModel in my hosting application's app.config. For example:

<configuration>
...
<system.serviceModel>
<services>
<service name="Services.MyServiceManager">
<endpoint address="net.tcp://localhost:8009/MyService"
binding="netTcpBinding"
contract="Contracts.IMyService" />
</service>
</services>
</system.serviceModel>
</configuration>

提交答案