2008-11-26 8 views
1

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

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

ответ

1

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

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

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

+0

Итак, почему в инфраструктуре 64-разрядные и 32-разрядные библиотеки DLL. Предварительно ли они оптимизированы для JITed? Или они предварительно оптимизированы для вызова 32/4-битных «WIN32» API? – 2008-11-26 06:42:34