Смутно о строительстве для 32- или 64-битных

У меня есть решение VS2013 с несколькими проектами (С# WPF-приложение плюс библиотеки классов). Для каждого проекта "Target Platform" установлен "Любой процессор". У меня создалось впечатление, что полученный EXE будет работать как 64-битное приложение на 64-битном ПК и 32-разрядное приложение на 32-разрядном ПК. Это верно? Мой dev-компьютер - 64-разрядный, но когда я запускаю приложение (автономное или VS-отладочное), он появляется в диспетчере задач как "foo.exe * 32". Что здесь происходит?

У нас есть младший разработчик с 32-разрядной машиной. Будет ли он все еще иметь возможность открыть решение и запустить его в VS?

Кроме того, некоторые из проектов ссылаются на стороннюю DLL. Поставщик предлагает как 32-битную, так и 64-битную версию, на которую должны ссылаться проекты? Если я ссылаюсь на 32-разрядную DLL, это предотвратит запуск приложения в виде 64-битного приложения? И если я ссылаюсь на 64-битную версию, это вызовет проблемы для 32-разрядного разработчика? А как насчет конечных пользователей - будет ли мой установщик проверять версию ОС и копировать через соответствующую DLL?

Наконец, что относительно DLL, на которые ссылается NuGet? NuGet устанавливает 32- или 64-разрядные версии DLL? Как мне работать с 32-разрядной или 64-разрядной установкой конечного пользователя?

Ответ 1

Я попытаюсь ответить на некоторые из ваших вопросов, так как вы вложили столько в один...

We have a junior developer with a 32-bit machine. Will he still be able to open the solution and run it in VS?

Да, до тех пор, пока все проекты настроены для сборки для Any CPU, и нет внешних зависимостей от 64-битных сборок или родных DLL.

If I reference the 32-bit DLL will this prevent the application from running as a 64-bit application?

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

And if I reference the 64-bit version, will this cause problems for the 32-bit developer?

Да, 32-битный разработчик не сможет запустить проект на своем компьютере, если есть 64-битные сборки.

В качестве последней мысли я хотел бы добавить, что очень важно, будет ли окончательный исполняемый проект построен как Any CPU, или для конкретной 32-битной или 64-битной целевой платформы.

Обычно я обнаружил, что наличие окончательного исполняемого файла, построенного как Any CPU, может вызвать всевозможные проблемы во время выполнения (из множества исключений среды выполнения Bad Image), если все связанные узлы не нацелены на Any CPU, и нет внешних, родные, зависимости. Это последнее требование наиболее сложно обеспечить.

С другой стороны, окончательный исполняемый файл, созданный для явно указанной 32-битной или 64-битной платформы, может с радостью включать другие сборки, построенные для Any CPU

Ответ 2

У нас есть младший разработчик с 32-разрядной машиной. Будет ли он все еще иметь возможность открыть решение и запустить его в VS?

Да, он может бежать.

Если я ссылаюсь на 32-разрядную DLL/64-разрядную версию, это предотвратит запуск приложения в виде 64-разрядного/32-разрядного приложения?

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

Обратитесь Условно используйте ссылку 32/64 бит при создании в Visual Studio

как насчет конечных пользователей - будет ли мой установщик проверять версию ОС и копировать через соответствующую DLL?

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

Литература:
Что делает Visual Studio и любой процессор? целевое среднее?