locked
Provider type not defined WCF error RRS feed

  • Question

  • Hi guys, not much help for this error out there. I have a WCF service hosted in IIS over SSL. In the service I am using Transport security.
    <security mode="Transport">
     <transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
     <message clientCredentialType="UserName" algorithmSuite="Default" />
    </security>
    

    For the sake of argument I have 3 methods. A 'Hello World' (guess what that returns!), a method that writes to a file on the server with 'Everyone' having full access and a method that interrogates the SharePoint Object Model. It's a SharePoint web application I'm hosting it in. I have the RequirementsMode:=Activation.AspNetCompatibilityRequirementsMode.Required decoration on my service class for this purpose, in case this is relevant.
     
    For each method I am getting the following results:

    HelloWorld: returns "Hello World" as expected.
    WriteFile: Returns "System.Runtime.InteropServices.COMException: Provider type not defined. (Exception from HRESULT: 0x80090017)

    SPQuery: returns "System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Could not load file or assembly 'Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Either a required impersonation level was not provided, or the provided impersonation level is invalid
     
    I am using a console application to query/test the service. My windows credentials should be enough to perform the actions above. Even when I build a credential set by using serviceInstance.ClientCredentials.Windows.ClientCredential = New NetworkCredential("admin", "adminpassword", "sharepoint") with the admin credentials I get the same error, and if I use ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation It brings back "Access Is Denied" for the second method (same error for the last one). What makes it more annoying is I can't see exactly what's going on cos I can't enable tracing (see my other thread http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/690b86c2-6462-44a1-bb1e-a0ddf6a4dc83/ for the hardcore among you).
    Sorry it's such a long post but I'm just trying to preempt the obvious responses.
    Does anyone pleeeease have any ideas what I'm doing wrong?!
    Cheers, Mike



    Thursday, August 4, 2011 12:53 PM

Answers

  • Ahah, figured it out! I had my DLL for the service in the bin folder, somehow it wasn't passing credentials through in here so I put the DLL in the GAC which lets face it is where it should be anyway. Doing this, then assigning

    Dim gs As New GenServiceNew.GenServiceClient
    gs.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation

     (or assigning your specified network credentials using the NetworkCredential class) my windows credentials were then passed to the service. So the 'provider type not defined' error I guess was because there was no user token being found while in the bin folder, and the 'Access is Denied' error was because there weren't enough privileges on the code (probably due to some settings at the root-level web.config).

    Hope this is helpful to anyone else having the same problem.

    Mike.


    • Marked as answer by Yi-Lun Luo Tuesday, August 9, 2011 2:40 AM
    Monday, August 8, 2011 11:08 AM

All replies

  • Hello, if you host the service in a normal IIS site instead of SharePoint (remove the SharePoint integration part), does it work fine? If this scenario works fine, it may be a SharePoint issue... You can ask SharePoint development questions on http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010programming/threads.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    Friday, August 5, 2011 1:56 AM
  • Here's the thing, I have an identical service hosted on a development machine that is not SSL enabled and all methods work fine. With that one I am using TransportCredentialOnly security mode. I cannot use this mode with the live server with SSL enabled.

    I struggle to see how this would be a SharePoint issue, at the end of the day a web application in IIS is just a web application, it's only when you start querying the SharePoint object model within the code that you start distinguishing the type of service it is. If this is the case, why does the write file method fail? The destination folder has full access to 'everyone', which leads me to believe the credentials are not being passed through. Also, it defeats the object putting the service on another server that doesn't have SharePoint enabled as all of the methods will be there querying SharePoint.

    A bit more info, in the folder the service is hosted from I have Anonymous, ASP.NET impersonation and Windows authentication enabled, if that helps.

    Greatly appreciate your help and input on this.

    Many thanks, Mike.

    Monday, August 8, 2011 8:46 AM
  • Ahah, figured it out! I had my DLL for the service in the bin folder, somehow it wasn't passing credentials through in here so I put the DLL in the GAC which lets face it is where it should be anyway. Doing this, then assigning

    Dim gs As New GenServiceNew.GenServiceClient
    gs.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation

     (or assigning your specified network credentials using the NetworkCredential class) my windows credentials were then passed to the service. So the 'provider type not defined' error I guess was because there was no user token being found while in the bin folder, and the 'Access is Denied' error was because there weren't enough privileges on the code (probably due to some settings at the root-level web.config).

    Hope this is helpful to anyone else having the same problem.

    Mike.


    • Marked as answer by Yi-Lun Luo Tuesday, August 9, 2011 2:40 AM
    Monday, August 8, 2011 11:08 AM