System.IO.IOException в PresentationFramework.dll при создании пользовательского элемента управления в WPF

Question

У меня есть пользовательский элемент управления UserControl, который находится в сборке сборки.У меня есть приложение WPF, которое создает экземпляр UserControl программным способом.Я уже добавил ссылку на сборку.Тем не менее, во время выполнения я получаю FF.исключение:

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)
   ...

Я изменил действие сборки для UserControl.xaml на EmbeddedResource, но это вызвало проблемы компиляции, поэтому я вернул его к настройке страницы по умолчанию.Я пробовал это в .NET 3 и 4 безрезультатно.У кого-нибудь есть идеи?

Answer 1

Наиболее распространенная причина этого - переименование сборки.Я объясню этот сценарий, а затем предоставлю некоторые другие возможности.

Предположим, у вас есть проект DLL "Abc", содержащий UserControl "MyControl".Сгенерированный InitializeComponent для MyControl в Abc.dll будет содержать Uri "/Abc;Component/MyControl.xaml".

Во время выполнения извлекается имя сборки" Abc "и поиск загруженных сборок выполняется для сборки.под этим именемЕсли такая сборка найдена, но у нее нет ресурса «MyControl.xaml», вы получите сообщение об ошибке, отправленное в вопросе.

Итак, вот сценарий:

• Вы переименовываете файл Abc.dll в Def.dll
• . Вы (или кто-то другой) создаете другой файл Abc.dll
• . В вашем проекте вы ссылаетесь на Def.dll (который был скомпилирован как Abc.dll)
• Ваш проект также прямо или косвенно ссылается на Abc.dll, поэтому он загружается при создании экземпляра MyControl

Теперь, когда вы создаете экземпляр MyControl из Def.dll, он ищет его xamlв сборке Abc.dll вместо сборки Def.dll.

Некоторые другие сценарии, в которых это может произойти:

• У вас есть устаревший файл .g.csв вашем каталоге obj с неправильным именем для файла xaml.Это может произойти, если вы изменили исходный код без обновления даты (что может произойти во время извлечения из системы контроля версий или распаковки zip-файла или многими другими способами).Очистка и восстановление решения исправят это.Поскольку ваш комментарий говорит, что вы пытались это сделать, это не относится к вам.

• Вы вручную редактируете имена ресурсов в файле .dll после его компиляции

• Вы загрузили две сборки с одинаковым именем (да, это возможно), и загрузчик ресурсов нашел неправильную

Обратите внимание, что при любом изменении пути кXAML-файл, например переименование или перемещение, может вызвать эту проблему, если файл .g.cs не соответствует пути в ресурсах.

Для дальнейшей диагностики вашей проблемы я рекомендую вам загрузить копиюNET Reflector и посмотрите на свой файл .dll, чтобы увидеть:

1. Какой Uri указывает InitializeComponent ()?
2. Существует ли файл .baml с тем же именем?

Вы также можете проверить стек вызовов в точке, где выдается исключение, чтобы убедиться, что используемый менеджер ресурсов имеет ссылку на ожидаемую сборку, а не какую-то другую сборку.

Answer 2

Я получил эту ошибку после перемещения всех моих окон WPF в новую папку в проекте под названием «Windows».Я исправил ошибку, перейдя в «App.Xaml» и обновив путь к главному окну:

StartupUri="Windows\MainWindow.xaml"