Должны ли проекты .NET «Any CPU» связываться с библиотеками DLL Framework или Framework64?

У меня есть проект C # Visual Studio (.csproj), в котором есть ссылка на версию System.Data для Framework64. Когда я пытаюсь построить с помощью MSBuild / Team Foundation Server (TFS) на другом компьютере, он не работает, поскольку 64-разрядная DLL не существует.

Должен ли я привязаться к версии Framework, или это ограничит меня при работе на 64-битных машинах? Перенаправляет ли .NET привязку на использование 64-разрядной версии, когда это возможно?


person Geoff Cox    schedule 26.11.2008    source источник


Ответы (1)


Я думаю, вы имеете в виду Любой процессор в своем вопросе, верно? Предполагая, что это так, привязка без учета битов является подходящим способом почти во всех обстоятельствах.

Напомним, что код .NET - это JITed (Just In Time compiled) - то есть 32-битный и 64-битный код из C # или Компилятор VB.NET одинаков, независимо от того, на какой архитектуре вы планируете работать. Когда код JIT выполняется во время выполнения, он становится 32- или 64-разрядным.

В некоторых ситуациях нужно помнить о целевой архитектуре. Конкретным случаем могут быть любые ссылки / зависимости от COM -обертки DLL, поставляемой .NET Framework или в противном случае. Это означает, что эти файлы DLL будут помечены (в случае COM) как 32-разрядные (поскольку COM - это только 32-разрядная архитектура), если они не были помечены как 32-разрядные, взаимодействие с COM не будет работать. Следовательно, поскольку они явно отмечены, результаты вашего проекта также должны быть отмечены.

person Peter Meyer    schedule 26.11.2008
comment
Итак, почему во фреймворке есть 64-битные и 32-битные библиотеки DLL? Они предварительно оптимизированы для JIT? Или они предварительно оптимизированы для вызова 32/4-битных API WIN32? - person Geoff Cox; 26.11.2008
comment
Я не был в этом уверен, но полагал, что некоторые системные сборки тесно интегрированы с собственным кодом. Это старое сообщение в блоге, похоже, предполагает следующее: blogs.msdn. com / junfeng / archive / 2004/08/11 / 212555.aspx - person Peter Meyer; 26.11.2008