#c# #wpf #visual-studio-2008 #c -cli
#c# #wpf #visual-studio-2008 #c -cli
Вопрос:
Я использую Visual Studio 2008, .NET 3.5 SP1, и у меня есть тестовое приложение со следующими модулями:
- C DLL
- C / CLI DLL, которая использует # 1
- приложение C # WPF, использующее # 2
Когда я пытаюсь использовать классы из # 2 в качестве ресурсов в WPF XAML, дизайнер не позволяет мне:
<Window x:Class="WpfApplication1.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:lib1="clr-namespace:ClassLibrary1;assembly=ClassLibrary1" <- ERROR
Ошибка: «Сборка ‘ClassLibrary1’ не найдена. Убедитесь, что у вас не пропущена ссылка на сборку. Кроме того, убедитесь, что ваш проект и все сборки, на которые ссылаются, были собраны.»
Но когда я использую класс из C / CLI DLL в коде за главным окном приложения, все работает нормально. Class1 создан, и в его конструкторе он обращается к C DLL, никаких проблем.
using ClassLibrary1;
...
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
//use in code-behind
Class1 tmp = new Class1();
tmp.FirstName = "foo";
Title = tmp.FirstName;
}
}
Если я изменяю сборку C / CLI, удаляю ее вызов в C DLL и перестраиваю все заново, разработчик перестает жаловаться и загружает сборку C / CLI без жалоб.
Я подозреваю, что эта проблема как-то связана с тем, где разработчик WPF ищет динамические библиотеки.
Комментарии:
1. Я не уверен в обходном пути, но я полагаю, что VS / WPF Designer копирует сборки во временное местоположение и загружает их оттуда. Так что, вероятно, это не копирование вашей библиотеки DLL C .
2. Я думаю, вы очень близки к истине, но не совсем. Сборки (даже неуправляемые) фактически скопированы, но, как говорит Рик ниже, разработчик WPF не может их найти, если они не находятся где-то в системном пути.
Ответ №1:
Поскольку дизайнер Visual Studio копирует ваши сборки во временное расположение, но не копирует ваши неуправляемые зависимости, вы можете столкнуться с этой проблемой.
Самое простое решение, хотя и не идеальное, — добавить папку, содержащую ваши неуправляемые зависимости, в PATH переменную окружения, а затем начать DevEnv.exe с этого PATH .
Вы можете сделать это либо с помощью:
- Добавление папки в системные переменные среды с помощью Компьютер -> Свойства
- Использование командного файла, который задает путь, а затем запускает DevEnv
Проблема с этим решением заключается в том, что при перестроении неуправляемых зависимостей Visual Studio имеет тенденцию «зависать» на них или не использовать новые, и поэтому в конечном итоге вам нужно выйти и перезапустить Visual Studio после использования конструктора, чтобы должным образом полностью все перестроить, и это может быть немного болезненно.
Комментарии:
1. Да, должно быть, так: дизайнер находит мои библиотеки DLL, только если они находятся по системному пути. Если я скопирую свою библиотеку в папку system32, как предлагается здесь ( social.msdn.microsoft.com/Forums/en/vswpfdesigner/thread /… ), вместо того, чтобы в папку вывода, дизайнер находит ее. Поэтому я уверен, что ваше решение сработает. Однако я действительно не горю желанием иметь дело с проблемой устаревших DLL, которую вы описываете. Блин.
2. @Matthew: В целях проектирования вас может вообще не волновать, обновлена ли неуправляемая DLL. Это могло быть недельной давности. Поэкспериментируйте, чтобы найти то, что работает лучше всего.
Ответ №2:
Не настоящее решение, но иногда это помогает: перестройте с использованием «AnyCPU» (не «x64», потому что дизайнер — это 32-разрядный процесс) и в режиме «Release» закройте и повторно откройте Visual Studio. И, да: это очень раздражает…