Pregunta

Esta pregunta surge como resultado de esta pregunta , pero pensé que iba a dividir a cabo en su cuenta.

Cualquier cosa usando SPUtility.GetGenericSetupPath() está regresando null, por ejemplo.

SPUtility.GetGenericSetupPath("config")
SPUtility.GetGenericSetupPath(string.Empty)

tanto nula rentabilidad. Si hago esas llamadas en una pequeña aplicación de consola y depurarlo en VS2008, que aparece para ejecutar bien y sin excepciones (aunque con nula de volver del método.) Sin embargo noto un mensaje en la ventana de salida:

A primera excepción del tipo 'System.DllNotFoundException' producido en Microsoft.SharePoint.dll

Así que si consigo Visual Studio para romper en todas las excepciones, incluso manejados queridos, la excepción es la siguiente:

System.DllNotFoundException: No se puede cargar DLL 'onetnative.dll': El módulo especificado no se pudo encontrar. (Excepción de HRESULT: 0x8007007E)

He comprobado y onetnative.dll existe en C:. Files \ Archivos de programa \ Common \ Microsoft Shared \ Web servidor extensions \ 12 \ BIN

¿Fue útil?

Solución 2

Por lo que yo puedo rastrear de nuevo, esto fue causado por una instalación de la versión incorrecta de Microsoft J #.

J # es un requisito previo de la Interfaz Web para SharePoint webparts. He instalado la versión de 32 bits por error, entonces desinstalado e instalado la versión de 64 bits. Tengo el presentimiento (sobre la base de una buena parte de las pruebas, pero no al 100% verificado) que esto causó aplicaciones .NET / CLR para empezar a buscar en el nodo de 32 bits del registro en lugar de 64 bits.

Otros consejos

Me intente copiar el onetnative.dll al mismo lugar como su aplicación de consola y ver si se hace una diferencia

Licenciado bajo: CC-BY-SA con atribución
scroll top