Выпуск веб-бинарных файлов с поддержкой как 64, так и 32 бит? ASP.NET

Question

Я хотел бы выпустить свое приложение с поддержкой 32 и 64 бит. Я использую Elmah и SQLite. Оба пакета имеют отдельный двоичный файл для 32 и 64 бит. Я не могу добавить как 32, так и 64-битную DLL. Я попытался добавить обе 32- и 64-битные библиотеки DLL с другим именем файла в папку bin / release, и я получил ошибку в формате неверного изображения. (Я проверил, запустив на 64-битном сервере Windows обе библиотеки DLL в каталоге и в моей системе, которая делает 32-битную).

Как мне выпустить приложение, чтобы одна и та же папка могла работать как 32-битная или 64-битная?

Answer 1

Не так давно я только что боролся с 32- и 64-разрядными, но я попытаюсь это сделать, по крайней мере, с некоторыми общими наблюдениями. Я знаю, что этому вопросу уже более года, но я надеюсь, что ответ кому-то поможет в любом случае, независимо от того, «принимаете» ли вы ответ (что, в отличие от некоторых, объясняет, почему я не отвечаю на вопросы по StackOverflow).

Прежде всего, будет ли 32-битный только работать в контексте WOW64 в вашей ситуации? Часто так и будет, и это может упростить вашу ситуацию.

Однако существуют ситуации, в которых сторонние библиотеки делают WOW64 неработоспособным, по крайней мере, согласно их документации, с которой я столкнулся. Чтобы решить эту проблему, мне нужно было иметь 32-битную и 64-битную сборки. Если есть способ как-то выпустить их обоих в «одинаковые папки», я его не нашел. Однако сделать это было не так уж сложно. Мне пришлось редактировать файлы проекта Visual Studio вручную. Если я помню, основные шаги были:

1. Тщательно настройте мои определения сборок в Visual Studio, чтобы в обеих версиях выпуска и отладки были правильно настроены отдельные проекты. В моем случае это означало, что все, что взаимодействует с нативными библиотеками, должно быть построено в формате x86 или x64, а не в любом процессоре. Насколько я могу судить, проекты, предназначенные только для MSIL, могут быть любыми процессорами.
2. Отредактируйте файлы проекта (например, .csproj) так, чтобы правильные сторонние библиотеки DLL помещались в правильные папки на основе сборки. Если бы был более простой способ сделать это, я этого не видел. В вашем решении может быть очевидный файл проекта, хотя это может произойти в любом месте вашего решения, если:
3. В вашем реальном веб-проекте убедитесь, что вы добавили проект со сторонней копией DLL в качестве ссылки, даже если веб-проект не использует этот другой проект напрямую. Таким образом, файлы будут скопированы в ваш каталог сборки. Мне кажется, что это ошибка в MSBuild или Visual Studio, но на VS2010 она, похоже, не исправлена. Кроме того, если вам нужно скопировать сторонние библиотеки DLL в такой каталог, как App_Code, вам может потребоваться отредактировать файл веб-проекта для этого.

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

Может прийти кто-то, кто знает об этом больше, чем я, но я надеюсь, что это кому-то поможет. Я постараюсь ответить на любые вопросы, оставленные в комментариях.