2

WindowsサービスでホストされているWCFサービスがあり、net.tcpエンドポイントがあります。クライアントはサービスと同じLAN（ワークグループ）にありますが、サーバーのWindowsユーザーアカウントを持っていません。

PS：クライアントとサーバーの両方でSecurity.ModeをNoneに設定すると、次のエラーが発生します。

要求されたアップグレードは「{SERVICEADDRESS}」でサポートされていません。これは、バインディングの不一致が原因である可能性があります（たとえば、サーバーではなくクライアントでセキュリティが有効になっている）。

4

4 に答える 4

3

Nettcpバインディングはデフォルトで安全です。すべてのメッセージは、tcpを介して署名および暗号化されるため、クライアントはWindowsクレデンシャルを提供する必要があります。noneに設定すると、おそらく問題が発生します。次のようなものが必要になります。

<netTcpBinding>
     <binding name="netTcp">
       <security mode="Transport">
         <transport clientCredentialType="Windows" />
       </security>
     </binding>
</netTcpBinding>
于 2010-07-01T17:59:10.967 に答える
1

問題は解決しました。

なぜこうなったのかはわかりませんが、サーバーのフォルダ オプションで「簡易ファイル共有を使用する」のチェックを外せば、問題なく動作します。

于 2010-07-03T06:20:29.910 に答える
0

上記の解決策のいずれかがうまくいかない場合は、以下に示すように、エンドポイントから ID を削除してみてください。

<endpoint address="net.tcp://127.0.0.1/FacilitySchedulesService/FacilitySchedulesService.svc"
                binding="netTcpBinding" bindingConfiguration="FacilityScheduleDSTCP"
                contract="FacilitySchedules.IFacilitySchedulesService" name="FacilityScheduleDSTCP">
        <!--<identity>
          <userPrincipalName value="abc" />
        </identity>-->
      </endpoint>
于 2016-05-16T11:39:46.297 に答える
0

私は自己ホスト型の net.tcp サービスを使用しており、セキュリティの有無にかかわらず正常に動作します。実際、同じポートで複数の安全な net.tcp コントラクトをホストできるため、ファイアウォールのセットアップが簡単になります。

Simple File Sharing をオフにすることでクライアント/サービスが機能するようになった場合、サービスをホストするために選択したポートが Simple File Sharing でも使用されていた可能性があります。

于 2015-08-22T16:26:28.837 に答える