Що означає ціль Visual Studio “Any CPU”?

496

У мене є певна плутанина, пов’язана з параметрами збірки платформи .NET у Visual Studio 2008.

Що таке ціль компіляції "Будь-який процесор" та які файли створює? Я вивчив виконуваний файл цієї будь-якої збірки процесора і виявив, що вони є x86-виконавчими файлами (хто не побачив, що це буде!). Отже, чи є якась різниця між націленням виконуваного файлу на x86 проти "Будь-якого процесора"?

Ще одна річ, яку я помітив, - це те, що керовані проекти C ++ не мають цієї платформи як опції. Чому так? Чи означає це, що моя підозра про те, що виконувані файли "Будь-який процесор" є звичайними 32-бітовими, - це правильно?

— галети
джерело

4

Ще одна річ , яку слід враховувати при прийнятті рішення , який цільової платформи для використання: якщо мета в проекті запуску є Any CPUі ви на 64 стереосистеми і поновіть бітних ОС, ви втрачаєте здатність до Edit і продовжувати під час налагодження. (Ви ефективно налагоджуєте 64-бітний процес). Ви можете зробити ціль запуску проекту,x86 щоб обійти цю проблему під час налагодження. (Асамблеї, на які посилається проект стартапу, можуть продовжувати орієнтуватися Any CPU.

— Крістіан Діаконеску

8

@ CristiDiaconescu З VS2013 Редагувати та продовжувати зараз можна

— ms007

Я думаю, тут має бути деяка примітка про те, чи є проект додатком чи бібліотекою класів, оскільки встановлення цільового біта для останнього може вплинути на його доступність до споживаних програм залежно від платформи. Я зіткнувся з цим, коли x86бібліотека використовувалась AnyCPUдодатком, де мені довелося встановити, Prefer 32-bitщоб уникнути помилки завантаження.

— SteveCinq

386

Збірка AnyCPU буде JIT на 64-розрядний код при завантаженні в 64-бітний процес і 32-розрядний при завантаженні в 32-бітний процес.

Обмежуючи процесор, ви б сказали: Існує щось, що використовується збіркою (щось, ймовірно, некероване), що вимагає 32 або 64 біта.

— AnthonyWJones
джерело

3

так, як я можу виготовити збірку, яка буде JIT до x64 в C ++?

— Галети

50

Проекти C ++ компілюються в нативний код, тому компілятор JIT не бере участь ... таким чином, ви не можете робити те, що просите.

— cplotts

7

@cplotts: оскільки @galets поставив це запитання 3 місяці тому, навряд чи він побачить вашу відповідь. Використовуйте у своєму коментарі префікс @galets подібно до того, як у мене тут, щоб він отримав сповіщення про вашу відповідь.

— AnthonyWJones

4

@AnthonyWJones Загалом ви маєте рацію, за винятком випадків, коли користувач є ОП питання, як у цьому випадку, оскільки вони отримуватимуть повідомлення про всі коментарі.

— Марк Херд

12

@MarkHurd Насправді в цьому випадку ОП не отримуватиме повідомлення. ОП не отримують повідомлення про коментарі до відповідей, якщо вони спеціально не знаходяться на синтаксисі @. ОП автоматично отримують повідомлення лише про коментарі, додані до їхнього початкового запитання.

— RSW

322

Я думаю, що більшість важливих матеріалів було сказано, але я просто подумав, що я додам одне: Якщо ви компілюєтеся як будь-який процесор і працюєте на платформі x64, ви не зможете завантажити 32-бітні файли DLL, оскільки ваша програма не була запущена в WoW64 , але ті файли DLL повинні працювати там.

Якщо ви компілюєте як x86, система x64 запустить вашу програму в WoW64, і ви зможете завантажити 32-бітні файли DLL.

Тому я думаю, що вам слід вибрати "Будь-який процесор", якщо ваші залежності можуть працювати в будь-якому середовищі, але вибрати x86, якщо у вас є 32-бітні залежності. Ця стаття від Microsoft трохи пояснює це:

/ CLRIMAGETYPE (Вкажіть тип зображення CLR)

Між іншим, ця інша документація Microsoft погоджується, що x86 зазвичай є більш портативним вибором:

Вибір x86 - це, як правило, найбезпечніша конфігурація пакету програм, оскільки він працюватиме майже на кожному пристрої. На деяких пристроях пакет програм із конфігурацією x86 не працюватиме, як-от Xbox або деякі пристрої IoT Core. Однак для ПК пакет x86 - це найбезпечніший вибір і має найбільший обсяг розгортання пристроїв. Значна частина пристроїв Windows 10 продовжує працювати з версією x86 Windows.

— Пол Юнгвірт
джерело

2

Можливо, ви можете відредагувати свою відповідь, щоб сказати, як можна визначити, чи дана DLL лише 32-бітна. Наскільки я знаю, це повинно з’ясувати це. Я думаю, що ми сподіваємось на DLL, які також є "будь-яким процесором", а не лише x86.

— Dan W

+1 важлива відмінність. Було потрібно використовувати 32-бітну залежність (яка не була ідентифікована як така). Не вдалося розібратися у критичних повідомленнях про помилки виконання. На голову змінив цільовий процесор, і він спрацював, але пішов шукати "чому". Буде приємно колись, коли все 64-бітне, а проблеми несумісності здадуться химерними, як зараз 16-бітний проти 32-бітовий.

— Джеральд Девіс

2

@GeraldDavis - я згоден. Іронія полягає в тому, що немає ніяких технологічних причин не в змозі змішати 32-бітну та 64-бітну залежності (лише відсутність товстого шару в CLR), і я розчарувався ще в перші дні .NET, коли побачив біт- ness було ще щось, що слід враховувати при розгортанні (враховуючи, що це VM / JIT, це була б можливість надати трохи більше доданої вартості).

— codenheim

1

@mrjoltcola: Навіть гірше, ніж це те, що Microsoft вирішила з тієї причини, що я не можу зрозуміти, що записи реєстру слід розділити на 32-бітний та 64-бітний всесвіт, навіть якщо вони контролюють такі речі, як кольори екрана, налаштування за замовчуванням тощо.

— supercat

Це відповідь, яку мене шукали ... Дякую!

— Мурат з програми Daminion

52

Ось короткий огляд, який пояснює різні цілі збірки.

З мого власного досвіду, якщо ви хочете створити проект, який працюватиме як на платформах x86, так і на x64, і у вас немає жодних конкретних оптимізацій x64, я би змінив збірку на конкретно сказати "x86".

Причиною цього є те, що іноді ви можете отримати деякі файли DLL, які зіштовхуються, або якийсь код, який закінчується збоєм WoW в середовищі x64. Конкретно вказавши x86, операційна система x64 буде розглядати додаток як чистий додаток x86 і гарантуватиме, що все працює безперебійно.

— Діллі-О
джерело

37

Що може бути жахливо, якщо ви пишете для серверного середовища та хочете, щоб ваша програма могла використовувати більше 2 Гб пам'яті. Ви також відмовляєтесь від будь-яких оптимізацій JIT x64, які колись можуть зійти.

— Остін Харріс

Кількість проблем із виконанням, які у мене виникли з компіляціями AnyCPU, - це все обґрунтування, яке мені потрібно було припинити використовувати його як варіант складання, якщо хтось не попросив явно посилати бінарні файли, які працюють на обох. Я ні в кого не запитував бінарні файли x86 понад x64 протягом більше 10 років.

— kayleeFrye_onDeck

2

"Конкретно вказавши x86, операційна система x64 буде розглядати додаток як чистий додаток x86 і переконайтесь, що все працює безперебійно." - Вибачте, я не згоден. Операційна система x64 все одно запустить ваш додаток x86 всередині WOW64

— Mandeep Janjua

Це лише погана порада тому, хто не повністю розуміє вплив, який він матиме. @AustinHarris дає чудовий приклад. Уявіть, що процес роботи в Інтернеті обмежений лише кількома ГБ оперативної пам’яті (мені нещодавно доводилося стикатися з цим у виробництві).

— rgoliveira

47

Перегляньте пояснену статтю Visual Studio .NET Platform Target .

Налаштування за замовчуванням "Будь-який процесор" означає, що збірка буде виконуватись на центральному процесорі, на якому вона зараз працює. Це означає, що він працюватиме як 64-розрядний на 64-бітній машині та 32-розрядний на 32-розрядній машині. Якщо збірка викликається з 64-розрядної програми, вона буде виконуватись як 64-бітна збірка тощо.

Повідомлялося, що вищезазначене посилання було розірвано, тому ось ще одна стаття з подібним поясненням: Що дійсно означає AnyCPU As. NET 4.5 та Visual Studio 11

— DCNYAM
джерело

1

Посилання розірвано - перехід до припаркованого домену зараз.

— Джон Адамс

Я додав посилання на другу статтю з подібною інформацією. Я залишив перше посилання на випадок, якщо домен коли-небудь повторно активується.

— DCNYAM

45

Кредит до книги "CLR через C #" , див. Це:

— Іван
джерело

3

Це найточніша відповідь станом на 06.09.2018 та VS 15.8.0

— Райкол Амаро

39

"Будь-який процесор" означає, що при запуску програми .NET Framework визначить, на основі біта ОС, чи запускати програму в 32 бітах або 64 бітах.

Існує різниця між x86 та будь-яким процесором : у системі x64 ваш виконуваний файл, складений для X86, працюватиме як 32-бітний виконуваний файл.

Що стосується ваших підозр, просто перейдіть до командного рядка Visual Studio 2008 та виконайте наступне.

dumpbin YourProgram.exe /headers

Це підкаже вам шматочок вашої програми, а також ще багато іншого.

— AngryHacker
джерело

7

Якщо він вбудований у "будь-який процесор", він відображатиметься як 32-бітний у заголовках дампбіну.

— Кірбінатор

34

Будь-який процесор означає, що він буде працювати на будь-якій платформі. Це тому, що керований код схожий на Java. Подумайте про це як про компільований байтовий код, який інтерпретується .NET Framework під час виконання.

У C ++ немає цієї опції, оскільки вона компілюється з машинним кодом, який залежить від платформи.

— Адам Теген
джерело

12

+1 для відповіді на ту частину питання, яку ніхто інший не робив (про проекти C ++, які не мають AnyCPU як варіант).

— cplotts

C ++ / CLI можна компілювати в код IL без будь-якого машинного коду (/ clr: чистий). Але sizeof (void *) все ще має бути констатою часу компіляції в C ++; тож навіть коли немає машинного коду, ви все одно не можете створити двійковий файл, який одночасно працюватиме на 32-бітних та 64-бітних.

— Даніель

5

Рекомендую прочитати цю публікацію .

При використанні AnyCPU семантика така:

Якщо процес працює в 32-бітній системі Windows, він працює як 32-бітний процес. CIL компілюється в машинний код x86.

Якщо процес працює в 64-бітній системі Windows, він працює як 32-бітний процес. CIL компілюється в машинний код x86.

Якщо процес працює в системі Windows ARM, він працює як 32-бітний процес. CIL складається з машинного коду ARM.

— mamczas
джерело

8

Тільки якщо вибрано "Віддати перевагу 32-бітовому".

— Флоріан Зима

Що за замовчуванням з Visual Studio 11

— Moerwald

@Moerwald Я вважаю, що виправлена помилка. Якщо ви читаєте публікацію mamczas, на яку посилається, автор пише: "у поточному інтерфейсі Visual Studio" Віддавайте перевагу 32-розрядному "залишається сірим і не перевіреним, де в дійсності це включено ..."; У моїй версії VS (15.8.0) опція все ще є сірою та невірно встановленою, проте вона працює як очікувалося (прапор 32BITPREF = ЛОЖКА у розділі CorFlags у складеному складі)

— Raikol Amaro

-1

Ось як я це зробив у Visual Studio 2017:

У досліднику Solution
Клацніть правою кнопкою миші на своєму проекті
Клацніть на "Властивості"
Клацніть на "Створити"
Вимкніть опцію "Віддати перевагу 32-бітовій"
І ви можете вибрати "x64" з цілі Платформи.

— М. Фавад Сурош
джерело

Ця відповідь поза темою.

— Йонас