2010-06-29 3 views
0

J'utilise le service WCF auto-hébergé (hébergé par programme) dans l'application Web. J'ai placé l'attribut [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] dans la classe SampleService et placé l'élément <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="false"/> dans la section Web.config system.serviceModel. Je suis mon hébergement WCF-service Global.asax dans la méthode Application_Start en utilisant le code suivant:Le service WCF auto-hébergé a HttpContext.Current == null malgré le fait que AspnetCompability a permis

protected void Application_Start(object sender, EventArgs e) 
{ 
    var serviceType = typeof (SampleService); 
    var serviceInterfaceType = typeof(ISampleService); 
    var baseAddresses = new Uri(@"https://localhost:443/SilverWIF.WEB/SampleService"); 
    var serviceHost = new ServiceHost(serviceType, baseAddresses); 
    var smb = serviceHost.Description.Behaviors.Find<ServiceMetadataBehavior>(); 
    if (smb == null) 
    { 
     smb = new ServiceMetadataBehavior { HttpsGetEnabled = true }; 
     serviceHost.Description.Behaviors.Add(smb); 
    } 
    else smb.HttpsGetEnabled = true; 

    var sdb = serviceHost.Description.Behaviors.Find<ServiceDebugBehavior>(); 
    if (sdb == null) 
    { 
     sdb = new ServiceDebugBehavior { IncludeExceptionDetailInFaults = true }; 
     serviceHost.Description.Behaviors.Add(sdb); 
    } 
    else sdb.IncludeExceptionDetailInFaults = true; 

    serviceHost.Description.Endpoints.Clear(); 
    serviceHost.AddServiceEndpoint(serviceInterfaceType, _getGustomBinding(), string.Empty); 

    serviceHost.Open(); 
} 

private static CustomBinding _getGustomBinding() 
{ 
    var binaryMessageEncodingBindingElement = new BinaryMessageEncodingBindingElement(); 
    var httpsTransportBindingElement = new HttpsTransportBindingElement(); 
    var binding = new CustomBinding(binaryMessageEncodingBindingElement, httpsTransportBindingElement); 
    return binding; 
} 

Malgré tout cela, je HttpContext.Current a == null (je suis en train d'y accéder à partir de l'un des Les méthodes de la classe SampleService).

Il est possible d'accéder à HttpContext.Current lorsque le service WCF est hébergé par programme? Quelqu'un peut il m'aider avec ce problème?

+0

Oui, un service WCF est ** NOT ** un service HTTP - votre HttpContext est censé être NULL, ce n'est pas la même chose, vraiment. De quoi avez-vous besoin à partir du HttpContext ?? –

+0

J'écris une application RP sécurisée par WIF, donc j'ai besoin d'obtenir l'identité de l'appelant (IClaimsPrincipal) dans CheckAccess mthod dans mon ClaimsAuthorizationManager. J'utilise les bibliothèques SL.IdentityModel et SL.IdentityModel.Server fournies dans WIF Training Toolkit pour fournir une autorisation sur le client Silverlight et essayer d'accéder à l'identité de l'utilisateur comme cela a été fait dans les exemples. J'ai lu beaucoup d'informations sur le service WCF et la différence de service Web et il semble que je ne puisse pas accéder à l'identité de l'appelant dans les services WCF comme je peux le faire dans les services Web. Mais, je ne comprends toujours pas comment je peux accéder à l'identité de l'utilisateur dans les services WCF – Ashald

+0

J'ai besoin de HttpContext.Current.User.Identity, dans lequel les services Web stockent l'identité de l'utilisateur. – Ashald

Répondre

0

Si votre site Web est hébergé dans IIS7, il y a eu une modification pour Integrated Pipeline qui rend le contexte de la demande indisponible dans l'événement Application_Start. Lors de l'utilisation du mode classique [NON RECOMMANDÉ] (le seul mode en cours d'exécution sur les versions précédentes d'IIS), le contexte de demande était disponible, même si l'événement Application_Start a toujours été conçu comme un événement global et indépendant de la requête. la durée de vie de l'application. La raison pour laquelle cela peut être fait (si cela doit être fait est une autre discussion) en mode IIS6 ou IIS7 Classic est que les applications ASP.NET étaient toujours démarrées par la première requête à l'application, il était donc possible d'accéder au contexte de requête via le static HttpContext.Current. L'explication ci-dessus mise à part, je ne recommanderais pas d'héberger votre service de cette manière dans un site Web. Jetez un oeil à ce lien pour l'hébergement au sein de IIS (How to implement a self-hosted service in a console application)

Espérons que cela aide.

+0

J'utilise "Classic .NET AppPool" car c'est le seul pool d'applications dans lequel je peux déboguer mon application Web. Peut-être, il ya un moyen par lequel je peux déboguer mon application Web dans le pool d'applications "ASP.NET v4.0", par exemple? Dans tous les cas, même je vais héberger mes services WCF dans l'application Windows Service ou Console, car je sais que je ne peux pas utiliser Pipeline AspNet pour mes services. Peut-être, il y a un moyen, dans lequel je peux accéder à l'information, qui est généralement stocké dans HttpContext.Curent.User.Identity en utilisant des classes/propriétés spécifiques au service WCF? – Ashald

Questions connexes