SPItemEventReceiver Contexte SiteId / WebUrl incorrect

Question

J'ai créé un SharePoint récepteur d'événements, qui se déclenche sur le Point de mise à jour. Le récepteur a besoin AfterProperties d'accès et ListItem.

Lors du déclenchement du récepteur d'événements à partir d'une application Web SharePoint en utilisant une adresse IP ( http://10.0.4.50/sites / ), il jette un FileNotFoundException , lors de l'accès SiteId Et WebUrl dans SPItemEventProperties. L'application Web à l'adresse http://10.0.4.50/sites/companyName n'a pas pu être trouvé . Vérifiez que vous avez tapé l'URL correctement.

Lors du déclenchement du récepteur d'événements en utilisant le nom d'hôte, lors de la configuration spécifiée de la collection du site http: // computerhostname / sites / companyName . Cela fonctionne bien, sans exception est levée.

//Combine Both AfterProperties And ListItem
var ListProperties = new List<KeyValuePair<string, object>>();
ListProperties.AddRange(properties.AfterProperties.ToKeyValue());
ListProperties.AddRange(properties.ListItem.ToKeyValue(p => !p.Sealed));
var AvaliableProperties = ListProperties.Distinct(new KeyValueComparer<object>());

Answer 1

Ce n'est pas nécessairement un problème de SharePoint, mais il est plus probable vers le bas à la façon dont IIS est configuré sur l'hôte. Un site particulier peut être « lié » à une adresse IP et un nom d'hôte, et si le nom d'hôte n'est pas présent dans le HTTP GET envoyé par le navigateur puis IIS renverra un 404 NOT FOUND.

Vous pouvez vérifier cela en utilisant un navigateur pour voir si vous pouvez accéder au site par adresse IP.

Vous pouvez ajouter des liaisons supplémentaires si nécessaire, mais il ne peut être qu'un « défaut » obligatoire par adresse IP, de sorte qu'un seul site peut être présent à (dans votre cas) 10.0.4.50.

Une façon possible autour de la situation où plusieurs sites sont présents mais vous ne pouvez pas utiliser un nom d'hôte pourrait être d'ajouter une liaison à un autre port que le port 80 pour cette adresse IP, de sorte que votre URL deviendrait quelque chose comme http://10.0.4.50:8080/sites/companyName.

Answer 2

Ce n'est pas seulement un problème d'IIS, mais Sharepoint lié aussi bien. Beaucoup de référencement dans SharePoint est fait en utilisant une URL comme point de départ (il suffit de regarder au constructeur de SPSite). L'URL est alors comparé à url connus dans la base de données de configuration de SharePoint. (Et les fichiers OFR etc dans la base de données de contenu du site).

SharePoint utilise un système appelé Mappages des accès à attribuer des urls à un Web "zones" de l'application (par défaut, intranet, internet, ... définition personnalisée). Si elle ne trouve pas la « exacte » Url, en interne des choses échouera (et en particulier la recherche est très « sensible Url »).

Vient ensuite la partie IIS en jeu: Étant donné que IIS n'a probablement aucun autre site en cours d'exécution sur le port 80, et sans HostHeader spécifique (il par défaut MACHINENAME), ou avec le HostHeader réglé sur le nom de la machine, IIS choisira la demande et depuis SharePoint est liée à cette webapp, SharePoint va essayer de le traiter, lève les yeux vers l'URL, Sharepoint ne trouve pas l'URL et thne « pauses ».

Le pas HostHeader se produit lorsque vous laissez le champ vide HostHeader lorsque vous créez une nouvelle application Web dans SharePoint.