FileNotFoundException avec le constructeur SPSite
https://stackoverflow.com/questions/266255
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'essaie d'instancier une instance de SPSite sur le serveur de la batterie de serveurs dans un processus personnalisé (MyApp.exe) et lui donne comme paramètre l'URI entier ( http: // mysite: 80 / ). Je me suis également assuré que le compte exécutant MyApp.exe est Administrateur de la collection de sites .
Cependant, je ne peux pas créer d'instance de SPSite quoi que j'essaye de faire. Il génère toujours une FileNotFoundException .
Quelqu'un a une idée?
StackTrace:
à Microsoft.SharePoint.SPSite..ctor (SPFarm ferme, Uri requestUri, Boolean contextSite, SPUserToken userToken)
à Microsoft.SharePoint.SPSite..ctor (String requestUrl) à MyCompanyName.Service.HelperClass.GetItemStateInSharePoint (SharePointItem article) dans C: \ Espaces de travail \ MonSociété \ Développement \ Principal \ MonSociété.SharePoint \ Service \ HelperClass.cs: line 555
Autre note en bas de page ... J'ai une collection d'applications Web + sites à laquelle je peux accéder sans problème via le navigateur.
La solution
L'exception FileNotFoundException est levée par SharePoint lorsqu'il ne parvient pas à trouver la collection de sites demandée dans la base de données de configuration SharePoint. Mon hypothèse est que vous n'avez pas encore créé de collection de sites sur l'URL http: // mysite: 80 . Je vois la trace de pile suivante si j'essaie d'instancier un nouvel objet SPSite avec l'URL d'une collection de sites non existante:
System.IO.FileNotFoundException : The site http://server/sites/bah could not be found in the Web application SPWebApplication
Name=SharePoint - 80 Parent=SPWebService.
at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)
at Microsoft.SharePoint.SPSite..ctor(String requestUrl)
Spécifiez l'URL appropriée de votre collection de sites ou ouvrez l'Administration centrale et créez une nouvelle collection de sites.
Autres conseils
La modification de la cible de la plate-forme dans les propriétés de construction en x64 a résolu ce problème pour moi sous SharePoint 2010.
Lisez ce site http://community.bamboosolutions.com/forums/t/ 8179.aspx si vous utilisez votre système d'exploitation x64 bit et utilisez MSTest (32 bits), il échouera, utilisez nunit works !!!
S'il s'agit d'une application console accédant à SharePoint 2010, assurez-vous que la cible de génération de votre projet est x64 et que le .NET Framework est 3.5.
Ce problème concerne davantage le problème des autorisations des utilisateurs. Donnez l’autorisation suivante
Permission d'utilisateur Site SharePoint : autorisation de lecture minimale
Serveur Sharepoint --- Ajouter au groupe WSS_ADMIN_WPG
Base de données --- Base de données de contenu Sharepoint (base de données de la collection de sites): autorisation associée à db_owner Sharepoint Config DB (Base de données de configuration de l'installation SharePoint) - - Autorisation db_owner
Lire la suite sur mon blog
http://sharepointinstallation.blogspot.com/ 2010/12 / minimal-permission-required-to-execute.html
Il est également possible que le modèle d'objet n'aime pas l'URL que vous lui donnez. Si vous ne le communiquez pas avec l'URL exacte à laquelle vous avez créé la collection de sites ou si une URL exacte répertoriée dans votre est configurée dans vos mappages des accès de substitution, cela générera une exception qui n'a peut-être pas de sens. Dans votre cas, vous pouvez essayer http: // mon_site ou http: // nom_ordinateur .
Le trait de pile de l'exception serait utile.
Je pense que vous pouvez éventuellement avoir une idée de quel fichier il s’agit et de ce qui se passe en désactivant "juste mon code". dans les outils - > options - > déboguer et examiner l'argument filename dans la pile d'appels de l'exception lorsque le débogueur l'affiche (si vous pouvez le déboguer bien sûr), ou peut-être que le nom apparaît dans le message d'exception.
Vérifiez votre web.config et voyez s’il existe une configuration avec un fichier manquant.
Cherchez dans votre ruche 12 le journal. Si vos paramètres de journal sont corrects, vous obtiendrez le fichier manquant.
EDIT: Vérifiez également si TOUTES vos DLL sont dans le GAC. Vérifiez si votre fichier web.config contient toutes les informations: espace de noms, nom de classe, espace de noms, version = version_number, culture-culture_votre, PublicKeyToken = votre_scrit_signé
J'ai récemment découvert que ce problème de constructeur peut être provoqué par le comportement de starnge du constructeur.
Je parle de MOSS 2007.
Lorsque vous transmettez l'URL complète du site au constructeur, il semble ne prendre en compte que la partie site de l'URL, en choisissant l'application Web actuellement sélectionnée dans le contrôle de sélecteur d'applications Web.
Ainsi, par exemple, lorsque vous avez http: // webapp / sites / site " et ont " http: // weabapp: 22345 " actuellement sélectionné (la dernière fois que vous l'avez sélectionné dans un tel sélecteur) lorsque vous appelez
SPSite site = new SPSite("http://webapp/sites/site")
Il tente de créer un objet de site pour &
J'ai eu le même problème. Je voulais exécuter une application console avec mon identifiant utilisateur. Je suis propriétaire de l'application Web + administrateur de la ferme. N'a toujours pas pu exécuter l'application.
Le problème a été résolu par
.-
Modification de la cible de la plate-forme dans les propriétés de construction en x64
-
Dans les paramètres du site - > Utilisateurs et autorisations - > Administrateurs de collections de sites, il y avait deux noms. Supprimé autre nom et il a commencé à fonctionner.
Vous pouvez conserver la cible de compilation du projet sur "Tout processeur". L'important est de configurer le processus hôte MSTest pour qu'il s'exécute à 64 bits. Ouvrez votre fichier .testsettings, accédez à l'onglet Hôtes et définissez l'option "Exécuter les tests en 64 bits ..."
.Si après cela, lorsque vous exécutez vos tests, VS vous dit qu'il n'y en a pas, supprimez et ajoutez votre projet de test à nouveau (je ne connais pas de meilleure solution pour cela)
J'espère que ça aide!
Nous avions le même problème, mais je connais les différentes causes, voici un résumé:
- Vous avez peut-être mal saisi ou saisi une adresse incorrecte
- Le compte d'utilisateur exécutant le processus ne dispose pas des autorisations requises, à savoir: autorisation de lecture sur le site SharePoint, dbo de la base de données SharePoint Config et base de données.
- Le processus doit être un processus 64 bits (la valeur par défaut est 64 bits "Tous les processeurs") lors de la création sur un serveur 64 bits.
- Le processus doit être ciblé sur .NET 3.5
J'en ai été victime il y a quelques semaines. En fin de compte, j'ai découvert que le fichier introuvable était l'assembly SharePoint lui-même. Le moteur d'exécution ne parvenait pas à charger l'assemblage satellite via une liaison tardive.
La solution à mon problème consistait à enregistrer les assemblys SharePoint 12.0.0.0 dans le GAC. Cela ne semble pas être la même chose que votre problème, mais juste pour votre information.
Nous avons rencontré le même problème il y a quelques jours. La solution consistait à configurer l'application, qui tente de créer un objet SPSite, d'utiliser le même AppPool que l'application Web de Sharepoint.
J'espère que ça aide.
Le problème MSTest sur x64 a été la cause de ce problème pour moi. Fonctionne dans une application console.
J'ai le même type de problème.
Dans mon scénario, j'ai pu créer l'instance de SPSite à partir d'une application console, mais lorsqu'un autre coéquipier a tenté de le faire, l'application a lancé la même exception que celle mentionnée ci-dessus.
Solution: J'ai ajouté l'autre coéquipier en tant qu'administrateur sur la boîte du serveur Content Db (cela peut ne pas être possible pour tout le monde), le code fonctionne correctement et aucune erreur
Même problème sur SharePoint 2010. Cependant, le problème venait de notre service Web qui accédait au modèle d'objet SharePoint. Le pool d'applications sous lequel ce service doit être exécuté doit être un administrateur de batterie.
Passer à NUnit n'est peut-être pas une option pour tout le monde.
Dans mon cas, le problème était que j'étais sur un serveur 64 bits. Tous les processeurs avaient été vérifiés (il s'agissait donc de choisir la version correcte), mais mes paramètres de test étaient configurés pour "Forcer l'exécution des tests dans un processus 32 bits". (GAH!)
Dans MSTest, accédez à TEst- > Modifier les paramètres de test- > Tracer et tester l'impact.
Choisissez des hôtes.
Assurez-vous que vous utilisez la version correcte.
Voici ma liste de contrôle pour VS2010 SP1, MSTest.
- Vous avez besoin du SP1 pour pouvoir cibler les tests sur .NET 3.5. Cela ne fonctionnera pas avec .NET 4.0
- Assurez-vous que le site se charge - j'ai lancé le site directement à partir de l'éditeur VS2010, car il s'agit d'un lien hypertexte
- Vérifiez les paramètres de construction. Pour choisir 64 bits si le serveur est 64 bits.
- Dans mon cas, j'avais un serveur 64 bits, mais le choix de x64 échouerait! C'était mon premier indice.
- Vérifiez que les paramètres de test prennent en charge les bits corrects.
J'ai eu le même problème en essayant d'accéder à Sharepoint 2010.
Je l'ai corrigé en modifiant le cadre cible en .NET 3.5.-, qui est la version prise en charge pour Sharepoint 2010.
Dans mon cas, il s'agissait certainement d'un problème d'autorisations avec le compte avec lequel j'avais ouvert une session.
Essayez cette commande dans SharePoint Management Shell exécuté en tant qu'administrateur:
Get-SPSite ' http: // votre site / votre collection '
Si vous rencontrez des erreurs, connectez-vous au serveur SharePoint en tant qu'utilisateur du pool d'applications ou compte utilisé pour installer SharePoint, puis relancez la commande ci-dessus.
Si cela fonctionne, vous savez que votre compte précédent a un problème d'autorisations. Pour résoudre le problème, exécutez cette commande dans la même fenêtre de shell et indiquez le compte que vous souhaitez utiliser dans VS:
Add-SPShellAdmin -UserName Domain \ User
J'ai eu le même problème, j'ai apporté les modifications ci-dessous et cela a commencé à fonctionner.
- Modification de la cible de la plate-forme dans Visual Studio en x64
- assurez-vous que vous utilisez Visual Studio dans "Administrateur". mode.
