Неуправляемые сборки x64 в смешанной среде разработки .NET - PullRequest
3 голосов
/ 06 марта 2009

Что нам делать, если у нас есть некоторые разработчики, работающие на 64-битных машинах, а некоторые на 32-битных машинах, но нам нужно сослаться на неуправляемые сборки, которые должны быть в x86 для половины команды и x64 для другой половины? Есть ли решение помимо ручного обновления ссылок каждый раз, когда кто-то на 64-битной установке получает последнюю версию?

Ответы [ 3 ]

1 голос
/ 06 марта 2009

Довольно странно, что разработчики с машиной x64 охотно запускают 64-битную версию. Visual Studio не поддерживает Edit + Continue в режиме x64, это большая потеря. Обойти это просто, установите для Platform Target значение x86. Автоматически также решает вашу неуправляемую проблему DLL.

1 голос
/ 06 марта 2009

Вы хотите сделать это как часть вашей сборки, верно?

Напишите шаг перед сборкой, чтобы скопировать указанную DLL из постоянной позиции в дереве исходного кода в локальный проект. Используйте макрос $ (ConfigurationName) или $ (PlatformName), чтобы выбрать, какая версия неуправляемой библиотеки DLL будет скопирована. Вы просто храните свои DLL в отдельных папках с именами, которые соответствуют имени конфигурации или имени платформы.

0 голосов
/ 19 сентября 2009

Есть еще одно решение, которое предполагает небольшое редактирование вашего кода. Это описано в ответе от Милана Гардиана до этого вопроса .

В основном это включает в себя написание собственного обработчика ссылок на сборку, чтобы определить, какую сборку загружать во время выполнения, при условии, что у вас есть доступ к обеим (32- и 64-разрядным) версиям сборки. Я только что реализовал это решение сам, и оно работает как шарм.

Моя ситуация такова:
Я занимаюсь разработкой программы .NET, ориентированной на «Любой процессор» в 64-битной Windows 7. Я добавил ссылку на 32-разрядную сборку и установил для параметра «Копировать локально» значение false. Я использую события после сборки, чтобы скопировать 32- и 64-битную сборку в выходную папку, и я обязательно даю 32-битной сборке другое имя, чем в справочной. Это связано с тем, что я хочу заставить свой пользовательский распознаватель сборок включиться и сделать свое дело из-за того, что распознаватель сборок по умолчанию .NET не может разрешить ссылку. Во время выполнения правильная сборка загружается, а во время компиляции я не получаю ошибок. Следует отметить, что у меня не было времени, чтобы на самом деле подтвердить, что это сейчас работает на 32-битных ОС, но я не вижу причин, почему это не должно работать.

...