Параметры компилятора C#
В этом разделе описаны параметры, интерпретируемые компилятором C#. Параметры сгруппированы в отдельные статьи в зависимости от того, чем они управляют. Это могут быть, например, функции языка, создание кода и выходные данные. Для навигации по параметрам можно воспользоваться оглавлением.
Установка параметров
В проектах .NET параметры компилятора можно задать двумя способами:
-
В файле *. csproj можно добавить свойства MSBuild для любого параметра компилятора в файле *. csproj в формате XML. Имя свойства совпадает с именем параметра компилятора. Значение свойства задает значение параметра компилятора. Например, в следующем фрагменте файла проекта задается свойство LangVersion .
preview
Проекты .NET Framework
Этот раздел относится только к проектам .NET Framework.
Кроме описанных выше способов, для проектов .NET Framework можно задать параметры компилятора с помощью двух дополнительных методов:
- аргументы командной строки для проектов платформа .NET Framework: платформа .NET Framework проекты используют csc.exe , а не для сборки проектов. Аргументы командной строки можно указать в csc.exe для проектов .NET Framework.
- Скомпилированные страницы ASP.NET. Проекты .NET Framework используют раздел файла web.config для компиляции страниц. Для новой системы сборки и проектов ASP.NET Core параметры берутся из файла проекта.
Некоторые параметры компилятора больше не используются в формате для csc.exe и проектов .NET Framework. Они используются в формате для новой системы MSBuild. В этом разделе применяется новый синтаксис. Обе версии приведены в верхней части каждой страницы. Для csc.exe все аргументы указываются после параметра и двоеточия. Например, параметр -doc будет выглядеть так:
-doc:DocFile.xml
Чтобы вызвать компилятор C#, следует ввести имя соответствующего исполняемого файла (csc.exe) в командной строке.
Кроме того, для проектов .NET Framework csc.exe можно запустить из командной строки. Каждый параметр компилятора можно использовать в двух формах записи: -параметр или /параметр. В проектах .NET Framework параметры для компиляции кода программной части указываются в файле web.config. Дополнительные сведения см. в разделе элемент компилятора >.
Если используется окно Командная строка разработчика для Visual Studio, все необходимые переменные среды устанавливаются автоматически. Дополнительные сведения о получении доступа к этому инструменту см. в статье Командная строка разработчика и PowerShell для разработчиков.
csc.exe исполняемый файл обычно находится в папке Microsoft. нет\фрамеворк\ Version в каталоге Windows . Расположение файла может зависеть от конкретной конфигурации компьютера. Если на компьютере установлено несколько версий .NET Framework, будет несколько версий этого файла. Дополнительные сведения о подобных вариантах установки см. в разделе Практическое руководство. Определение установленных версий платформы .NET Framework.
Как удалить csc
Подлинный файл является одним из компонентов программного обеспечения Microsoft .NET Framework, разработанного Microsoft Corporation .
CsC — это аббревиатура от Visual C# [sharp] Command-Line Compiler
Csc.exe — это исполняемый файл (программа) для Windows. Расширение имени файла .exe — это аббревиатура от англ. слова executable — исполнимый. Необходимо запускать исполняемые файлы от проверенных производителей программ, потому что исполняемые файлы могут потенциально изменить настройки компьютера или нанести вред вашему компьютеру. Бесплатный форум с информацией о файлах может помочь вам разобраться является ли csc.exe вирусом, трояном, программой-шпионом, рекламой, которую вы можете удалить, или файл принадлежит системе Windows или приложению, которому можно доверять.
Вот так, вы сможете исправить ошибки, связанные с csc.exe
- Используйте программу Настройщик Windows, чтобы найти причину проблем, в том числе и медленной работы компьютера.
- Обновите программу Visual C# Command Line Compiler. Обновление можно найти на сайте производителя (ссылка приведена ниже).
- В следующих пунктах предоставлено описание работы csc.exe.
Информация о файле csc.exe
Процесс Visual C# Command Line Compiler принадлежит программе Microsoft .NET Framework (версия 4 Client Profile) или Microsoft Visual Studio (версия 2005) или Unity от Microsoft (www.microsoft.com).
Описание: csc.exe не является необходимым для Windows. Файл csc.exe находится в подпапках C:\Windows. Известны следующие размеры файла для Windows 10/11/7 1,972,552 байт (50% всех случаев), 77,888 байт или 77,960 байт.
У файла поставлена цифровая подпись. У процесса нет видимого окна. Поэтому технический рейтинг надежности 10% опасности.
Если вы хотите полностью удалить программу, перейдите в Панель управления ⇒ Программы ⇒ Microsoft .NET Framework 4 Client Profile.
Если csc.exe находится в подпапках «C:\Program Files», тогда рейтинг надежности 100% опасности. Размер файла 78,336 байт. У процесса нет видимого окна. Мнение пользователей: опасно Нет информации о создателе файла. Это скрытый процесс-невидимка. Это не системный процесс Windows.
Вы можете удалить программу Unity, или попросить поставщика программного обеспечения о поддержке. Нажмите на Unity в Панели управления Windows (раздел Программы и компоненты) для удаления.
Важно: Некоторые вредоносные программы маскируют себя как csc.exe, особенно, если они расположены в каталоге c:\windows или c:\windows\system32. Таким образом, вы должны проверить файл csc.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Файл находится в папке C:\Windows\Microsoft.NET\Framework\[версия]. Является компилятором C#. Используется средами разработки для компоновки исполняемого файла. Герман Дмитриев [JGDger] |
его блокировал антиспайваре, вследствие чего ничего не запускалось дальше пустого рабочего стола. |
Используется в среде программирования Visual Studio 2010 в частности для C# |
компилятор для C# shady |
Итого: Средняя оценка пользователей сайта о файле csc.exe: — на основе 5 голосов с 4 отзывами.
42 пользователей спрашивали про этот файл. Один пользователь не поставил рейтинг (указал «я не знаю»). 2 пользователей оценили, как неопасный. 2 пользователей оценили, как кажется неопасным. Один пользователь оценил, как нейтральный.
Лучшие практики для исправления проблем с csc
Аккуратный и опрятный компьютер — это главное требование для избежания проблем с csc. Для этого требуется регулярная проверка компьютера на вирусы, очистка жесткого диска, используя cleanmgr и sfc /scannow, удаление программ, которые больше не нужны, проверка программ, которые запускаются при старте Windows (используя msconfig) и активация Автоматическое обновление Windows. Всегда помните о создании периодических бэкапов, или в крайнем случае о создании точек восстановления.
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
Следующие программы могут вам помочь для анализа процесса csc.exe на вашем компьютере: Security Task Manager отображает все запущенные задания Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записей автозагрузки. Уникальная оценка рисков безопасности указывает на вероятность процесса быть потенциально опасным — шпионской программой, вирусом или трояном. Malwarebytes Anti-Malware определяет и удаляет бездействующие программы-шпионы, рекламное ПО, трояны, кейлоггеры, вредоносные программы и трекеры с вашего жесткого диска.
csc сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
Инструмент ремонта ПК бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Параметры компилятора C#, которые управляют выводом компилятора
Следующие параметры управляют созданием выходных данных компилятора.
MSBuild | csc.exe | Description |
---|---|---|
DocumentationFile | -doc: | Создание XML-файла документации из комментариев /// . |
OutputAssembly | -out: | Указание выходного файла сборки. |
PlatformTarget | -platform: | Указание разрядности ЦП целевой платформы. |
ProduceReferenceAssembly | -refout: | Создание базовой сборки. |
TargetType | -target: | Указание типа выходной сборки. |
DocumentationFile
Параметр DocumentationFile позволяет поместить комментарии из документации в XML-файл. Дополнительные сведения о документировании кода см. в статье Рекомендуемые теги для комментариев документации. Значение указывает путь к выходному XML-файлу. XML-файл содержит комментарии в файлах исходного кода компиляции.
path/to/file.xml
Файл исходного кода, содержащий метод Main или инструкции верхнего уровня, выводится в XML первым. Часто вы предпочтете использовать созданный XML-файл с IntelliSense. Имя XML-файла должно совпадать с именем сборки. XML-файл должен находиться в том же каталоге, что и сборка. Если в проект Visual Studio добавляется ссылка на сборку, XML-файл также будет найден. Дополнительные сведения о создании комментариев к коду см. в статье Вставка XML-комментариев для создания документации. Если при компиляции не используется параметр , file будет содержать теги
Параметр DocumentationFile применяется ко всем файлам в проекте. Чтобы отключить предупреждения, связанные с комментариями документации для определенного файла или раздела кода, используйте директиву #pragma warning.
Этот параметр можно использовать в любом проекте в стиле пакета SDK для .NET. Дополнительные сведения см. в разделе о свойстве DocumentationFile.
OutputAssembly
Параметр OutputAssembly позволяет задать имя выходного файла. Выходной путь указывает на папку, куда помещаются выходные данные компилятора.
folder
Укажите полное имя и расширение файла, который требуется создать. Если не указать имя выходного файла, MSBuild использует имя проекта для указания имени выходной сборки. К проектам со старым стилем применяются следующие правила:
- EXE-файлу будет присвоено имя файла исходного кода, который содержит метод Main или инструкции верхнего уровня.
- DLL-файлы и NETMODULE-файлы берут имя из первого файла исходного кода.
Все модули, созданные в процессе компиляции, будут связаны со сборкой, полученной в результате этого процесса. С помощью ildasm.exe можно просмотреть связанные файлы в манифесте сборки.
Параметр компилятора OutputAssembly обязателен, если требуется установить EXE-файл в качестве целевого для дружественной сборки.
PlatformTarget
Указывает, в какой версии среды CLR может запускаться сборка.
anycpu
- anycpu (по умолчанию) позволяет компилировать сборку для запуска на любой платформе. Если возможно, приложение выполняется как 64-разрядный процесс, а если доступен только 32-разрядный режим, переключается на него.
- anycpu32bitpreferred (по умолчанию) позволяет компилировать сборку для запуска на любой платформе. Приложение выполняется в 32-разрядном режиме в системах, поддерживающих и 64-разрядные, и 32-разрядные приложения. Можно задать этот параметр только для проектов, предназначенных для .NET Framework 4.5 и выше.
- ARM компилирует сборку для выполнения на компьютере с процессором Advanced RISC Machine (ARM).
- ARM64 компилирует сборку для выполнения 64-разрядной средой CLR на компьютере с процессором Advanced RISC Machine (ARM) с поддержкой набора инструкций А64.
- x64 компилирует сборку для запуска в 64-разрядной среде CLR на компьютере, поддерживающем набор инструкций AMD64 или EM64T.
- x86 компилирует сборку для запуска в 32-разрядной среде CLR с архитектурой x86.
- Itanium компилирует сборку для запуска в 64-разрядной среде CLR на компьютере с процессором Itanium.
В 64-разрядной ОС Windows:
- Сборки, скомпилированные с параметром x86, будут выполняться в 32-разрядной среде CLR в подсистеме WOW64.
- Библиотеки DLL, скомпилированные с использованием параметра anycpu, выполняются в той же среде CLR, в которую загружается процесс.
- Исполняемые файлы, скомпилированные с использованием параметра anycpu, выполняются в 64-разрядной среде CLR.
- Исполняемые файлы, скомпилированные с использованием параметра anycpu32bitpreferred, выполняются в 32-разрядной среде CLR.
Параметр anycpu32bitpreferred является допустимым только для исполняемых файлов (.exe). Он используется только с .NET Framework 4.5 и выше. Дополнительные сведения о разработке приложений для запуска в 64-разрядной операционной системе Windows см. в разделе 64-разрядные приложения.
Параметр PlatformTarget можно задать на странице свойств сборки для проекта в Visual Studio.
В .NET Core, .NET 5 и более поздних выпусках параметр anycpu имеет некоторые особенности. Если вы указали параметр anycpu, опубликуйте приложение и выполняйте его только с dotnet.exe x86 или только с dotnet.exe x64. Если вы используете автономные приложения, на этапе dotnet publish упаковывается исполняемый файл для настройки RID.
ProduceReferenceAssembly
Параметр ProduceReferenceAssembly определяет, создает ли компилятор ссылочные сборки.
true
Базовые сборки являются особым типом сборки, которая содержит только минимальный объем метаданных, необходимый для представления общедоступного API-интерфейса библиотеки. Такие сборки включают в себя объявления для всех элементов, которые важны при указании ссылки на сборку в средствах сборки. Базовые сборки исключают все реализации элементов, а также объявления закрытых элементов, не имеющих наблюдаемого влияния на их контракт API. Дополнительные сведения см. в статье Базовые сборки в руководстве по .NET.
Параметры ProduceReferenceAssembly и ProduceOnlyReferenceAssembly являются взаимоисключающими.
Как правило, вам не нужно работать напрямую с файлами эталонной сборки. По умолчанию эталонные сборки создаются в вложенной ref папке промежуточного пути (т. е. obj/ref/ ). Чтобы создать их в выходном каталоге (т. е. bin/ref/ ) в ProduceReferenceAssemblyInOutDir true проекте.
Пакет SDK для .NET 6.0.200 по умолчанию изменил ссылочные сборки из выходного каталога в промежуточный каталог.
TargetType
Параметр компилятора TargetType можно задать в одной из следующих форм:
- library: для создания библиотеки кода. library — это значение по умолчанию.
- exe: для создания EXE-файла.
- module: для создания модуля.
- winexe: для создания программы Windows.
- winmdobj: для создания промежуточного файла .winmdobj.
- appcontainerexe: для создания EXE-файла для приложений Магазина Windows 8.x.
Если вы создаете приложения для .NET Framework и не указываете значение module, этот параметр приводит к помещению манифеста сборки .NET Framework в выходной файл. Дополнительные сведения см. в разделах Сборки в .NET и Общие атрибуты.
library
При каждой компиляции компилятор создает только один манифест сборки. В манифест сборки добавляются сведения обо всех файлах в компиляции. При создании нескольких выходных файлов в командной строке может быть создан только один манифест сборки, который добавляется в первый выходной файл, указанный в командной строке.
При создании сборки можно указать, что код полностью или частично CLS-совместим с атрибутом CLSCompliantAttribute.
библиотека
Параметр library указывает компилятору создавать библиотеку динамической компоновки (DLL), а не исполняемый файл (EXE). Библиотека DLL создается с расширением .dll. Выходной файл получает имя первого входного файла, если только с помощью параметра OutputAssembly не указано иное. При сборке DLL-файла метод Main не требуется.
exe
Параметр exe указывает компилятору создать исполняемое (EXE) консольное приложение. Исполняемый файл создается с расширением ЕХЕ. Используйте параметр winexe для создания исполняемого файла программы Windows. Если не указано иное с помощью параметра OutputAssembly, имя выходного файла совпадает с именем входного файла, который содержит точку входа (метод Main или инструкции верхнего уровня). В файлах исходного кода, который компилируется в EXE-файл, должна содержаться только одна точка входа. Если код содержит несколько классов с методом Main , указать, какой класс содержит метод Main , можно с помощью параметра компилятора StartupObject.
модуль
Этот параметр указывает компилятору не создавать манифест сборки. По умолчанию выходной файл, созданный при компиляции с этим параметром, имеет расширение .netmodule. Файл без манифеста сборки не может быть загружен в среду выполнения .NET. Но его можно включить в манифест сборки с помощью параметра AddModules. Если в рамках одной процедуры компиляции создается несколько модулей, типы internal из одного модуля будут доступны для других модулей, компилируемых вместе с ним. Если код одного модуля ссылается на типы internal в другом модуле, оба модуля нужно включить в манифест сборки с помощью параметра AddModules. Создание модуля в среде разработки Visual Studio не поддерживается.
winexe
Параметр winexe указывает компилятору создать исполняемый файл (EXE) программы Windows. Исполняемый файл создается с расширением ЕХЕ. Программа Windows предоставляет пользовательский интерфейс либо из библиотеки .NET, либо с помощью API-интерфейсов Windows. Воспользуйтесь параметром exe, чтобы создать консольное приложение. Если не указано иное с помощью параметра OutputAssembly, имя выходного файла совпадает с именем входного файла, который содержит метод Main . Один и только один Main метод требуется в файлах исходного кода, скомпилированных в файл .exe. Если код содержит несколько классов с методом Main , указать, какой класс содержит метод Main , можно с помощью параметра StartupObject.
winmdobj
Если используется параметр winmdobj, компилятор создает промежуточный WINMDOBJ-файл, который можно преобразовать в двоичный WINMD-файл среды выполнения Windows. Затем WINMD-файл можно использовать в программах на языках JavaScript и C++ в дополнение к программам, использующим управляемые языки.
Параметр winmdobj сигнализирует компилятору, что необходим промежуточный модуль. Затем WINMDOBJ-файл можно передать с помощью инструмента экспорта WinMDExp для создания файла метаданных Windows (WINCMD-файл). WINMD-файл содержит код из исходной библиотеки и метаданные WinMD, используемые JavaScript, C++ и средой выполнения Windows. Выходные данные файла, скомпилированного с помощью параметра компилятора winmdobj, используются только в качестве входных данных инструментом экспорта WimMDExp (на WINMDOBJ-файл нет прямой ссылки). Выходной файл получает имя первого входного файла, если только не используется параметр OutputAssembly. Метод Main не требуется.
appcontainerexe
Если используется параметр компилятора appcontainerexe, компилятор создает исполняемый файл Windows (EXE-файл), который должен запускаться в контейнере приложения. Этот параметр аналогичен -target:winexe, но предназначен для приложений Магазина Windows 8.x.
Этот параметр устанавливает бит в переносимом исполняемом файле (PE), чтобы обеспечить запуск приложения в контейнере. Если он установлен, при попытке запустить исполняемый файл вне контейнера приложения методом CreateProcess будет возникать ошибка. Выходной файл получает имя входного файла, содержащего метод Main , если только с помощью параметра OutputAssembly не указано иное.
Совместная работа с нами на GitHub
Источник этого содержимого можно найти на GitHub, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.
Компилятор csc.exe
В действительности необходимость в создании крупных приложений с использованием одного лишь компилятора командной строки C# может никогда не возникнуть, тем не менее, важно понимать в общем, как вручную компилировать файлы кода. Существует несколько причин, по которым освоение этого процесса может оказаться полезным:
- Самой очевидной причиной является отсутствие Visual Studio 2010 или какой-то другой графической IDE-среды.
- Работа может выполняться в университете, где использование инструментов для генерации кода и IDE-сред обычно запрещено.
- Планируется применение автоматизированных средств разработки, таких как msbuild.exe, которые требуют знать опции командной строки для используемых инструментов.
- Возникло желание углубить свои познания в C#. В графических IDE-средах в конечном итоге все заканчивается предоставлением компилятору csc.ехе инструкций относительно того, что следует делать с входными файлами кода C#. В этом отношении изучение происходящего «за кулисами» позволяет получить необходимые знания.
Еще одно преимущество подхода с использованием одного лишь компилятора csc.ехе состоит в том, что он позволяет обрести навыки и чувствовать себя более уверенно при работе с другими инструментами командной строки, входящими в состав .NET Framework 4.0 SDK, так как целый ряд важных утилит работает исключительно в режиме командной строки.
Чтобы посмотреть, как создавать .NET-приложение без IDE-среды, давайте построим с помощью компилятора C# и текстового редактора Notepad простую исполняемую сборку по имени TestApplication.exe. Сначала необходимо подготовить исходный код. Откройте программу Notepad (Блокнот), выбрав в меню Start (Пуск) пункт All Programs — Accessories — Notepad (Все программы — Стандартные — Блокнот), и введите следующее типичное определение класса на C#:
using System; class TestApplication < static void Main() < Console.WriteLine("Привет!"); Console.ReadLine(); >>
После окончания ввода сохраните файл под именем TestApplication.cs. Теперь давайте ознакомимся с ключевыми опциями компилятора C#.
Указание целевых входных и выходных параметров
Первым делом важно разобраться с тем, как указывать имя и тип создаваемой сборки (т.е., например, консольное приложение по имени MyShell.exe, библиотека кода по имени MathLib.dll или приложение Windows Presentation Foundation по имени Halo8.ехе). Каждый из возможных вариантов имеет соответствующий флаг, который нужно передать компилятору csc.ехе в виде параметра командной строки.
Обратите внимание, что параметры, передаваемые компилятору командной строки (а также большинству других утилит командной строки), могут сопровождаться префиксом в виде символа дефиса (-) или слеша (/).
Выходные параметры, которые может принимать компилятор C# приведены в следующей таблице:
Параметр | Описание |
---|---|
/out | Этот параметр применяется для указания имени создаваемой сборки. По умолчанию сборке присваивается то же имя, что у входного файла *.сs |
/target:exe | Этот параметр позволяет создавать исполняемое консольное приложение. Сборка такого типа генерируется по умолчанию, потому при создании подобного приложения данный параметр можно опускать |
/target:library | Этот параметр позволяет создавать однофайловую сборку *.dll |
/target:module | Этот параметр позволяет создавать модуль. Модули являются элементами многофайловых сборок |
/target:winexe | Хотя приложения с графическим пользовательским интерфейсом можно создавать с применением параметра /target: ехе, параметр /target: winexe позволяет предотвратить открытие окна консоли под остальными окнами |
Чтобы скомпилировать TestApplication.cs в консольное приложение TestApplication.exe, перейдите в каталог, в котором был сохранен файл исходного кода (с помощью флага cd) и введите следующую команду:
Обратите внимание, что здесь C:\myProject — это путь к папке, в которой хранится файл TestApplication.cs. Так же обратите внимание, что здесь флаг /out не был указан явным образом, поэтому исполняемым файл получит имя TestApplication.ехе из-за того, что именем входного файла является TestApplication. Кроме того, для почти всех принимаемых компилятором C# флагов поддерживаются сокращенные версии написания, наподобие /t вместо /target (полный список которых можно увидеть, введя в командной строке команду csc -?).
Теперь можно попробовать запустить приложение TestApplication.ехе из командной строки, введя имя его исполняемого файла:
Добавление ссылок на внешние сборки
Давайте посмотрим, как скомпилировать приложение, в котором используются типы, определенные в отдельной сборке .NET. Если осталось неясным, каким образом компилятору C# удалось понять ссылку на тип System.Console, вспомните, что во время процесса компиляции происходит автоматическое добавление ссылки на mscorlib.dll (если по какой-то необычной причине нужно отключить эту функцию, следует передать компилятору csc.exe параметр /nostdlib).
Модифицируем приложение TestApplication так, чтобы в нем открывалось окно сообщения Windows Forms. Для этого откройте файл TestApplication.cs и измените его следующим образом:
using System; using System.Windows.Forms; class TestApplication < static void Main() < Console.WriteLine("Привет!"); MessageBox.Show("Привет. "); >>
Далее в командной строке нужно проинформировать компилятор csc.exe о том, в какой сборке содержатся используемые пространства имен. Поскольку применялся класс MessageBox из пространства имен System.Windows.Forms, значит, нужно указать компилятору на сборку System.Windows.Forms.dll, что делается с помощью флага /reference (или его сокращенной версии /r):
Если теперь снова попробовать запустить приложение, то помимо консольного вывода в нем должно появиться еще и окно с сообщением:
Кстати, как поступить, когда необходимо указать csc.exe несколько внешних сборок? Для этого нужно просто перечислить все сборки через точку с запятой. В рассматриваемом примере ссылаться на несколько сборок не требуется, но ниже приведена команда, которая иллюстрирует перечисление множества сборок:
csc /r:System.Windows.Forms.dll;System.Drawing.dll *.cs
Компиляция нескольких файлов исходного кода
В текущем примере приложение TestApp.exe создавалось с использованием единственного файла исходного кода * . cs. Хотя определять все типы .NET в одном файле *.cs вполне допустимо, в большинстве случаев проекты формируются из нескольких файлов *.cs для придания кодовой базе большей гибкости. Чтобы стало понятнее, давайте создадим новый класс и сохраним его в отдельном файле по имени HelloMessage.cs:
// Класс HelloMessage using System; using System.Windows.Forms; class HelloMessage < public void Speak() < MessageBox.Show("Привет!!") ; >>
Изменим исходный класс TestApplication так, чтобы в нем использовался класс этого нового типа:
using System; class TestApplication < static void Main() < Console.WriteLine("Привет!"); HelloMessage v = new HelloMessage(); v.Speak(); >>
Чтобы скомпилировать файлы исходного кода на C# , необходимо их явно перечислить как входные файлы:
В качестве альтернативного варианта компилятор C# позволяет использовать групповой символ (*) для включения в текущую сборку всех файлов *.cs, которые содержатся в каталоге проекта:
Вывод, получаемый после запуска этой программы, идентичен предыдущей программе. Единственное отличие между этими двумя приложениями связано с разнесением логики по нескольким файлам.
Работа с ответными файлами в C#
Как не трудно догадаться, для создания сложного приложения C# из командной строки потребовалось бы вводить утомительное количество входных параметров для уведомления компилятора о том, как он должен обрабатывать исходный код. Для облегчения этой задачи в компиляторе C# поддерживается использование так называемых .
В ответных файлах C# размещаются все инструкции, которые должны использоваться в процессе компиляции текущей сборки. По соглашению эти файлы имеют расширение *.rsp (сокращение от response — ответ). Чтобы посмотреть на них в действии, давайте создадим ответный файл по имени TestApplication.rsp, содержащей следующие аргументы (комментарии в данном случае обозначаются символом #):
# Это ответный файл для примера # TestApplication.exe /r:System.Windows.Forms.dll # Параметры вывода и подлежащие компиляции файлы /target:exe /out:TestApplication.ехе *.cs
Теперь при условии сохранения данного файла в том же каталоге, где находятся подлежащие компиляции файлы исходного кода на C#, все приложение можно будет создать следующим образом (обратите внимание на применение символа @):
В случае необходимости допускается также указывать и несколько ответных *.rsp файлов в качестве входных параметров (например, csc @FirstFile.rsp @SecondFile.rsp @ThirdFile.rsp). При таком подходе, однако, следует иметь в виду, что компилятор обрабатывает параметры команд по мере их поступления. Следовательно, аргументы командной строки, содержащиеся в поступающем позже файле *.rsp, могут переопределять параметры из предыдущего ответного файла.
Последним моментом, связанным с ответными файлами, о котором необходимо упомянуть, является то, что с компилятором C# ассоциирован ответный файл csc.rsp, который используется по умолчанию и размещен в том же самом каталоге, что и файл csc.ехе (обычно это С:\Windows\Microsoft. NET\Framework\ , где на месте элемента идет номер конкретной версии платформы). Открыв файл csc.rsp в программе Notepad (Блокнот), можно увидеть, что в нем с помощью флага /r: указано множество сборок .NET, в том числе различные библиотеки для разработки веб-приложений, программирования с использованием технологии LINQ и обеспечения доступа к данным и прочие ключевые библиотеки (помимо, конечно же, самой главной библиотеки mscorlib.dll):
При создании программ на C# с применением csc.ехе ссылка на этот ответный файл добавляется автоматически, даже когда указан специальный файл *.rsp. Из-за наличия такого ответного файла по умолчанию, рассматриваемое приложение TestApplication.ехе можно скомпилировать и c помощью следующей команды (поскольку в csc.rsp уже содержится ссылка на System.Windows.Forms.dll):
Стоит отметить, что в случае добавления с помощью опции /r ссылок на сборки, которые на самом деле не используются, компилятор их проигнорирует. Поэтому беспокоиться по поводу «разбухания кода» не нужно.