Дизайнер отклоняет пользовательский контроль

Question

У меня есть проект библиотеки управления C++, скомпилированный с использованием/CLR. Внутри этого проекта есть пользовательский элемент управления, который вызывает вызов в родную DLL. Этот элемент управления пользователя появляется в панели инструментов дизайнера, как и должно быть, но я не могу перетащить его в форму. Без ссылки на DLL пользовательский элемент управления может использоваться отлично, но при ссылке я просто получаю сообщение «Не удалось загрузить элемент панели инструментов» при попытке его использовать.

Натуральный вызов функциональный и не повредит User Control. Пользовательский элемент управления может быть хорошо рассмотрен в дизайнере самостоятельно с включенным вызовом DLL. Также, если элемент управления добавляется вручную в форму и выполняется как программа, он также будет отображаться в порядке.

Это заставляет меня подозревать, что проблема заключается только в том, что Visual Studio Designer должен знать, где находится эта родная DLL. Но я не уверен, как это сказать, или где разместить DLL, чтобы он мог ее найти. Насколько я знаю, в настройках проекта нет способа ссылаться на родную DLL. Поэтому для меня имеет смысл, что дизайнер просто жалуется, потому что он не может это исправить.

Есть ли способ сделать эту работу?

Answer 1

К сожалению, вы столкнулись с «ошибкой по дизайну» в VS (или, другими словами, «особенностью»).

Ваше подозрение, что проблема связана с дизайнером Visual Studio, который должен знать, где находится родная DLL, - частично справа. Дело не в незнании его местоположения, а в том, что дизайнер не может отражать смешанные сборки (те, которые содержат как управляемый, так и собственный код), чтобы создать экземпляр элемента управления. Это приводит к тому, что панель инструментов отображает отмеченную вами ошибку.

Обходной путь заключается в компиляции исходных файлов на C++ с использованием /clr:pure для создания чисто управляемого EXE.

Другая возможность (также «ошибка по дизайну» в VS) заключается в том, что элемент управления, который вы пытаетесь добавить, был скомпилирован как 64-битный компонент. Поскольку Visual Studio представляет собой 32-разрядный процесс, он может выполнять только 32-битные модули. Хотя он позволяет вам добавить ссылку на 64-битную сборку, она не может на самом деле JIT компилировать эту 64-битную сборку и выполнять ее в процессе.

Обходной путь здесь состоит в том, чтобы скомпилировать вашу сборку пользовательских элементов управления с помощью параметра «AnyCPU», что приведет к его выполнению в виде 32-разрядного процесса в 32-разрядной среде и 64-разрядному процессу в 64- бит. На самом деле, это лучшее из обоих миров, если вы правильно написали свой код.

Наконец, если ни одна из этих работ, не всегда есть возможность обхода дизайнера.Вы все равно можете написать код, необходимый для создания экземпляра вашего пользовательского элемента управления и установки его свойств в инициализаторе формы. Все, что вы потеряете, - это возможность использовать элемент управления внутри конструктора внутри Visual Studio. Все будет работать так, как ожидалось во время выполнения.

Answer 2

вещи попробовать:

VS2010: скопировать DLL в папку Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies.

VS2008, VS2010: скопируйте dll в папку AppData\Local\Microsoft\VisualStudio\<version>\ProjectAssemblies\.

Answer 3

Мне кажется, что управление со ссылкой на родную DLL не удается, потому что Visual Studio не может ее загрузить. Попробуйте установить переменную среды PATH либо глобально, либо исполняемую версию Visual Studio при ее запуске. Если это не помогает, попробуйте отладить поведение времени разработки вашего элемента управления, и вы сможете найти проблему.

Answer 4

Я нашел это похоже на аналогичную проблему?

https://connect.microsoft.com/VisualStudio/feedback/details/388107/winforms-designer-fails-to-load-managed-dll-having-unmanaged-dependencies#details

Так MS, кажется, официально говоря, обновление от VS2008 к VS2010 в качестве обходного пути.

Вы когда-нибудь находили другое обходное решение?

Это проблема, которую я испытываю прямо сейчас в VS2008 с помощью управляемого проекта C# .net с использованием управляемого проекта оболочки C++ с использованием неуправляемого проекта на C++.

Это, безусловно, выглядит как временные сборки дизайнера, которые использует Visual Studio, - проблема заключается в загрузке обнаруженной сборки оболочки зависимостей во временную папку, но не в неуправляемых зависимостях сборки обертки. Я вижу это в C: \ Users \ Username \ AppData \ Local \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies. Когда я пытаюсь загрузить конструктор, там создается новая папка с управляемой DLL, но не неуправляемыми зависимостями. К сожалению, я не могу понять, что говорит человек из вопроса из вышеперечисленного Microsoft, это обходной путь с использованием $ (TargetDir).

Answer 5

Свяжите свою библиотеку с /DELAYLOAD:"your_native.dll ". Для меня это решило ту же проблему.

Answer 6

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

Для записи, здесь было мое решение:

1) Измените параметры решения для x86. Это позволило мне установить контроль над дизайнером, переместить его и т. Д. 2) По завершении вы можете вернуться к AnyCPU или x64. Я действительно использую только конструктор, чтобы упростить установку нескольких значений, и кажется, что проблема с 32/64 бит вызывает проблемы.