SPITEMEVENTRECEIVER CONTEXT SITEID/WEBURL INCORRETO

Question

Eu criei um receptor de eventos do SharePoint, que dispara na atualização do item. O receptor precisa de acesso AfterProperties e ListItem.

Ao disparar o receptor de evento de um aplicativo da Web do SharePoint usando um endereço IP (http://10.0.4.50/sites/), ele joga um FilenotfoundException, ao acessar o SiteID e o weburl no SpiTemEventProperties.O aplicativo da web em http://10.0.4.50/sites/companyname Não pode ser achado. Verifique se você digitou o URL corretamente.

Ao disparar o receptor do evento usando o nome do host, especificado na configuração da coleção de sites http: // computherHostName/sites/CompanyName. Isso funciona bem, nenhuma exceção é lançada.

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

Isso não é necessariamente um problema do SharePoint, mas provavelmente se deve à maneira como o IIS está configurado no host. Um site específico pode estar "ligado" a um endereço IP e um nome de host, e se o nome do host não estiver presente no http ser enviado pelo navegador, o IIS retornará um 404 NOT FOUND.

Você pode verificar isso usando um navegador para ver se você pode acessar o site por endereço IP.

Você pode adicionar ligações adicionais, se necessário, mas pode haver apenas uma ligação "padrão" por endereço IP, para que apenas um site possa estar presente em (no seu caso) 10.0.4.50.

Uma maneira possível de contornar a situação em que vários sites estão presentes, mas você não pode usar um nome de host pode ser adicionar uma ligação a uma porta que não seja a porta 80 para este IP, para que seu URL se tornasse algo como http://10.0.4.50:8080/sites/companyName.

Answer 2

Este não é apenas um problema do IIS, mas também relacionado ao SharePoint. Muita referência no SharePoint é feita usando um URL como ponto de partida (basta olhar para o construtor do spsite). O URL é então comparado aos URLs conhecidos no banco de dados de configuração do SharePoint. (e arquivos OFR etc no banco de dados de conteúdo do site).

O SharePoint usa um sistema chamado mapeamentos de acesso alternativo para atribuir diferentes URLs às "zonas" de um aplicativo da web (padrão, intranet, internet, ... definição personalizada). Se não encontrar o URL "exato", as coisas internas falharão (e especialmente a pesquisa é muito "sensível ao URL").

Depois, vem a parte do IIS em jogo: como provavelmente não tem outro site em execução na porta 80 e sem um hósteade específico (por isso, o padrão é o nome do maquiné), ou com o conjunto de Hostheader para o nome da máquina, o IIS pegará a solicitação E como o SharePoint está vinculado a este webApp, o SharePoint tentará processá -lo, procurar o URL, o SharePoint não encontra o URL e o Thne "Breaks".

O não -hostheader ocorre quando você deixa o campo Hostheader vazio quando você cria um novo aplicativo na Web no SharePoint.