Impossible de charger le fichier, l'assembly ou l'une de ses dépendances. L'accès est refusé. Le problème est aléatoire, mais après une fois, il continue
J'ai trouvé de nombreuses informations sur cette erreur: 'ERREUR: impossible de charger le fichier ou l'assembly' * .dll 'ou l'une de ses dépendances. L'accès est refusé. ' Mais je n'ai pas trouvé de réponse spécifique à mon scénario. Mon site est déployé sur 6 serveurs de production différents, mais sur un seul serveur auquel je suis confronté. Le problème est aléatoire, mais après que cela se produise une fois, il continue jusqu'à ce que le site soit recompilé en faisant une petite modification dans le fichier web.config (je sais, après la modification dans l'application Web.config recompiler l'application Web) et le site sur ce serveur de travail . Hier, le problème se reproduisait après un mois de travail ... .. Nous ne pouvons nous permettre ce problème pour la production.
Détail du problème:
Erreur serveur dans l'application.__________________________________ Impossible de charger le fichier ou l'assembly 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. L'accès est refusé. Description: une exception non gérée s'est produite lors de l'exécution de la demande Web en cours. Consultez la trace de la pile pour plus d’informations sur l’erreur et son origine dans le code.
Détails des exceptions: System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'MainCore.DbImpl, version = 0.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. L'accès est refusé.
Erreur source: Une exception non gérée a été générée lors de l'exécution de la requête Web en cours. Les informations concernant l'origine et l'emplacement de l'exception peuvent être identifiées à l'aide de la trace de pile d'exceptions ci-dessous.
Suivi de la charge d'assemblage: Les informations suivantes peuvent être utiles pour déterminer pourquoi le composant 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutre, PublicKeyToken = null' n'a pas pu être chargé.
WRN: la journalisation de la liaison d'assemblage est désactivée . Pour activer la journalisation des erreurs d'assemblage avec Assembly, définissez la valeur de registre [HKLM\Software\Microsoft\Fusion! EnableLog] (DWORD) sur 1 . Remarque: La journalisation des échecs de liaison avec l'assemblage entraîne une baisse des performances .____. Pour désactiver cette fonctionnalité, supprimez la valeur de registre [HKLM\Software\Microsoft\Fusion! EnableLog].
Trace de la pile:
[FileLoadException: impossible de charger le fichier ou l'assembly 'MainCore.DbImpl, Version = 0.0.0.0, Culture = neutre, PublicKeyToken = null' ou l'une de ses dépendances. L'accès est refusé.] ... DbImpl.Event.TTCEventController.GetEventFields (Int32 eventId) +0 WebSuite.SportChannel.ModelImpl.TTCModelController.AddEventFieldList (XmlElement eventNode, ITTCEventController ctrl, IntI eventId, PlayerType stupidType) dans ... racine\SportChannel\ModelImpl\Ttc\TTCModelController. ... ModelImpl.TTCModelController.GetLatestFourTourSchedulesXml () in ... root\SportChannel\ModelImpl\Ttc\TTCModelController.cs: 283 ... WebRoot.UserControls.HeadlinesTab.Page_Load (Expéditeur d'objet, EventArgs e) +491 System.Web.Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Objet o, Objet t, EventArgs e) +25 System.Web.Util.CalliEventHandlerDelegateProxy.Callback (Expéditeur d'objet, EventArgs e) +42 System.EventHandler.Invoke (Expéditeur d'objet, EventArgs e) +0 System.Web.UI.Control.OnLoad (EventArgs e) +132 System.Web.UI.Control.LoadRecursive () +66 System.Web.UI.Control.LoadRecursive () +191 System.Web.UI.Control.LoadRecursive () +191 System.Web.UI.Page.ProcessRequestMain (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2428
__________________________________Informations de version: Microsoft .NET Framework Version: 2.0.50727.5446; Version ASP.NET: 2.0.50727.5420
Ma solution est la suivante:
Je n'ai pas trouvé de dossier root sous C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files.
Google m'a dit qu'il pourrait s'agir d'un problème de permission vis-à-vis de l'utilisateur actuel, puis j'ai découvert que j'ai une identité actuelle: IIS APPPOOL sur le serveur défaillant, le reste du serveur ayant l'identité actuelle: NT AUTHORITY\NETWORK SERVICE.
Ensuite, j'ai changé l'identité actuelle de IIS APPPOOL à NT AUTHORITY\NETWORK SERVICE.
À partir de là, j'ai constaté que la réinitialisation de l'application Web reconstitue le cache temporaire ASP.NET, ce qui résout le problème.
Pour mon scénario, j'ai trouvé qu'il y avait un nœud d'identité dans le fichier web.config.
<identity impersonate="true" userName="blah" password="blah">
Lorsque j'ai supprimé les paramètres userName et password du noeud, cela a commencé à fonctionner.
Une autre option consiste à vous assurer que le nom d'utilisateur spécifié a le droit de travailler avec les dossiers "Fichiers ASP.NET temporaires" trouvés dans les différents dossiers C:\Windows\Microsoft.NET\Framework {version}.
En espérant que cela aide quelqu'un d'autre à sortir!
Avait le même problème, résolu avec la définition du paramètre "Activer les applications 32 bits" à "true" (dans les paramètres avancés du pool d'applications IIS).
À tous ceux qui ont essayé la plupart des solutions et qui rencontrent encore des problèmes.
Ma solution est différente des autres, qui se trouvent au bas de ce post, mais avant de l'essayer, assurez-vous d'avoir épuisé les listes suivantes. Pour être sûr, je les ai tous essayés mais en vain.
Recompiler et redéployer à partir de zéro, ne mettez pas à jour l'application existante. SO Réponse
Accordez à IIS_IUSRS un accès complet au répertoire "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires"
Gardez à l'esprit la version du framework que vous utilisez. Si votre application utilise l'emprunt d'identité, utilisez cette identité au lieu de IIS_IUSRS.
Supprimez tout le contenu du répertoire "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires" ".
Gardez à l'esprit la version du framework que vous utilisez
Changez l'identité de l'AppPool utilisé par votre application, de ApplicatonPoolIdentity à NetworkService.
IIS> Pools d'applications> Sélectionner le pool d'applications actuel> Paramètres avancés> Identité.
SO Réponse (veuillez rétablir les paramètres par défaut si cela ne fonctionne pas)
Vérifiez la compatibilité de IIS Version et de la version AppPool .NET avec votre application. Très applicable aux premiers déploiements. SO Réponse
Vérifiez la configuration de l'emprunt d'identité, le cas échéant. SO Réponse
Ma solution:
J'ai découvert que certains logiciels anti-virus bloquaient activement les compilations de DLL dans le répertoire "Fichiers temporaires ASP.NET", le mien était McAfee. Les informaticiens ne m'ont pas informé de l'installation.
Selon les conseils des experts McAfee et de Microsoft, vous devez exclure le répertoire "Fichiers temporaires ASP.NET" lors de l'analyse en temps réel.
Sources:
Ne désactivez pas l'antivirus car il ne fait que son travail. Ne copiez pas manuellement les fichiers DLL manquants dans le répertoire \Fichiers ASP.NET temporaires {nom du projet} car c’est du ruban adhésif.
Si vous utilisez l'emprunt d'identité, veillez à donner les autorisations, y compris write et modify permission au compte d'utilisateur approprié dans le dossier suivant:
C:\Users\[username]\AppData\Local\Temp\Temporary ASP.NET Files
Il me manquait l'autorisation de modification, ce qui expliquait pourquoi l'ajout des autorisations par défaut ne fonctionnait pas pour moi.
Si vous êtes toujours confronté au problème, essayez ceci:
Ouvrez votre gestionnaire IIS -> Pools d'applications -> sélectionnez votre pool d'applications -> Paramètres avancés -> Sous "Modèle de processus", définissez le paramètre "Charger le profil utilisateur" sur True
Je crois avoir perdu une journée à la recherche de ce que je viens de dire.
Vous devez ajouter l'utilisateur Impersonating au dossier Debug de votre solution, car Framework tentera d'accéder à la DLL à partir de cet emplacement et de le placer dans le dossier Temporary Asp.Net.
Donc, fondamentalement, suivez ces 2 étapes
Autorisez le dossier Temporary Asp.Net Folder sous
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Fileset assurez-vous que l'utilisateur que vous ajoutez ici est identique à celui que vous utilisez lors de l'emprunt d'identité.Ajoutez l’utilisateur se faisant passer pour l’emprunt d’identité dans le dossier de débogage de votre solution YourSolutionPath ..\bin\Debug
Cela devrait marcher
J'ai eu le même problème, corrigé par reconstruire et redéployerTOUS LES FICHIERSDependents Dll
Accédez à IIS -> Pool d'applications -> Paramètres avancés -> Activer les applications 32 bits.
Dans mon cas, cela était dû à la fonction de protection d'accès de mon antivirus (McAfee). Il était évident que cela bloquait l’accès à ce fichier, de ce fait l’erreur.
Je l'ai désactivé et la solution a fonctionné. Vous pouvez vérifier toutes les applications utilitaires en cours d’exploitation susceptibles d’affecter l’accès à certains fichiers.
Vérifiez les paramètres IIS. J'utilise IIS 7.5 avec une compilation 32 ou 64 bits dans le cadre .NET. Si vous avez une application utilisant le mode 32 bits, assurez-vous que le pool d'applications peut utiliser des instructions 32 bits. Sinon, rien ne semble fonctionner, quel que soit le degré de sécurité ou le signe fort défini pour la DLL.
Dans mon cas, j'avais copié un service d'un serveur à un autre sans effectuer un déploiement approprié à partir de Visual Studio. Longue histoire.
Quoi qu'il en soit, j'avais configuré toutes les autorisations NTFS appropriées, entre autres choses, mais je ne pouvais toujours pas charger le fichier principal DLL pour le service.
Je l'ai corrigé en renommant le fichier service.pdb correspondant.
Par exemple, voici mon dossier bin:
\bin\
service.dll
service.dll.config
service.pdb
J'ai renommé service.pdb en zzservice.pdb, puis le service.dll est correctement chargé.
Je n'utilisais pas l'emprunt d'identité dans mon cas. Ma solution était de donner un accès complet à mon répertoire de projet pour le groupe d'utilisateurs "IIS_IUSRS".
J'ai rencontré ce problème et il s'est avéré qu'un paquet/assemblage référencé était chiffré par Windows. Cela est dû au fait que mon entreprise a implémenté une stratégie exigeant que le dossier Mes documents soit chiffré et que mes solutions Visual Studio se trouvent dans ce répertoire.
Je pourrais manuellement aller dans les propriétés de fichier/répertoire dans l'Explorateur Windows et désactiver le cryptage. Mais dans mon cas, il s’agissait d’une solution temporaire, car la stratégie réseau la modifierait. J'ai finalement déplacé ma solution VS vers un autre emplacement non chiffré.
Go to run : ctrl + R
Type : %temp%
supprimer tous les fichiers et dossiers
Rebuild Project.
done!
Dans mon cas, j'utilisais une usurpation d'identité simple et l'utilisateur de l'emprunt d'identité avait du mal à accéder à l'un des assemblys du projet. Ma solution:
- Recherchez le message de l'exception interne pour identifier l'assemblage problématique.
Modifiez les propriétés de sécurité du fichier d'assemblage.
a) Ajoutez le compte d'utilisateur que vous utilisez pour l'emprunt d'identité au nom du groupe et de l'utilisateur.
b) Donnez à ce compte utilisateur un accès complet au fichier Assembly.
Je configure l'environnement sur un nouveau serveur. Mon composant Web.config a un noeud d'identité, comme ci-dessous.Lorsque je fais face à "Impossible de charger le fichier, l'assembly ou l'une de ses dépendances. L'accès est refusé. Le problème est aléatoire, mais une fois que cela se produit, il continue"
Ajout de ccs\HJKWeb en tant que liste des utilisateurs de mon nouveau serveur.
<authentication mode="Windows" />
<identity impersonate="true" password="******" userName="ccs\HJKWeb" />
J'ai eu cette erreur de VS. En fait, j'avais ouvert une solution sans exécuter Visual Studio en tant qu'administrateur. Fermer Visual Studio et le réexécuter en tant qu'administrateur, puis la reconstruction, a résolu le problème pour moi.
J'espère que ça aide quelqu'un.
Pour moi, le hack suivant a fonctionné: Allez dans IIS -> Pools d’applications -> Paramètres avancés -> Modèle de processus -> Identité. Utilisateur du domaine)
Si vous obtenez le fichier DLL introuvable à la place de l'accès refusé, assurez-vous que le correctif VC++ approprié est installé.