Яка мета Microsoft.Net.Compilers?

У чому важливість цього компілятора? Це треба мати або без чого можна обійтися? Яка мета мати ще один компілятор, чи це просто футуристичний проект? Короткий огляд буде вдячний.

Суть пакета Microsoft.Net.Compilers полягає в тому, що компілятори, що розподіляються з цим пакетом, будуть використовуватися для компіляції вашого проекту, а не компілятор, що постачається з .NET Framework або Visual Studio. Найбільш практична пряма перевага полягає в тому, що це дозволяє вашим проектам використовувати функції C # 6, а потім дозволяє створювати ці проекти в системі, де не встановлений компілятор C # 6, наприклад, на сервері безперервної інтеграції, де ви цього не робите я не хочу встановити повну Visual Studio 2015.

На даний момент для Microsoft.Net.Compilers немає цілей. Це пакет NuGet, який застарів і припинить випуск після Visual Studio 16.5. Існує пакет-наступник Microsoft.Net.Compilers.Toolset. Цей пакет має майже ту ж функціональність, що і Microsoft.Net.Compilers, але працює як з екземплярами .NET Desktop, так і з .NET Core MSBuild.

Попри це Microsoft.Net.Compilers.Toolset не призначений для загального споживання. Цей пакет пропонує два конкретні цілі:

1. Діє як короткостроковий транспортний засіб для розблокування клієнтів, які потрапляють у помилки компілятора. Для таких клієнтів ми можемо використовувати цей пакет, щоб розблокувати їхні сценарії приблизно через годину після того, як ми об’єднаємо виправлення у сховище Roslyn. Це служить мостом, доки виправлення не потрапить до відповідного випуску обслуговування Visual Studio або .NET SDK. Коли це трапляється, замовника просять видалити пакет зі свого рішення та покластися на офіційно випущені набори інструментів.
2. Служить механізмом переміщення бінарних файлів між Roslyn та офіційними збірками .NET SDk.

Цей пакет не призначений для загального довгострокового споживання споживачами для їх складання. Я розумію, що деякі клієнти вирішили це зробити, але таке використання також не підтримується. Пакет може регулярно спричиняти перерви, беручи залежності від нових версій MSBuild або завдань / цілей у .NET SDK.

Клієнтам, які хочуть використовувати нові версії компілятора для своїх збірок, натомість рекомендується використовувати один з офіційних дистрибутивів компілятора:

1. Використовуйте SKU Visual Studio Build Tools.
2. Використовуйте .NET SDK

Примітка : Пакет Microsoft.Net.Compilers був офіційно підтриманий як частина пакета Microsoft.CodeDom.Providers.DotNetCompilerPlatform кілька років тому, оскільки це була залежність. Починаючи з версії 2.0, хоча залежність від Microsoft.Net.Compilers була видалена, і тепер вона виглядає як повністю незалежний пакет. У той же час ми перейшли до припинення Microsoft.Net.Compilers, оскільки для нього більше не існує явних випадків використання.

Це означає, що деякі клієнти несподівано опиняються з Microsoft.Net.Compilers у своєму проектному файлі, оскільки він не був видалений, коли Microsoft.CodeDom.Providers.DotNetCompilerPlatform скинув залежність. Порада для таких клієнтів полягає в тому, щоб просто видалити посилання на упаковку. Це вже не потрібно.

Це пакет, який надає компілятори з відкритим кодом C # та Visual Basic з розширеними API для аналізу коду.

Ви можете знайти велику документацію про github:

https://github.com/dotnet/roslyn

Як вже говорили інші, він містить компілятори .NET для C # та VB.NET.

Цікавим аспектом цього пакету є те, що ви можете вказати конкретну збірку компілятора для вашого проекту, включаючи версію, яка ще не надіслана з Visual Studio.

Ми використовуємо це в https://github.com/dotnet/project-system, яка є компонентом Visual Studio з відкритим кодом. Це дозволяє нам використовувати попередні версії компілятора для функцій інтерфейсної мови, які не підтримуються компілятором, що постачається з VS.