#vb.net #intel #autodesk #amd-processor
#vb.net #intel #Autodesk #amd-процессор
Вопрос:
Я постоянно разрабатываю надстройку inventor в VB.Net в Visual studio 2019 у меня есть несколько разных сборок, но время от времени какая-то машина просто не хочет загружать надстройку, например. текущая версия, которая у меня сейчас есть, работает на всех машинах, кроме одной машины AMD.
Когда я компилирую тот же проект с теми же настройками, никаких изменений вообще на компьютере AMD с ЛЮБЫМ вариантом сборки процессора, он запускается без проблем. Когда я делаю это на своей основной машине для разработки, это не работает на этом другом компьютере.
Я проверил зависимости с помощью dependency walker, я не получаю никаких сообщений об ошибках.
Когда я устанавливаю точки останова в режиме отладки и отлаживаю компиляцию dll в первых методах, вызываемых в файле «StandardAddInServer.vb», он не достигает его на компьютере AMD, когда он скомпилирован на компьютере Intel. Но в обратном случае она работает гладко.
Я понятия не имею, что это может быть, и я только предполагаю, что это связано с различием AMD / Intel в машинах. Была бы признательна за любую помощь в поиске решения.
Inventor 2018.3.7 Профессиональная сборка 287 установлена на компьютере Intel i7-4771 Visual Studio Community 2019 16.3.9, .NET 4.8.03761
Профессиональная сборка Inventor 2018 112 установлена на компьютере AMD Ryzen 7 3700X Visual Studio Community 2019 16.7.2 .NET 4.8.03752
Любая дополнительная информация, которая может быть полезной, будет предоставлена с удовольствием.
Ответ №1:
Что ж …. я подумал, давайте сделаем машины идентичными в отношении программного обеспечения. я начал устанавливать обновления inventor одно за другим в версии 2018.3.1, надстройка волшебным образом работала …. поэтому я надеюсь, что помогу кому-нибудь, если надстройка автоматически выгружается без каких-либо ошибок, вероятно, по вине autodesk inventors …
Ответ №2:
Используете ли вы КАКОЙ-ЛИБО процессор или принудительно доводите проект до заданного размера в битах?
Если вы не установите это и оставите его на ЛЮБОМ процессоре? Что ж, если вы запустите приложение из Visual Studio (например, установите на этот целевой компьютер), тогда приложение будет работать как x32 бита. ОДНАКО, если вы запустите программу из командной строки Windows (командная строка). Ну, если вы используете 64-разрядную командную строку, вы получаете 64-разрядную программу, запущенную в процессе. Если какой-либо из ваших внешних.dll или библиотеки x32 (или не скомпилированы ни с ОДНИМ процессором), или вы используете какие-либо библиотеки неуправляемого кода (скажем, ghostscript или что-то подобное)? Тогда ваша программа будет выполняться (или пытаться) как 64-разрядная.
Однако, если вы запустите x32-разрядную командную строку Windows (их две — одна x32, а другая x64). Итак, если вы запустите .net exe (свою программу) из командной строки Windows x32 bit, то ваша программа будет выполняться в процессе как x32 бита.
Итак, будьте осторожны здесь. Используя ЛЮБОЙ процессор из Visual Studio, вы ВСЕГДА получите x32-разрядную программу, включая отладку. Но ЗАПУСК программы (запуск за пределами VS) не всегда будет иметь размер x32 бита.
И вышеуказанное поведение, похоже, объясняет ваши проблемы на компьютере AMD. Дело было НЕ в том, что вы установили VS на этот компьютер, а в том, что использование VS для запуска вашей программы фактически ЗАСТАВИЛО ее работать как x32 бита.
Итог: НЕ используйте КАКОЙ-ЛИБО процессор, если это не именно то, что вам нужно, и что вы АБСОЛЮТНО уверены, что любые внешние библиотеки также скомпилированы как ЛЮБОЙ процессор, или фактически, что любые внешние библиотеки НЕ ИСПОЛЬЗУЮТ какой-либо неуправляемый код.
В целом? Я бы настроил ваш проект на принудительный запуск как x86 ВСЕГДА, и, таким образом, вы не получите сюрпризов из-за того, что код не работает.
Я очень сомневаюсь, что проблема в процессоре AMD, и установка VS сработала только из-за того, что ваш проект был запущен как x32, а не как x64 бит. Здесь это не имеет никакого отношения к AMD.
Ответ №3:
Вы могли бы попробовать использовать предыдущую версию framework, такую как 4.6.2. Это должно устранить проблему. Возможно, новые пакеты обновления Inventor могут работать с надстройками, созданными с более новыми версиями .net. Когда был выпущен 2018 Inventor, .net 4.8 был недоступен.
То, что написал Альберт, также верно. Если архитектура вашей библиотеки DLL не соответствует архитектуре вашего хост-процесса, она не может быть загружена. 64-битный процесс может использовать только 64-битные библиотеки DLL, тогда как 32-битный процесс может работать только с 32-битными библиотеками DLL. Проект .Net не будет скомпилирован Studio в полнофункциональный машинный код (в настоящее время вы также можете это сделать), а только промежуточный код, который будет окончательно скомпилирован .net Framework на целевой машине. Если выбран AnyCPU, вам не нужно предоставлять разные версии для разных аппаратных средств из-за такого поведения.