SPItemEventReceiver Context SiteId/WebUrl Incorrect

Question

I have created a SharePoint Event Receiver, that fires on Item Update. The receiver needs access AfterProperties and ListItem.

When firing the event receiver from a SharePoint web application using an IP address (http://10.0.4.50/sites/), it throws a FileNotFoundException, when accessing SiteId And WebUrl in SPItemEventProperties. The Web application at http://10.0.4.50/sites/companyName could not be found. Verify that you have typed the URL correctly.

When firing the event receiver using the hostname, specified at setup of Site Collection http://computerhostname/sites/companyName. This works fine, no exception is thrown.

//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

This isn't necessarily a SharePoint problem, but is most likely down to the way that IIS is configured on the host. A particular site can be "bound" to an IP address and a host name, and if the host name isn't present in the HTTP GET sent by the browser then IIS will return a 404 NOT FOUND.

You can verify this by using a browser to see whether you can access the site by IP address.

You can add additional bindings if necessary, but there can only be one "default" binding per IP address, so only one site can be present at (in your case) 10.0.4.50.

A possible way around the situation where multiple sites are present but you can't use a hostname might be to add a binding to a port other than port 80 for this IP, so your URL would become something like http://10.0.4.50:8080/sites/companyName.

Answer 2

This is not just an IIS problem, but Sharepoint related as well. A lot of referencing in SharePoint is done by using a url as a starting point (just look at the constructor of SPSite). The url is then compared to known url's in SharePoint's Config database. (and ofr files etc in the site's content database).

SharePoint uses a system called Alternate Access Mappings to assign different urls to a Web Application's "Zones" (default, intranet, internet, ... custom definition). If it does not find the 'exact' Url, internally stuff will fail (And especially search is very "Url sensitive").

Then comes the IIS part into play: Since IIS probably has no other site running on the 80 port, and without a specific hostheader (so it defaults to machinename), or with the hostheader set to the machine name, IIS will pick up the request and since SharePoint is tied into this webapp, SharePoint will try to process it, looks up the url, Sharepoint does not find the Url and thne "breaks".

The no hostheader occurs when you leave the hostheader field empty when you create a new web app in SharePoint.