После установки на Windows 7 x64 MS VS и создания почти пустого x64 -приложения, ссылки
через C:\Program Files\Reference Assemblies для некоторых системных компонент устанав-
ливаются по умолчанию на их 86-версии. Возможно это не так и страшно и ни на что в
итоге не повлиляет, ...НО:
1) Дело принципа сослаться на x64 сборки - коль они есть.
2) Возможно способы решения этой проблемы могут быть
полезными и в рамках одной платформы.
Вопрос: что в такой ситуации можно сделать?
P.S.
Возможно эта тема вызовет интерес и сама по себе.
Кому как не .Net-программистам начать что-то делать
на x64?!
Разное - .Net на x64
-
Almanax
Re: Разное - .Net на x64
Странно, что Visual Studio сама не приспосабливается к x64, хотя, конечно, умеет компилировать код, который выполняется в 64 битах. Может, готовое приложение уже обращается к 64битным аналогам сборок? Ведь запущено оно может быть под любым фреймворком (в котором есть нужные сборки и т.д.) - x86, IA64 или x64.
P.S. К слову, сама IDE выполнена только в x86 варианте.
P.S. К слову, сама IDE выполнена только в x86 варианте.
-
knibrest
Re: Разное - .Net на x64
Добрый день, уважаемый Almanax.
1) Прежде всего, благодарю вас за интерес к этой теме, моральную и не только поддержку.
2) Мне удалось решить эту проблему( если она была?), промоделировав 2 основных варианта
с использованием MSBuild. Если я работаю в папке ...C:\Windows\Microsoft.NET\Framework c
параметром Platform="x64" в файле проекта, то получаю точно такие предупреждения.
А если в папке C:\Windows\Microsoft.NET\Framework64, то все "по нулям".
Наверное, это типичный прием спуска с одного уровня абстракции на более низкий.
Часто бывает, что некоторые вопросы не удается режить удобным диалоговым способом,
а приходится работать в командной строке. Сам я ярый противник бесконечного сидения
в окне командной строки и всегда считал( считаю), что такие знания в оценке уроня прог-
раммиста не должны давать никаких положительных очков. Тут имеет место редкое исклю-
чение реальной полезности.
3) Меня по-прежнему интересует, как все это можно сделать в рамках VS2008, ну и конечно,
получу ли я какой либо существенный прирост в моих достаточно ресурсоемких графичес-
ких и других приложениях. Думаю, что шансов на это мало, но я обязан добросовестно
проверить и этот шанс. Будем также ждать по-настоящему многоядерных настольных
компьютеров или даже настольных суперкопьютеров.
4) Учитывая, что к нашей дискусси так никто и не присоединился, думаю ее можно завер-
шить. Если что, мой email [url=mailto:knibrest@tut.by]knibrest@tut.by[/url].
1) Прежде всего, благодарю вас за интерес к этой теме, моральную и не только поддержку.
2) Мне удалось решить эту проблему( если она была?), промоделировав 2 основных варианта
с использованием MSBuild. Если я работаю в папке ...C:\Windows\Microsoft.NET\Framework c
параметром Platform="x64" в файле проекта, то получаю точно такие предупреждения.
А если в папке C:\Windows\Microsoft.NET\Framework64, то все "по нулям".
Наверное, это типичный прием спуска с одного уровня абстракции на более низкий.
Часто бывает, что некоторые вопросы не удается режить удобным диалоговым способом,
а приходится работать в командной строке. Сам я ярый противник бесконечного сидения
в окне командной строки и всегда считал( считаю), что такие знания в оценке уроня прог-
раммиста не должны давать никаких положительных очков. Тут имеет место редкое исклю-
чение реальной полезности.
3) Меня по-прежнему интересует, как все это можно сделать в рамках VS2008, ну и конечно,
получу ли я какой либо существенный прирост в моих достаточно ресурсоемких графичес-
ких и других приложениях. Думаю, что шансов на это мало, но я обязан добросовестно
проверить и этот шанс. Будем также ждать по-настоящему многоядерных настольных
компьютеров или даже настольных суперкопьютеров.
4) Учитывая, что к нашей дискусси так никто и не присоединился, думаю ее можно завер-
шить. Если что, мой email [url=mailto:knibrest@tut.by]knibrest@tut.by[/url].
-
knibrest
Re: Разное - .Net на x64
Спасибо за внимание к моей теме, уважаемый 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 - как бы хотелось. Я не знаю как это осуществить!
Возможно вы или кто-то другой это знает!?
для 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
-
Almanax
Re: Разное - .Net на x64
VS2008(1!) - я же знаю, что у меня установлено под Windows 7 x64(2!) - об этом есть в моем 1-м сообщении
ответы на 2 последних вопроса "в одном флаконе"
Да, кстати абсолютно таже картина будет и на Windows XP SP3 x86, которая у меня на данный момент основная.
Хотя, мне кажется никто не должен мне препятствовать создать(! не запускать) с помощью VS2008 в операционной системе x86-платформы x64-приложение на С#, которое просто выводит пустую форму без контролов.
В этом плане такое ощущение, что дело не в платформе OC, а в самой VS. Просто, для чистоты экспериментов я делаю
все под Windows 7 x64. Ну, и чтобы запустить можно было.
ответы на 2 последних вопроса "в одном флаконе"
Да, кстати абсолютно таже картина будет и на Windows XP SP3 x86, которая у меня на данный момент основная.
Хотя, мне кажется никто не должен мне препятствовать создать(! не запускать) с помощью VS2008 в операционной системе x86-платформы x64-приложение на С#, которое просто выводит пустую форму без контролов.
В этом плане такое ощущение, что дело не в платформе OC, а в самой VS. Просто, для чистоты экспериментов я делаю
все под Windows 7 x64. Ну, и чтобы запустить можно было.
-
Almanax
Re: Разное - .Net на x64
Извини , уже забыл))
Дело, конечно, в самой VS. Думаю, при компиляции в Vista x64 получается тот же эффект. Сейчас нет рядом x64 ОС. В C:\Program Files\Reference Assemblies (Win7x64) эти сборки вообще есть?
Дело, конечно, в самой VS. Думаю, при компиляции в Vista x64 получается тот же эффект. Сейчас нет рядом x64 ОС. В C:\Program Files\Reference Assemblies (Win7x64) эти сборки вообще есть?
-
Almanax
Re: Разное - .Net на x64
Цитата knibrest:
Прежде всего, во Windows 7 x64 64-разрядные приложения группируются в Program Files,
а 32-разрядные в Program Files (x86).
Я это знаю. Если у меня в данный момент нет x64 ОС - это не означает, что я ей никогда не пользовался.
Цитата knibrest:
думаю, что 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). Вот на этой стадии уже берутся сборки из нужной папки и нужной архитектуры.
Прежде всего, во Windows 7 x64 64-разрядные приложения группируются в Program Files,
а 32-разрядные в Program Files (x86).
Разное - .Net на x64
Я это знаю. Если у меня в данный момент нет x64 ОС - это не означает, что я ей никогда не пользовался.
Цитата knibrest:
думаю, что AMD64 нужно понимать просто как х64
Разное - .Net на x64
Так оно и есть. 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). Вот на этой стадии уже берутся сборки из нужной папки и нужной архитектуры.