Webservice funktioniert mit einer Konfiguration aber nicht mit der anderen

Da es dasselbe Programm ist und nur die app.config anders, laufen die beiden Services nicht gleichzeitig.

Klar, irgendwie hat er den Port im Zugriff. Aber das kann eigentlich nichts Externes sein, was da läuft. Denn auch wenn ich schnell hintereinander die app.configs wechsle und das Programm starte, kommt immer dasselbe Ergebnis:

app.config 1 benutzen, Programm starten: Service geht
Programm stoppen
app.config 2 benutzen, Programm starten: AddressAlreadyInUseException
Programm stoppen
app.config 1 benutzen, Programm starten: Service geht
Programm stoppen
app.config 2 benutzen, Programm starten: AddressAlreadyInUseException
Programm stoppen

Das muss also irgendwas sein, was Visual Studio intern macht, wenn ich das Programm mit der zweiten app.config starte. Dass er beim Starten aus irgendeinem Grund schon was registriert und es dann ein zweites Mal versucht.
(Der Port ist ja auch nicht irgendein beliebiger Port, sondern offenbar von Visual Studio fest fürs Debuggen vorgesehen.)

Vielleicht hat es auch mit https zu tun.

Das Problem kann übrigens ganz leicht nachvollzogen werden: Einfach eine Konsolenanwendung erstellen, app.config hinzufügen und den unten stehenden Code in die Program.cs einfügen. Dann die app.config mit den Inhalten aus dem vorherigen Post füllen und du kannst das Ergebnis sehen.

using System;
using System.ServiceModel;

namespace Service
{
    [ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        string Test();
    }

    public class TestService : ITestService
    {
        public string Test()
        {
            return "Test";
        }
    }

    static class Program
    {
        static void Main()
        {
            ServiceHost serviceHost = null;

            try
            {
                serviceHost = new ServiceHost(typeof(TestService));

                serviceHost.Open();

                Console.WriteLine("Service was started.");
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.GetType() + ": " + ex.Message);
            }
            finally
            {
                if (serviceHost != null && serviceHost.State != CommunicationState.Faulted)
                    ((IDisposable)serviceHost).Dispose();

                Console.ReadLine();
            }
        }
    }
}

inflames2k

ICh kann jetzt sonst nichts weiter finden. - Eventuell könntest du die Frage wenn sie hier keiner beantwortet mal bei mycsharp.de stellen.

Kommt denn bei dir derselbe Fehler?

inflames2k

Ich hab jetzt keinen WCF-Dienst erstellt und dies ausprobiert. Also bisher: nein.

PuppetMaster2k

Ich hoffe dir kann folgender Link helfen:
http://blogs.msdn.com/b/keithmg/archive/2009/08/10/http-could-not-register-url-http-another-application-has-already-registered-this-url-with-http-sys.aspx

Leider nicht. Den Link kenn ich schon und er hat mich vorher schon geärgert. Ich meine, guck doch mal, was der für einen Schwachsinn erzählt:

Are you self hosting a WCF library service inside a console or windows forms application? Then the most likely cause of this problem is that you have the library project contained within your same solution.

Was meint der hier überhaupt? Ich habe genau ein Projekt in einer Solution. Ich hab da nicht noch irgendwo ein separates Webserviceprojekt drin, wozu auch? Es ist eine simple Konsolenanwendung, mehr nicht.

Basically remove the wcf lib from the solution and reference it.

What??? Erinnert mich an:

*Forum question:
I fell into a pipe in "Super Mario Bros." How can I get out of it again?

Answer:
I think the pipe is a glitch. There's no way around it.*

Hier genau das gleiche: "Entferne die WCF-Lib und referenziere sie." Ich weiß nicht mal, was der mir damit sagen will, geschweige denn, dass das irgendwas mit meiner Situation zu tun hat. Und ich bezweifle, dass irgendjemand genau diese Situation hatte. Wer weiß, aus welchem Halbwissen und eingebauten, aber vergessenen Workarounds er sich diesen Tipp zusammengereimt hat.

Der gesamte Code, den ich oben gepostet habe (den C#-Code und die beiden app.configs) reicht aus, um das Problem zu rekonstruieren. Eine Solution, eine Konsolenanwendung. Kein IIS, kein IIS Express, kein Cassini. Nichts. Nur eine Konsolenanwendung mit dem oben geposteten Code und einer app.config. Und wenn die app.config den Inhalt des ganz ersten XMLs enthält, funktioniert es immer. Und wenn die app.config aus der zweiten XML besteht, funktioniert es nie.
Alles, was ich bisher dazu im Internet gefunden habe, ist Blödsinn.

Er geht davon aus, wie ich es auch tun würde, dass deine komplette WCF Funktionalität in einem eigenen Projekt liegt. Sein Vorschlag ist schlicht und ergreifend, dass du das Projekt aus der Solution entfernen sollst und nur einen Verweis auf die DLL hinzufügen sollst.

Da du aber ohnehin nur ein Projekt hast, wirst du eine extra Assembly dafür erstellen müssen.

Aha. Dazu hätte ich dann zwei Fragen:

1. Wie soll ich in so einem Fall meinen Webservice debuggen? Das kann doch nun wirklich nicht die Lösung sein.

2. Funktioniert das auch wirklich? (Ich bin im Moment an einem anderen Rechner und kann es deshalb nicht ausprobieren.) Denn ich vermute zu 90 %, dass das genau gar nichts bringen wird. Ich packe meine Webservicefunktionalität in eine eigene DLL, rufe die Initialisierungsfunktion auf und es wird höchstwahrscheinlich genau derselbe Fehler kommen und ich werde mich erneut ärgern, was der für einen Scheiß zusammenschreibt. Kann also jemand bestätigen, dass der Fehler bei ihm auftritt, wenn er alles in einem Projekt hat, während der Fehler nicht mehr auftritt, wenn er die Webservicefunktionalität in ein Library-Projekt auslagert und dies als kompilierte DLL statt als Projekt referenziert?

inflames2k

Zu erstens:

Du öffnest im Visual Studio das Projekt, welches die WCF-Klassen enhält und hängst den Debugger an dein Programm an.
Damit kannst du die WCF Funktionalität Problemlos testen.

Zu zweitens:

Wenn ich das aus dem Artikel richtig verstanden habe, ist doch das Grundproblem dass der VSHost den Port reserviert. - Insofern könnte es durchaus sein, dass der Port auf die im Artikel beschriebene Weise nicht mehr reserviert ist.

Aber was red ich, probiers doch einfach mal aus.

Ausprobieren kann ich es erst am Montag wieder.

Mich würde aber weiterhin interessieren, wieso auf einmal ein Port reserviert ist, wo doch derselbe Port mit demselben Programm und anderer app.config eben nicht reserviert ist.

Nen Scheiß funktioniert das. Ich wusste doch, dass der Typ von der Webseite nur Gülle quatscht.
Es ist völlig egal, ob ich die Webservicefunktionalität im selben Projekt, in einem extra Projekt oder in einer kompilierten DLL habe, die nicht zur Solution gehört: Der AlreadyInUse-Fehler kommt jedesmal. Selbst wenn ich alles im Release-Modus kompiliere, Visual Studio zumache und die Anwendung durch Anklicken starte, kommt dieser Fehler.

Fazit: Ich bin noch keinen Schritt weiter.

inflames2k

Dann beendet sich deine Anwendung nicht korrekt / schnell genug. Irgend nen Grund muss es haben, dass der Port reserviert bleibt.

Prüf doch mal, ob der Service-Prozess noch läuft wenn du den mit der anderen Config startest.

// Alternativ: Prüfe welche Anwendung den Port zur Zeit der Fehlermeldung für sich beansprucht.

Wie oft soll ich es noch erklären:

Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.
Programm mit erster app.config: Geht.
Programm mit zweiter app.config: Geht nicht.

Was macht dich glauben, dass es was damit zu tun hat, dass ich das Programm nicht richtig beende? Meinst du, mir passiert es immer genau jedes zweite Mal, dass ich händisch was falsch mache?

// Alternativ: Prüfe welche Anwendung den Port zur Zeit der Fehlermeldung für sich beansprucht.

Keine.

inflames2k

Claudius schrieb:

Was macht dich glauben, dass es was damit zu tun hat, dass ich das Programm nicht richtig beende?

Die Tatsache, das der Port noch verwendet wird.

Claudius schrieb:

// Alternativ: Prüfe welche Anwendung den Port zur Zeit der Fehlermeldung für sich beansprucht.

Keine.

Das kann und will ich nicht glauben. Entweder du enthältst uns was vor oder die Fehlermeldung sieht anders aus, oder aber der Port wird wirklich verwendet.

Wie hast du geprüft, welche Anwendung den Port beansprucht um zu der Aussage "Keine." zu kommen?

// EDIT:
Womöglich hilft dir aber das: Windows Service hosted WCF over HTTPS

inflames2k schrieb:

Claudius schrieb:

Was macht dich glauben, dass es was damit zu tun hat, dass ich das Programm nicht richtig beende?

Die Tatsache, das der Port noch verwendet wird.

Was macht dich glauben, dass es was mit meiner Bedienung zu tun hat, obwohl es nur bei einer bestimmten app.config passiert?

inflames2k schrieb:

Das kann und will ich nicht glauben. Entweder du enthältst uns was vor oder die Fehlermeldung sieht anders aus, oder aber der Port wird wirklich verwendet.

Wie hast du geprüft, welche Anwendung den Port beansprucht um zu der Aussage "Keine." zu kommen?

netstat

Und zur Frage, ob du mir das glaubst: Warum wohl habe ich ein minimales, rekonstruierbares Beispiel erstellt? Probier es selbst aus. Mach es doch spaßenshalber einfach mal. Konsolenanwendung, Code einfügen und app.configs ausprobieren. Dann wirst du doch selbst sehen, dass das eine geht und das andere nicht. Dann brauchst du auch nicht darüber spekulieren, ob ich dir was vorenthalte.

inflames2k schrieb:

// EDIT:
Womöglich hilft dir aber das: Windows Service hosted WCF over HTTPS

Aussage von der Webseite:

I'm getting the error message that this question lists

Verlinkte Meldung:

The ChannelDispatcher at 'net.tcp://mysecreturl/' with contract(s) '"IClass"' is unable to open its IChannelListener.
System.InvalidOperationException: A registration already exists for URI 'net.tcp://mysecreturl/Indexer/'.

Ergo: Der Typ hat noch nicht mal dasselbe Problem wie ich, wie soll dieser Artikel also die Lösung für mich sein?

inflames2k

Irgendwie hat der bei mir auf der verlinkten Seite nen anderen Fehler als bei dir...

Service cannot be started. System.ServiceModel.AddressAlreadyInUseException: HTTP could not register URL https://+:54321/MyService/. Another application has already registered this URL with HTTP.SYS. ---> System.Net.HttpListenerException: Failed to listen on prefix 'https://+:54321/MyService/' because it conflicts with an existing registration on the machine.

Übrigens krieg ich dein Minimalbeispiel ohne Anpassungen meinerseits garnicht zum laufen.

geeky

Ich würds auf http://connect.microsoft.com/VisualStudio einfach mal als Bug melden und den Quellcode einer Minimal-Version davon direkt dort anhängen.

inflames2k

Nachdem ich das Binding etwas angepasst habe läuft es nun bei mir.
Meine beiden Konfigurationen mit minimal-Anpassungen z.B. wegen fehlens von Zertifikaten:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="Service.TestService" behaviorConfiguration="TestServiceBehavior">
        <endpoint address="" binding="basicHttpBinding" contract="Service.ITestService" bindingNamespace="TestService"/>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:4005/Design_Time_Addresses/DataService" />
          </baseAddresses>
        </host>
      </service>
    </services>

    <behaviors>
      <serviceBehaviors>
        <behavior name="TestServiceBehavior" >
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

und:

<configuration>
  <system.serviceModel>
    <services>
      <service name="Service.TestService" behaviorConfiguration="TestServiceBehavior">
        <endpoint
         address="https://localhost:4005/Design_Time_Addresses/DataService"
         binding="customBinding"
         contract="Service.ITestService"
         bindingConfiguration ="TestServiceBinding">
        </endpoint>
      </service>
    </services>

    <bindings>
      <customBinding>
        <binding name="TestServiceBinding">
          <textMessageEncoding messageVersion="Soap11" />
          <security
           defaultAlgorithmSuite="Basic128Rsa15"
           allowSerializedSigningTokenOnReply="true"
           authenticationMode="UserNameOverTransport"
           messageProtectionOrder="SignBeforeEncrypt"
           messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10"/>
          <httpsTransport maxBufferSize="5000000" maxReceivedMessageSize="5000000"/>
        </binding>
      </customBinding>
    </bindings>

    <behaviors>
        <serviceBehaviors>
          <behavior name="TestServiceBehavior">
            <serviceMetadata httpGetEnabled="false" />
            <serviceDebug includeExceptionDetailInFaults="true" />
          </behavior>
        </serviceBehaviors>
      </behaviors>
  </system.serviceModel>
</configuration>

Ich weis, Variante 1 weicht nun stark von deiner ab, aber sie funktioniert. Mit deiner ersten Variante konnte ich's beim besten Willen nicht ohne Exception ausführen. - Ich kann beide unabhängig von einander Problemlos starten.

inflames2k schrieb:

Übrigens krieg ich dein Minimalbeispiel ohne Anpassungen meinerseits garnicht zum laufen.

Auch als Fragesteller hab ich keine Glaskugel und kann zu "Geht nicht" nichts sagen.

Zu deinen app.config-Dateien: Na klar, du hast ja auch den Port geändert. Wenn ich einen anderen Port verwende als 8731 oder 8732, dann sagt er AccessDenied. Gib's zu, du hast es nicht als Nutzer mit beschränkten Rechten ausgeführt.

inflames2k

Definiere "Als Nutzer mit beschränkten Rechten"?

Der Witz ist, das ich ohne "Als Administrator ausführen" - garkeinen WCF-Service gestartet bekomme. Und das ist nicht nur auf Arbeit wo ich eingeschränkt bin so, sondern auch zu Haus auf meinem privat Notebook den Service ohne Administratorrechte nicht gestartet bekomme.

Die Portanpassung war Zufall und hat mit dem Problem nichts zu tun, ich machs aber auch gern nochmal mit deinen Config's.

Zu dem geht nicht: Das fängt schon beim fehlenden Zertifikat an.

- Zu dem als Administrator ausführen -

Mir ist klar, das ich mittels netsh den Port manuell an den Namespace binden kann. Aber das ist bescheuert. - Wieso hast du als Entwickler überhaupt nur eingeschränkte Rechte?!

Aber wie gesagt zu dem NETSH hilft dir ja der von mir vorhin gegebene Link... Denn er hat !!!genau!!! dein Problem.