2010-11-09 4 views
1

Un site Web sur lequel je travaille utilise un assembly tiers, disons A.dll. Cet ensemble A charge également un autre ensemble B pour certaines opérations. L'utilisation de mon site web par A ne nécessite pas du tout B, et je n'ai pas B.dll.De .NET 3.5 à 4.0: l'application Web se bloque car l'assembly inutilisé est introuvable

Cela n'a jamais été un problème lorsque je ciblais .NET 3.5, mais maintenant que j'essaie de passer à .NET 4, j'obtiens une erreur. Quand je regarde mon site Web dans le navigateur, j'obtiens: "Impossible de charger le fichier ou l'assemblage 'B.dll' [...]". Si je mets B.dll dans le répertoire bin, ça fonctionne très bien.

Cependant, je ne veux pas déployer B.dll et je ne sais pas ce qui fait que .NET 4 essaie de charger cet assembly alors que le site n'utilise aucune fonction de A qui le nécessite. Je suis mystifié car le même code fonctionne très bien sur .NET 3.5. Je suppose qu'il essaie de charger tous les assemblages à l'avance, même s'il ne sera pas utilisé. Je cherche un drapeau de configuration ou de compilateur qui empêcherait ce comportement. Des pointeurs?

J'ai essayé de simplifier mon problème en omettant les détails et les raisons pour lesquelles je ne veux pas que B soit déployé, etc. Veuillez me faire savoir si les informations que j'ai fournies ne donnent pas une idée claire du problème. Merci!

EDIT:

trace de la pile

[FileNotFoundException: Impossible de charger le fichier ou l'assembly 'B, Version = 15.4.0.0, Culture = neutral, PublicKeyToken = 1a5b964d6f0fbeab' ou une de ses dépendances. Le système ne peut pas trouver le fichier spécifié]

_Default.Page_Load (Object sender, EventArgs e) dans c:. \ Users \ bob \ Desktop \ WebSite1 \ Default.aspx.cs: 15

System.Web. Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Objet o, Objet t, EventArgs e) +14 System.Web.Util.CalliEventHandlerDelegateProxy.Callback (Expéditeur d'objet, EventArgs e) +35 System.Web.UI.Control.OnLoad (EventArgs e) 91 System.Web.UI.Control.LoadRecursive() 74 System.Web.UI.Page.ProcessRequestMain (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2207

trace de charge Assemblée

=== informations d'état pré-bind === LOG: User = bob LOG: DisplayName = B, Version = 15.4.0.0, Culture = neutre, PublicKeyToken = 1a5b964d6f0fbeab (Entièrement spécifié) LOG: Appbase = fichier: /// C:/Users/bob/Bureau/WebSite1/ LOG: Initial PrivatePath = C: \ Utilisateurs \ bob \ Desktop \ WebSite1 \ bin Assemblage d'appel: A, Version = 16.0.0.0, Culture = neutre, PublicKeyToken = null. LOG: Cette liaison démarre dans le contexte de chargement par défaut. LOG: Utilisation du fichier de configuration de l'application: C: \ Users \ bob \ Desktop \ WebSite1 \ web.config LOG: Utilisation du fichier de configuration de l'hôte: LOG: Utilisation du fichier de configuration de l'ordinateur à partir de C: \ Windows \ Microsoft.NET \ Framework \ v4 .0.30319 \ config \ machine.config. LOG: Référence de post-stratégie: B, Version = 15.4.0.0, Culture = neutre, PublicKeyToken = 1a5b963c6f0fbeab LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Fichiers ASP.NET temporaires/website1/efdbfea0/f60231a3/B.DLL. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.Fichiers NET/site Web1/efdbfea0/f60231a3/B/B.DLL. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Users/bob/Desktop/WebSite1/bin/B.DLL. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Users/bob/Desktop/WebSite1/bin/B/B.DLL. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary Fichiers ASP.NET/website1/efdbfea0/f60231a3/B.EXE. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary Fichiers ASP.NET/website1/efdbfea0/f60231a3/B/B.EXE. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Users/bob/Desktop/WebSite1/bin/B.EXE. LOG: Tentative de téléchargement du nouveau fichier URL: /// C: /Users/bob/Desktop/WebSite1/bin/B/B.EXE.

+0

Quelle est la trace de la pile? – SLaks

Répondre

1

Trouvé le problème; l'une des méthodes de l'assembly que nous appelions avait un type de valeur de B.dll dans une signature de méthode. Dans .NET 4.0, cela chargera B.dll même si cette méthode n'est jamais appelée.

La solution consistait à modifier la signature de méthode pour supprimer toutes les références aux types de valeur de B.

1

La fonction appelée par Default.aspx.cs sur la ligne 15 utilise B.dll.

+0

Je vais enquêter plus car la ligne 15 ne repose que sur A, qui hérite de C, à son tour de D, et D ne nécessite pas de B pour être chargé pour ce que je demande à la ligne 15. En outre, ce problème ne se produire si je cible .NET 3.5 et la fonction fonctionne bien. – siger

+0

Je vais essayer de créer une nouvelle solution simple qui imite cette chaîne d'héritage pour reproduire le problème plus clairement. – siger

+0

JITter essaye de charger B.dll quand il JIT la méthode appelée par cette ligne. Cela se produirait si la méthode ou son ctor statique faisait référence à un type de B.dll. – SLaks

Questions connexes