System.Exception в InitializeComponent ()?

Question

У меня странная проблема, которая вызывает у нас проблемы.

У нас есть простой C # Wpf UserControl. Это индикатор выполнения - ничего особенного - просто граница, которая меняет размер в зависимости от привязок к Value и MaxValue. Он прекрасно работает в 99% случаев, и мы используем его в дюжине мест в нашем коде, включая заставку.

Он всегда отлично работает на заставке - поэтому он всегда загружается и работает в нашем приложении.

Проблема в том, что иногда (и мы не можем предсказать или понять, когда) вызов InitializeComponent () в конструкторе индикатора выполнения выдает исключение System.Exception. Просматривая файл progressbar.g.cs, созданный во время компиляции (папка obj / Debug), я вижу, что выброшено исключение, поскольку файл progressbar.xaml не найден. Я, конечно, не изменил никакого кода в файле g.cs, и я вообще ничего не делал в этом UserControl.

System.Exception: The component 'MyProject.ControlLibrary.ProgressBar' does not have a resource identified by the URI '/MyProject.ControlLibrary;component/progressbar.xaml'. at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator) at MyProject.ControlLibrary.ProgressBar.InitializeComponent() in d:\Projectfolder\MyProject.ControlLibrary\ProgressBar.xaml:line 1 at MyProject.ControlLibrary.ProgressBar..ctor() in D:\projectfolder\MyProject.ControlLibrary\ProgressBar.xaml.cs:line 26 at ProjectName.UI.VideoViewer..ctor() in D:\projectfolder\UI\VideoViewer.xaml.cs:line 26 Source: PresentationFramework

Я не понимаю, почему ресурс progressbar.xaml иногда пропадает, особенно учитывая, что он всегда работает нормально хотя бы один раз при запуске приложения.

UserControl содержится в проекте MyProject.ControlLibrary.dll. Кажется, что этот проект настроен правильно, так как он содержит другие пользовательские элементы управления, которые не показывают никаких проблем - кроме одного другого аналогичного UserControl, который имеет идентичные проблемы.

У меня закончились идеи по этому поводу, поэтому любые предложения будут полезны. Я использую VisualStudio 2008 и .net 3.5

Answer 1

I может решил эту проблему - я объясню проблему здесь на случай, если кто-то еще столкнется с ней.

Один раздел нашего кода динамически загружает плагины из папки плагинов.Для этого он выполняет Assembly.LoadFile (имя файла) для всех файлов DLL в папке плагинов.

Он проверяет, реализует ли DLL наш интерфейс плагинов;если он это делает, он загружает его, если нет, это не так.Наши интерфейсы плагинов содержатся в файле с именем MyProject.Interfaces.dll, и этот файл вместе с MyProject.ControlLibrary.dll также находится в папке плагина.

Таким образом, код иногда вызывает Assembly.LoadFile для MyProject.ControlLibrary.dll дважды, поскольку он циклически перебирает dll в папке плагинов.Кажется, что после этого второго LoadFile ресурсы xaml теряются.Когда я предотвращаю эту вторую загрузку, кажется, это решает проблему.

Answer 2

Этот пост кажется лучшим обсуждением проблемы. Краткий ответ предполагает, что ваш пользовательский контроль мог быть загружен в две разные сборки. Длинный ответ заключается в том, что есть много людей, которые столкнулись с ошибкой, и неясно, нашли ли они последовательное решение / обходной путь. Один человек сказал, что MS, возможно, исправила проблему в 4.0

Answer 3

Я тоже хочу добавить свою информацию по этой теме.

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

Для этого я использовал Assembly.Load(File.ReadAllBytes(file));. Если бы я сделал это до создания экземпляра окна, InitializeComponent() выдаст мне ошибки.

Если я сначала создаю экземпляр окна, а затем загружаю сборки, все работает нормально. Хотя окно можно открывать и закрывать в любое время, таким образом, большую часть времени эти сборки были загружены.

Что я сделал, чтобы решить эту проблему, так это сначала создал отдельный домен приложения, а затем загрузил сборки в этом домене, используя: Assembly asm = PrivateAssemblyLoader.Load(File.ReadAllBytes(file));

Таким образом, текущий домен приложений не будет мешать загруженным сборкам.

(В моем приложении-плагине я ищу все файлы .exe и .dll внутри исполняемого каталога, поэтому он также может загружаться сам.)