none
Can't add service reference after tls 1.2 upgrade RRS feed

  • Question

  • Hello all,

    As the title might suggest, we recently upgraded to TLS 1.2 and now SOME of the dev machines can't add a service reference to that service.

    We've all tried with the exact same method.  New Console Application (full framework), targeted .NET 4.7, add service reference to our service -> bam, broke.

    Like I said though, this is a strange issue as it is only broken for some of the developers but not all.  Here is the error message we are getting:

    There was an error downloading 'https://[company url]/ServiceWeb.svc/$metadata'.
    The request failed with HTTP status 400: Bad Request.
    Metadata contains a reference that cannot be resolved: 'https://[company url]/ServiceWeb.svc'.
    Content Type application/soap+xml; charset=utf-8 was not supported by service https://[company url]/ServiceWeb.svc.  The client and service bindings may be mismatched.
    The remote server returned an error: (415) Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'..
    If the service is defined in the current solution, try building the solution and adding the service reference again.

    We've gone through registry keys, host file, installed certificates, and the credential manager with everything being identical yet it doesn't work for some.  Then, we had one developer add the service reference to a project, check it in, then had another dev (one who was having issues) get it from TFS and still couldn't perform an 'Update Service Reference'.  Something is clearly preventing these machines from being able to access the service but we aren't sure why.  Also, the devs that can't add the reference via Visual Studio CAN hit the WSDL from a browser.  We're at a loss here.

    Any insight/suggestions would be most appreciated.


    Oh, almost forgot.  We are running all latest patches for Windows and the .NET Framework.  These are Windows 7 machines if that matters.
    Thursday, February 15, 2018 9:12 PM

Answers

  • We are following the standard way to expose metadata.  At this point, I'm thinking it has to be something weird with the setup of our machines as some can and some can't access a service that hasn't changed.  It seems this issue isn't just restricted to our TLS 1.2 services.
    • Marked as answer by da.3vil.coder Thursday, February 22, 2018 10:47 PM
    Thursday, February 22, 2018 10:47 PM

All replies


  • We're discovered that other developers can bind to the service if they put in the ?wsdl after the service.  Which means that ?disco isn't working when they try and connect to the service.  Does anyone know why ?disco would not work for certain machines?
    Friday, February 16, 2018 7:52 PM
  • Hi da.3vil.coder,

    Do you mean the developers could add service reference by use "http://service address?wsdl"?

    In general, we use ?wsdl or/mex address to access service metadata.

    #How to: Publish Metadata for a Service Using a Configuration File

    https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-publish-metadata-for-a-service-using-a-configuration-file

    Best Regards,

    Tao Zhou


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, February 19, 2018 12:54 PM
  • Before we upgraded to TLS 1.2, any dev here could go to service 'Add Service Reference' and type in the address of a service on this server:

    https://serverAddress/service.svc

    After the upgrade, this only works for a few people.  We've discovered that the others have to enter:

    https://serverAddress/service.svc?wsdl

    This struck us as odd because this means that those machines are failing when the original address is entered.  When you add a reference (i'm going to use https://serverAddress/service.svc), what happens behind the scenes is that the following address is looked up:

    https://serverAddress/service.svc?disco

    Once that is found, it redirects to:

    https://serverAddress/service.svc?wsdl

    and then Visual Studio generates what it needs based on this.  Since the original address isn't working for some, that indicates that these machines are having an issue with:

    https://serverAddress/service.svc?disco

    We have also verified this by having them try and go directly to the ?disco endpoint.  Some can and some can't.  What would cause Visual Studio to not grab the wsdl from the original endpoint?  Why would certain machines only work when ?wsdl is appended to the end?


    Monday, February 19, 2018 3:50 PM
  • Hi da.3vil.coder,

    I think you need to follow standard way to expose service metadata which is using ?wsdl address.

    If you want to achieve exposing service metadata without using ?wsdl for your current issue, you could consider redirect the https://serverAddress/service.svc to https://serverAddress/service.svc?wsdl at service side by IIS feature or coding in WCF Service.

    Best Regards,

    Tao Zhou


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, February 22, 2018 3:05 AM
  • We are following the standard way to expose metadata.  At this point, I'm thinking it has to be something weird with the setup of our machines as some can and some can't access a service that hasn't changed.  It seems this issue isn't just restricted to our TLS 1.2 services.
    • Marked as answer by da.3vil.coder Thursday, February 22, 2018 10:47 PM
    Thursday, February 22, 2018 10:47 PM