System.IO.IOException dans PresentationFramework.dll lors de l'instanciation d'un contrôle utilisateur dans WPF

Question

J'ai un contrôle utilisateur UserControl qui se trouve dans un assembly Assembly. J'ai une application WPF qui instancie UserControl d'une manière programmatique. J'ai déjà ajouté une référence à l'Assemblée. Cependant, pendant l'exécution, je reçois le ff. exception:

Cannot locate resource 'usercontrol.xaml'. 
    at MS.Internal.AppModel.ResourcePart.GetStreamCore(FileMode mode, FileAccess access) 
    at System.IO.Packaging.PackagePart.GetStream(FileMode mode, FileAccess access) 
    at System.IO.Packaging.PackagePart.GetStream() 
    at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator) 
    ... 

J'ai changé l'action de construction pour UserControl.xaml à EmbeddedResource mais cela a causé des problèmes de compilation si je l'ai remis à la mise en page par défaut. J'ai essayé ceci dans .NET 3 et 4 en vain. Quelqu'un a quelquonque idée?

Answer 1

La cause la plus fréquente de ceci est si vous renommez un assemblage. Je vais expliquer ce scénario, puis donner d'autres possibilités.

Supposons que vous avez un projet DLL "Abc" contenant UserControl "MyControl". Le InitializeComponent généré pour MyControl dans Abc.dll contiendra le Uri "/Abc;Component/MyControl.xaml".

Lors de l'exécution, le nom de l'assembly "Abc" est extrait et les assemblys chargés sont recherchés pour un assembly de ce nom. Si un tel assembly est trouvé mais qu'il n'a pas de ressource "MyControl.xaml", vous obtenez l'erreur que vous avez affichée dans la question.

Voici donc le scénario:

• renommer le fichier Abc.dll à Def.dll
• Vous (ou quelqu'un) crée un fichier Abc.dll différent
• Dans votre projet, vous faites référence Def.dll (qui a été compilé comme Abc.dll)
• Votre projet a également directement ou indirectement des références Abc.dll il est chargé lorsque MyControl est instancié

Maintenant, lorsque vous instanciez MyControl à partir Def.dll, il recherche son xaml dans l'assembly Abc.dll au lieu de l'assembly Def.dll.

D'autres scénarios dans lesquels cela peut se produire:

• Vous avez un fichier .g.cs périmé dans votre répertoire obj qui a le mauvais nom pour le fichier XAML. Cela peut se produire si vous avez modifié le code source sans mettre à jour la date (ce qui peut se produire lors d'une extraction à partir d'un système de contrôle de source ou d'un dézippage d'un fichier zip ou de plusieurs autres façons). Le nettoyage et la reconstruction de la solution permettront de résoudre ce problème. Puisque votre commentaire dit que vous avez essayé cela, cela ne s'applique pas à vous.

• Vous modifiez manuellement les noms de ressources dans le fichier .dll après qu'il a été compilé

• Vous avez chargé deux assemblées avec le même nom (oui, cela est possible), et le chargeur de ressources trouvé le mauvais un

Notez que toute modification du chemin d'accès au fichier XAML, comme changement de nom ou de le déplacer, peut provoquer ce problème si le fichier .g.cs ne correspond pas au chemin dans les ressources.

Pour diagnostiquer votre problème plus loin, je vous recommande de télécharger une copie de NET Reflector et de regarder votre.Fichier dll à voir:

1. Qu'est-ce que Uri fait pour InitializeComponent()?
2. Existe-t-il un fichier .baml portant le même nom?

Vous pouvez également examiner la pile d'appels au point où l'exception est levée pour vous assurer que le gestionnaire de ressources utilisé contient une référence à l'assembly attendu, et non un autre assembly.

Answer 2

J'ai reçu cette erreur après avoir déplacé toutes mes fenêtres WPF dans un nouveau dossier du projet appelé "Windows". Je corrige l'erreur en allant dans « app.xaml » et mettre à jour le chemin de la fenêtre principale à:

StartupUri = « Windows \ MainWindow.xaml »