.Net на x64

[knibrest]

После установки на Windows 7 x64 MS VS и создания почти пустого x64 -приложения, ссылки
через C:\Program Files\Reference Assemblies для некоторых системных компонент устанав-
ливаются по умолчанию на их 86-версии. Возможно это не так и страшно и ни на что в
итоге не повлиляет, ...НО:
1) Дело принципа сослаться на x64 сборки - коль они есть.
2) Возможно способы решения этой проблемы могут быть
полезными и в рамках одной платформы.

Вопрос: что в такой ситуации можно сделать?

P.S.
Возможно эта тема вызовет интерес и сама по себе.
Кому как не .Net-программистам начать что-то делать
на x64?!

[Almanax]

Странно, что Visual Studio сама не приспосабливается к x64, хотя, конечно, умеет компилировать код, который выполняется в 64 битах. Может, готовое приложение уже обращается к 64битным аналогам сборок? Ведь запущено оно может быть под любым фреймворком (в котором есть нужные сборки и т.д.) - x86, IA64 или x64.

P.S. К слову, сама IDE выполнена только в x86 варианте.

[knibrest]

Спасибо за внимание к моей теме, уважаемый Almanax.
для RELEASE X64 получаются предупреждения:
Предупреждение 1 Создание сборки -- Сборка "mscorlib.dll", на которую дается ссылка, предназначена для другого процессора
Предупреждение 2 Создание сборки -- Сборка "System.Data.dll", на которую дается ссылка, предназначена для другого процессора
Соответствующая справка MSDN несколько успокаивает:
При построении 64-разрядного приложения в 32-разрядной операционной
системе необходимо обеспечить установку в целевой операционной системе
64-разрядных версий всех связанных сборок. Для всех сборок среды CLR, ориентированных на системы x86, предусмотрены
64-разрядные аналоги (каждая сборка CLR будет существовать во всех операционных системах).
Поэтому для сборок CLR предупреждение CS1607 можно пропустить(!!!).
-------------------------------------------------------------------------------------------------------!!!
Если посмотреть свойства ссылки System.Core, то виден путь C:\Program Files (x86)\Reference Assemblies,
а не C:\Program Files\Reference Assemblies - как бы хотелось. Я не знаю как это осуществить!
Возможно вы или кто-то другой это знает!?

[Almanax]

VS2008 или 2005?

[knibrest]

VS2008 - а что есть какая-то принципиальная разница!?

[Almanax]

Не уверен... А ОС я так понял x86?

[knibrest]

VS2008(1!) - я же знаю, что у меня установлено под Windows 7 x64(2!) - об этом есть в моем 1-м сообщении
ответы на 2 последних вопроса "в одном флаконе"

Да, кстати абсолютно таже картина будет и на Windows XP SP3 x86, которая у меня на данный момент основная.
Хотя, мне кажется никто не должен мне препятствовать создать(! не запускать) с помощью VS2008 в операционной системе x86-платформы x64-приложение на С#, которое просто выводит пустую форму без контролов.
В этом плане такое ощущение, что дело не в платформе OC, а в самой VS. Просто, для чистоты экспериментов я делаю
все под Windows 7 x64. Ну, и чтобы запустить можно было.

[Almanax]

Извини , уже забыл))
Дело, конечно, в самой VS. Думаю, при компиляции в Vista x64 получается тот же эффект. Сейчас нет рядом x64 ОС. В C:\Program Files\Reference Assemblies (Win7x64) эти сборки вообще есть?

[knibrest]

Уважаемый Almanax!
Прежде всего, во Windows 7 x64 64-разрядные приложения группируются в Program Files,
а 32-разрядные в Program Files (x86).
Далее:
1) В C:\Windows\assembly в графе "Архитектура процессора" встечаются значения: x86, AMD64, MSIL.
В частности, mscorlib есть MSIL и AMD64.Аналогично и для System.Data.А вот System.Core там только MSIL.
( думаю, что AMD64 нужно понимать просто как х64).
2) Много еще где хранятся сборки .Net( они там предустановлены). В частности,
в C:\Windows\Microsoft.NET\Framework и C:\Windows\Microsoft.NET\Framework64.
3) В C:\Program Files (x86)\Reference Assemblies:
- mscorlib отсутствует;
- System.Data отсутствует;
В C:\Program Files\Reference Assemblies - аналогично
4) А вот System.Core есть в обоих "Референсах", но берется из
C:\Program Files (x86)\Reference Assemblies и для платформы x64.
Это видно из свойств этой ссылки в проекте x64.
Если у вас нет 64-разрядной OC, то вам будет сложно предложить что-нибудь путное.Но кто знает?

[Almanax]

Прежде всего, во Windows 7 x64 64-разрядные приложения группируются в Program Files,
а 32-разрядные в Program Files (x86). »
Я это знаю. Если у меня в данный момент нет x64 ОС - это не означает, что я ей никогда не пользовался.

думаю, что AMD64 нужно понимать просто как х64 »
Так оно и есть. x64 (а точнее x86-x64) - это альтернативное название архитектуры AMD64, которая позволяет на стандартом x86-совместимом процессоре запустить 64битный уровень.

MSIL означает, что сборка будет браться из той папки, которая содержит сборки архитектуры среды.

Т.к. System.Core определяется как MSIL, то и результат для него соответствующий. Т.к. VS2008 (как и 2005, 2010 CTP) выполнена в x86 варианте и является средой выполнения вашей программы на момент её компиляции, она и показывает вам сборки из папки Program Files (x86).

После компиляции проекта ваш .exe или .dll содержат не машинный код, а код промежуточного языка IL, который при запуске программы перекомпилируется в машинный код средой выполнения (Framework x86 или Framework x64). Вот на этой стадии уже берутся сборки из нужной папки и нужной архитектуры.

[knibrest]

Добрый день, уважаемый Almanax.
1) Прежде всего, благодарю вас за интерес к этой теме, моральную и не только поддержку.
2) Мне удалось решить эту проблему( если она была?), промоделировав 2 основных варианта
с использованием MSBuild. Если я работаю в папке ...C:\Windows\Microsoft.NET\Framework c
параметром Platform="x64" в файле проекта, то получаю точно такие предупреждения.
А если в папке C:\Windows\Microsoft.NET\Framework64, то все "по нулям".
Наверное, это типичный прием спуска с одного уровня абстракции на более низкий.
Часто бывает, что некоторые вопросы не удается режить удобным диалоговым способом,
а приходится работать в командной строке. Сам я ярый противник бесконечного сидения
в окне командной строки и всегда считал( считаю), что такие знания в оценке уроня прог-
раммиста не должны давать никаких положительных очков. Тут имеет место редкое исклю-
чение реальной полезности.
3) Меня по-прежнему интересует, как все это можно сделать в рамках VS2008, ну и конечно,
получу ли я какой либо существенный прирост в моих достаточно ресурсоемких графичес-
ких и других приложениях. Думаю, что шансов на это мало, но я обязан добросовестно
проверить и этот шанс. Будем также ждать по-настоящему многоядерных настольных
компьютеров или даже настольных суперкопьютеров.
4) Учитывая, что к нашей дискусси так никто и не присоединился, думаю ее можно завер-
шить. Если что, мой email knibrest@tut.by.