Здравствуйте, ·, Вы писали:

A>>1. /out можно не указывать.
A>>2. «Имя файла не влияет на работоспособность программы».
A>>3. Файл всегда можно переименовать.
A>>Зачем тогда опция?
·>Эта опция относится непосредственно к процессу компиляции. Компилятор должен куда-то класть свой вывод, вариантов нет. Обсуждаемый флажок никакого отношения к компиляции не имеет, а влияет только на работоспособность на последнем этапе жизненного цикла проекта — запуск в системе пользователя.

/out никакого отношения к процессу компиляции не имеет. Компилятору всё равно, как называется конечный файл. Опция опциональна, указывать не требуется, т.к. есть значение по умолчанию. /platform тоже не имеет отношения к процессу компиляции, компилятору всё равно, что там указано. Опция также не требуется, т.к. есть значение по умолчанию.

A>>>>А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать?
A>>·>У меня есть две длл, под обе intel платформы, но нет под ARM/Itanium. Шо делать?
A>>Раз программа сама разрешает свои зависимости => AnyCPU.
·>Что значит сама?

Выбирает и подгружает нужную версию нативной dll в рантайме. Или разработчик озаботился как в Яве лаунчером в виде exe/bat, и подопытной программе уже на момент старта подсовываются правильные версии зависимостей.

·>Почему нельзя всегда самой? Зачем эти частные случаи?

Для удобства. Чтоб не ручками, а само автоматически.

·>Чем поддержка одной платформы из четырёх принципиально отличается от поддержки двух платформ из четырёх?

Когда нативные библиотеки, от которых ты зависишь, существует более чем под одну платформу, тебе в любом случае нужен какой-то ручной механизм разрешения зависимостей. Когда зависимости существуют только под одну платформу, то писать ручной механизм нет смысла, т.к. не из чего выбирать.

Здравствуйте, ·, Вы писали:

A>>1. /out можно не указывать.
A>>2. «Имя файла не влияет на работоспособность программы».
A>>3. Файл всегда можно переименовать.
A>>Зачем тогда опция?
·>Эта опция относится непосредственно к процессу компиляции. Компилятор должен куда-то класть свой вывод, вариантов нет. Обсуждаемый флажок никакого отношения к компиляции не имеет, а влияет только на работоспособность на последнем этапе жизненного цикла проекта — запуск в системе пользователя.

/out никакого отношения к процессу компиляции не имеет. Компилятору всё равно, как называется конечный файл. Опция опциональна, указывать не требуется, т.к. есть значение по умолчанию. /platform тоже не имеет отношения к процессу компиляции, компилятору всё равно, что там указано. Опция также не требуется, т.к. есть значение по умолчанию.

A>>>>А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать?
A>>·>У меня есть две длл, под обе intel платформы, но нет под ARM/Itanium. Шо делать?
A>>Раз программа сама разрешает свои зависимости => AnyCPU.
·>Что значит сама?

Выбирает и подгружает нужную версию нативной dll в рантайме. Или разработчик озаботился, как в Яве, лаунчером в виде exe/bat, и подопытной программе уже на момент старта подсовываются правильные версии зависимостей.

·>Почему нельзя всегда самой? Зачем эти частные случаи?

Для удобства. Чтоб не ручками, а само автоматически.

·>Чем поддержка одной платформы из четырёх принципиально отличается от поддержки двух платформ из четырёх?

Когда нативные библиотеки, от которых ты зависишь, существует более чем под одну платформу, тебе в любом случае нужен какой-то ручной механизм разрешения зависимостей. Когда зависимости существуют только под одну платформу, то писать ручной механизм нет смысла, т.к. не из чего выбирать.