Webservice funktioniert mit einer Konfiguration aber nicht mit der anderen

[Claudius]

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.

[Claudius]

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.

[Claudius]

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

[Claudius]

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.

[Claudius]

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.

[Claudius]

inflames2k schrieb:

Definiere "Als Nutzer mit beschränkten Rechten"?

Ein Benutzer in Windows 7, der kein Administrator ist.

inflames2k schrieb:

Der Witz ist, das ich ohne "Als Administrator ausführen" - garkeinen WCF-Service gestartet bekomme.

Merkwürdig. Bei mir geht es, zumindest mit der einen app.config.

inflames2k schrieb:

Die Portanpassung war Zufall und hat mit dem Problem nichts zu tun

Doch, hat es zum Teil. Denn nur dieser eine Port bringt überhaupt einen AlreadyInUse-Fehler. Alle anderen Ports bekommen direkt einen AccessDenied-Fehler, und zwar mit beiden app.configs.

inflames2k schrieb:

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

Ja, stimmt, das mit dem Zertifikat hätte ich rausnehmen sollen, da hast du recht.

inflames2k schrieb:

Mir ist klar, das ich mittels netsh den Port manuell an den Namespace binden kann. Aber das ist bescheuert.

Hab ich auch nicht gemacht. Ich hab nur nachgeguckt, welche Ports belegt sind und gesehen, dass der Port, den ich benutze, eben nicht schon von einem anderen Programm besetzt ist. Das ich mit netsh irgendwas einstelle, hab ich nirgendwo gesagt.

inflames2k schrieb:

Wieso hast du als Entwickler überhaupt nur eingeschränkte Rechte?!

Wieso sollte ich Administratorrechte haben, nur weil ich Entwickler bin?

inflames2k schrieb:

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

In dem Link steht:

Than check if HTTP listening is registered on that port by calling:

netsh http show urlacl

If so use following command to remove that registration:

netsh http delete urlacl url=http://+:54321/MyService

Und was habe ich bereits gesagt? Dass bei mir der Port nicht(!!!) bereits durch ein Programm belegt ist. Ich sehe in netsh keinen Eintrag, wo der Port benutzt wird, der mir durch Visual Studio als belegt angezeigt wird. Ansonsten würde es doch gar nicht funktionieren. Aber es funktioniert nur mit einer ganz bestimmten app.config nicht, mit der anderen schon. Wie oft soll ich das eigentlich noch erklären? Aber gut, bitte. Hier nochmal die Zusammenfassung:

Wir haben NICHT das Problem, dass der Port tatsächlich nachweislich durch ein anderes Programm belegt ist. Nirgendwo erscheint der Port aufgelistet, und sobald ich mein Programm mit der ersten app.config starte, funktioniert auch alles und er beschwert sich nicht mehr, dass der Port irgendwo belegt wäre.
Die Meldung, dass der Port belegt ist, kommt NUR wenn ich das Programm mit der zweiten app.config starte. Und der Fehler ist nicht mehr da, sobald ich die erste app.config nehme.
Irgendwelche Sachen mit netsh zu entfernen, dürfte nichts bringen, da die Portbelegung ja sowieso kein allgemeines Problem ist, sondern NUR auftritt, wenn ich eine ganz bestimmte app.config nehme und NICHT MEHR auftritt, wenn ich eine andere app.config nehme.

[inflames2k]

Mehr als versuchen, dir zu helfen kann ich nicht. Bei mir persönlich funktioniert es, wenn ich es als Administrator ausführe was für WCF völlig legitim ist.

Bzgl. warum du als Entwickler Administratorrechte haben solltest: Das fängt schon allein bei der Tatsache an, dass du Entwickler bist. Ich hab keine Ahnung was du bisher schon alles gemacht hast, aber es gibt einige Dinge die beim Entwickeln von Anwendungen zu Problemen führen können, wenn man die Rechte nicht hat.