Actualización: An anonymous poster left a great comment about internal names. Be sure to read it.

Ao traballar con receptores de eventos e outros códigos que referencias SharePoint elementos de lista a través do modelo de obxecto, Eu moitas veces cometen erros que xeran este erro en tempo de execución:

Erro Conchango.xyzzyEventReceiver receptor cargar e executar eventos xyzzy, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 0dc50a750396c3ac. Additional information is below. : Value does not fall within the expected range.

I think this is a fairly generic error that is potentially caused many different ways. Con todo, one simple explanation is that I’m referencing a field incorrectly. If the name of the field is "Due Date", Debo referencia-como este en un receptor de eventos:

properties.ListItem["Data de caducidade"]

Cando cometer erros ou utilizar o caso mal ao facer referencia ao campo, SharePoint generates the above mentioned runtime error. Por exemplo, iso é malo:

properties.ListItem["Data de caducidade"]

</final>

Rexístrate para o meu blog.

Co fin de evitar un problema KPI Eu escribín sobre aquí, I did some testing and discovered that KPI’s work against folders with meta data in the same way that they work against documents or list items. I proved it out by creating a new content type based on the folder content type and then added a few fields. I created some indicators and proved to myself that KPIs work as expected. This was welcome news. It’s not perfect, because the drill-down you get from the KPI against the folders is not exactly what you want. This isn’t too much a drawback in my case because 1) os usuarios finais non saben de nada e 2) the drill-down goes to a folder. They click the folder name and they are at the item. It’s two clicks instead of one, o que non é o fin do mundo.

This flowed nicely with the work I was doing. I am creating a folder for every document that gets uploaded. This is done via an event receiver. Como resultado, é unha peza de bolo para manter o pai do cartafol meta data in sync with the KPI-driven meta data from the file itself since the plumbing is already in place. This allows me to have my KPI’s and eat them too 🙂

I modified the event receiver to add the folder and then set this new folder’s content type to my custom KPI-friendly content type. This bit of code did the trick:

 SPFolderCollection srcFolders = targetWeb.GetFolder("Documents").SubFolders;
  SPFolder addedFolder = srcFolders.Add(properties.ListItem.ID.ToString());

  SPContentTypeId kpiCT = novo SPContentTypeId("0x0120002A666CAA9176DC4AA8CBAA9DC6B4039F");
  addedFolder.Item["Content Type ID"] = KpiCT;
  addedFolder.Item.Update();

Para atopar o real Content Type ID, Eu acessei este tipo de contidos a través de configuración do sitio web e copiar / pegar lo da URL, como se mostra:

</final>

Rexístrate para o meu blog!

Eu odio admitir iso, but I struggled with this one all day. My event receiver needs to update a field of its parent folder. This little bit shows how to do it:

privado invalidar UpdateParentFolder(SPItemEventProperties Propiedades)
{

SPFolder thisItemFolder = properties.ListItem.File.ParentFolder;
thisItemFolder.Item["ZZ Approval Status"] = "Good news, todos!";
thisItemFolder.Item.Update();


} // UpdateParentFolder

Neste caso, Estou traballando con unha biblioteca de documentos e as propiedades proveñen dun evento ItemAdded.

O truco é que non se pode obter o SPFolder do elemento directamente do elemento en si (i.e. properties.ListItem.Folder é nulo). Pola, ir ao ficheiro asociado do elemento da lista e obter o cartafol do ficheiro.

</final>

Rexístrate para o meu blog!

I’m sure I’m not the first person to come up with this. Con todo, I haven’t noticed anyone publish a trick like this since I started paying close attention to the community last July. Así, Eu penso que eu ía publicar esta información de depuración rápido e sinxelo.

Estou traballando nun receptor de eventos que comezou a xerar ese erro 12 colmea:

Erro Conchango.xyzzyEventReceiver receptor cargar e executar eventos xyzzy, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = blahbalhbalh. Additional information is below. : Referencia de obxecto non está definida para unha instancia dun obxecto.

I didn’t know where I had introduced this bug because I had done too many things in one of my code/deploy/test cycles.

Tente esta solución para obter o meu PDB alí coa esperanza de que o SharePoint 12 colmea ía amosar o seguimento de pila, but no luck. I don’t know if it’s possible and if someone does, por favor me aviso 🙂

Sei que é posible escribir as súas propias mensaxes de rexistro ao 12 colmea. Frankly, Eu quería algo un pouco menos asustado e máis rápido para aplicar.

Houbo-me que eu podería polo menos ter unha información básica de seguimento, captura e re-lanzar excepcións xenéricas como esta:

  intentar {
    UpdateEditionDate(Propiedades);
  }
  incorporarse (Excepción e)
  {
    xogar novo Excepción("Dispatcher, UpdateEditionDate(): Excepción: [" + e.ToString() + "].");
  }

Este mostrou-se no 12 colmea deste xeito:

Erro Conchango.xyzzyEventReceiver receptor cargar e executar eventos xyzzy, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = blahblahblah. Additional information is below. : Expedidor, UpdateEditionDate(): Excepción: [System.NullReferenceException: Referencia de obxecto non está definida para unha instancia dun obxecto. at Conchango.xyzzyManagementEventReceiver.UpdateEditionDate(Propiedades SPItemEventProperties) at Conchango.xyzzyManagementEventReceiver.Dispatcher(Propiedades SPItemEventProperties, EventDescription cadea)].

Iso me deu todos os detalles que eu precisaba para rastrexar este problema específico e esperamos usalo moito de aquí para diante.

</final>

Rexístrate para o meu blog!