Код написан в Vista 64, совместимом на OS на 32 бита?
Метод расширения для IEnumerable:
public static IEnumerable<T> Randomize<T>(this IEnumerable<T> source)
{
Random rnd = new Random();
return source.OrderBy<T, int>((item) => rnd.Next());
}
7 ответов
Я делаю разработку на машинах на 64 бита для Windows на 32 бита. Это не проблема. Необходимо удостовериться, что проекты установлены скомпилировать в x86 режиме для консерватора. Вы захотите пройти каждый проект в решении и проверить это дважды. Вы могли также использовать установку AnyCPU, но это немного более опасно, так как она будет работать по-другому на Вашей dev машине, чем машина на 32 бита. Вы хотите избежать режима на 64 бита, конечно.
Проблемами, с которыми я столкнулся, являются драйверы, которые не работают, когда приложение компилируется для 64 битов (явно 64 бита или скомпилированный AnyCPU и работа Windows на 64 бита). Те проблемы абсолютно преодолимы, придерживаясь x86 компиляции. Это должно показать все дефекты на Ваших dev машинах.
Идеально, Вы могли настроить среду сборки и тестовую среду, которая могла быть выполнена против часто на машине на 32 бита. Это должно заверить Ваше управление и позволить Вам избежать VM как своего рабочего стола.
Не ответ на Ваш вопрос, но возможно решение Вашей проблемы: VirtualBox (и вероятно другие) поддерживает режим "бесшовной интеграции", который просто дает Вам вторую панель запуска и позволяет Вам перетащить окна вокруг свободно.
Кроме того, и это - ответ на Ваш вопрос, он зависит от Ваших настроек компиляции. Можно скомпилировать для различных сред, и можно отлично скомпилировать 32-разрядные программы в 64-разрядной системе с Visual Studio. Не может сказать Вам, как, но я уверен, что некоторый гуру Visual Studio мог выручить Вас.
Компиляция для ОС на 64 бита является опцией в компиляторе. Можно абсолютно скомпилировать в 32 бита exe из Vista 64 бита. Когда Вы запускаете приложение, можно затем видеть в TaskManager, что существует "*32" рядом с процессом... это означает, что это - 32 бита ;)
Я полагаю, что Вашим менеджерам нужно еще некоторое образование на том, что действительно означает ОС на 64 бита :)
Пока Вы компилируете свои исполняемые файлы как 32 бита, они будут работать и на 32 битах и на 64 (гарантируемых) машинах Windows. Используя 64 dev машины имеет преимущество, которое можно начать тестировать код с компиляцией на 64 бита (для проверки на вещи как указатели, литые к целым числам на 32 бита), этот способ делать переход к на 64 бита более легкому в будущем (должны Вы своя компания принимать решение сделать версию на 64 бита).
да, как adam говорил. Существует 3 опции: MSIL (значение по умолчанию), x64, и x86. Можно быть нацелены на x64, и он генерирует dll's специально для 64-разрядных систем, или можно сделать x86, который будет работать 32-разрядный и 64-разрядный, но будет иметь те же ограничения как 32-разрядные в 64-разрядной системе.
MSIL в основном позволит JITer дать конкретную инструкцию платформы (при небольшой потере производительности по сравнению с собственным изображением)
Править: никакой язык, таким образом, я говорю о языках платформы .NET как vb.net и c#, C++, не является совершенно другим животным.
Мы разрабатываем 32-разрядное приложение с помощью VS 2005 (2008 скоро) и только что купили некоторые новые машины с XP Pro x64 или Vista Business, 64-разрядной на них так, чтобы мы могли использовать в своих интересах дополнительную RAM, пока содержание наблюдения информирует о возможности выполнения 64-разрядного порта, если становится коммерчески необходимо сделать так. У нас не было проблем с выполнением этого кроме тонкой настройки некоторых сценариев в нашей среде разработки и т.д.
Те разработчики, которые не были включены в этот цикл обновления все еще, используют 32-разрядные машины, таким образом, они должны взять проблемы, когда модульные тесты и набор тестов приложения выполняются как само собой разумеющееся перед регистрацией.
То, что мы также делаем, должно удостовериться, что у нас есть ряд "тестовых машин" сборки, составленных из "типичных" конфигураций (XP/Vista, 2/4/8 ядра, и т.д.), что сборка и наборы тестов регистраций - у нас есть всевозможные наборы тестов для устойчивости, производительности, и т.д. - прежде чем они будут добавлены к надлежащей области интеграции. Снова, они не взяли проблем с запуском 32-разрядного приложения, основывался на 64-разрядной ОС.
Так или иначе, как другие уже сказали, я не ожидал бы, что это будет проблемой, потому что это - компилятор, который генерирует соответствующий код для целевой ОС независимо от ОС, на которой на самом деле работает компилятор.
Найденный этим сегодня:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
Разработка x64 с.NET
Ранее в этом году я переключился на 64-разрядную операционную систему - Vista Окончательный x64, чтобы быть точным. По большей части этот процесс был относительно безболезненным, но было несколько отклонений по пути (x64 совместимые драйверы, главным образом, но это не точка этого обсуждения).
В мире x64 разработки было несколько борющихся точек, что я думал, что обрисую в общих чертах здесь. Этот список будет, вероятно, выращивать, поэтому ожидать будущие сообщения по вопросу.
В замечательном мире разработки.NET приложения и блоки могут быть скомпилированы для предназначения для различных платформ. По умолчанию приложения и блоки компилируются как Любой ЦП в Visual Studio. В этом сценарии CLR загрузит блок как, независимо от того, что цель по умолчанию для машины, на которой это выполняется. Например, при выполнении исполняемого файла на x64 машине, это будет выполнено как 64-разрядный процесс.
Visual Studio также предусматривает 3 определенных цели платформы: x86, x64 и Itanium (IA-64). При создании исполняемого файла как определенной цели это будет загружено как процесс того типа. Например, x86-целенаправленный исполняемый файл работает на x64 машине, будет работать как 32-разрядный процесс с помощью 32-разрядного уровня CLR и WOW64. Когда блоки загружаются во времени выполнения, они могут только быть загружены процессом, если их целевые соответствия тот из процесса хостинга, или он компилируется как Любой ЦП. Например, если x64 были установлены как цель для блока, она может только быть загружена процессом x64.
Это сыграло роль в нескольких сценариях для меня:
XNA - XNA доступен как ряд 32-разрядных блоков только. Поэтому при ссылке на блоки XNA, исполняемый файл/блок с помощью них должен быть предназначен на x86 платформу. Если это будет предназначаться как x64 (или как Какой-либо ЦП и работаться 64-разрядная машина), то ошибка будет брошена при попытке загрузить блоки XNA.
Microsoft Robotics Studio - XInputGamepadService использует XNA внутренне, чтобы говорить с контроллером Xbox 360. Посмотрите выше.
Управляемый DirectX - В то время как это уже удержано от использования и заменяемый XNA, это все еще, имеет свое использование. Блоки не отмечены для определенной цели, однако я испытал затруднения за исключениями памяти, особенно за Microsoft. Блок DirectX.AudioVideoPlayback.
Phidgets - В зависимости от того, какую библиотеку Вы загружаете и когда, она может или не может быть отмечена как 32-разрядная только. Текущая версия (11/8/07) отмечена как таковая, и так требует, чтобы 32-разрядный процесс разместил его. Самый легкий способ определить, предназначены ли исполняемый файл или блок на определенную платформу, состоит в том, чтобы использовать corflags приложение. Для использования этого откройте Visual Studio Command Prompt из Меню "Пуск" и выполните его против блока, который Вы хотите проверить.
Самый легкий способ определить, предназначены ли исполняемый файл или блок на определенную платформу, состоит в том, чтобы использовать corflags приложение. Для использования этого откройте Visual Studio Command Prompt из Меню "Пуск" и выполните его против блока, который Вы хотите проверить.