Ребят, наступил на грабли и сам поборол проблему, но думаю будет полезно всем.
Итак, есть неуклюжий .NET, созданный доблестными мелкокодерами, учащими нас модульности, принципам SOLID и т.п.;
Допустим, есть задача "на лету" скомпилять C# код, в котором используются новомодные фичи (напр., pattern matching). Простой и везде доступный код...

var csprovider = new CSharpCodeProvider();
var par = new CompilerParameters { GenerateInMemory = true, CompilerOptions = options };
par.ReferencedAssemblies.Add("Microsoft.CSharp.dll");
par.ReferencedAssemblies.Add("System.Core.dll");
var res = csprovider.CompileAssemblyFromSource(par, code);
return res.CompiledAssembly;

...работать не будет. Как не будет он работать и с очевидным параметром:

var csprovider = new CSharpCodeProvider(new Dictionary<string, string> {
    ["LangVersion"] = "8.0",
});

А грабля кроется в факте, что даже в нововышедшем FW 4.8 вы НЕ МОЖЕТЕ использовать свежий компилятор! Последняя доступная версия в этом FW — 5.0; Хотя казалось бы, а нафига его вообще выпускать, если он недоступен стандартными средствами! Даже мешочник с Павелецкого вокзала понимает, что FW, CSC и VS — это три разные вещи, проектировка которых просто обязана была предусматривать полную заменяемость и сочетаемость разных версий. Оставим этот траходром на совести тех, кто ещё долго будет нырять в этом болоте. Хак для работы (именно хак, а не очевидная опция) заключается в двух параметрах:

var csprovider = new CSharpCodeProvider(new Dictionary<string, string> {
    ["CompilerDirectoryPath"] = @"c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn",
});
options += " -langversion:8.0 ";

И тогда, достатый из недр студии 2019, новый компилятор позволит вам все фичи.

PS
Я не понимаю, в чём вообще заключается связь между гемороем собеседований в этот распупыренный Мелкософт и теми лоботрясами, что проектируют в нём продукты?! Такую похабщину может проектировать вообще любой стажёр, зашедший в офис MS попить и случайно поступивший на работу. Дикость...

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

K>в нововышедшем FW 4.8 вы НЕ МОЖЕТЕ использовать свежий компилятор!

Можно было не писать гневную простыню, а просто спросить. Современный Розлин обитает на nuget и к фреймвоку не привязан. А то что во фреймвоке лежит что-то старое, за 20 лет там много чего лежит старого, например тип ArrayList.

1. Подключаешь к проекту пакет Microsoft.CodeDom.Providers.DotNetCompilerPlatform
2. Пользуешься:

using System;
using System.CodeDom.Compiler;
using System.Reflection;
using Microsoft.CodeDom.Providers.DotNetCompilerPlatform;

public class Program
{
    private static void Main()
    {
        string code = "class Foo { static void Hello(string name) { System.Console.WriteLine($\"Hello, {name}!\"); } }";

        var assembly = Compile(code);
        var hello = (Action<string>)assembly.GetType("Foo").GetMethod("Hello", BindingFlags.Static | BindingFlags.NonPublic).CreateDelegate(typeof(Action<string>));
        hello("Vasya");

    }

    private static Assembly Compile(string code)
    {
        var codeProvider = new CSharpCodeProvider();
        var parameters = new CompilerParameters { GenerateInMemory = true };
        var compilerResults = codeProvider.CompileAssemblyFromSource(parameters, code);
        return compilerResults.CompiledAssembly;
    }
}

Hello, Vasya!
Press any key to continue . . .

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

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

K>>в нововышедшем FW 4.8 вы НЕ МОЖЕТЕ использовать свежий компилятор!

A>Можно было не писать гневную простыню, а просто спросить. Современный Розлин обитает на nuget и к фреймвоку не привязан. А то что во фреймвоке лежит что-то старое, за 20 лет там много чего лежит старого, например тип ArrayList.

Видать такой человек. 2019-й год пошел, а он до сих пор NuGet-том не пользуктся. Таскает эти бинарники по репам.

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

A>Можно было не писать гневную простыню, а просто спросить.

Зачем спрашивать? Ваш ответ и так сидит в тырнетах и я его читал. Но если вы так и не поняли суть поста, он в следующем: программист НЕ ДОЛЖЕН тратить время на пляски с бубном и пакетами, когда ПРЯМАЯ ЗАДАЧА инструмента — работать в соответствии со спеками. В данном случае, FW предоставляет возможность компиляции кода и меня вообще никаким боком не интересует, что там "старое" и какую черезголовузадерищенскую схему придумали макаки для элементарной задачи "сканпелять".
Есть класс CSharpCodeProvider — всё, на этом все поиски должны быть окончены — создал объект, скомпилил. Наличие каких-то пакетов в клоунском nuget меня не колышет абсолютно. Я не считаю nuget ни полезным, ни безопасным. Хотите — каждый год пляшите под дудку MS — может, они ещё какую-нть ахинею из Линупса притащат. Мы жили 20 лет без пакетов и прекрасно всё писали.

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

D>Видать такой человек. 2019-й год пошел, а он до сих пор NuGet-том не пользуктся.

То, что одна мартышка притащила в 21 век, а остальные надели на себя, не делает скафандр полезнее в джунглях. Nuget — это жалкая пародия MS на "пакетные менеджеры" из Линупса. Причём бесполезная.

D> Таскает эти бинарники по репам.

Какие конкретно "бинари", ты вообще что ли ничего не читал?? Осуждатель...

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

K> придумали макаки для элементарной задачи "сканпелять".

Может пора сменить работу, зачем же так мучаться?

K> Есть класс CSharpCodeProvider — всё
K> Мы жили 20 лет без пакетов и прекрасно всё писали.

Ну так и пишите как 20 лет назад, кто мешает?
Тогда кстати не было класса CSharpCodeProvider. Пишите свой "сканпелятор".

K>Nuget — это жалкая пародия MS на "пакетные менеджеры" из Линупса. Причём бесполезная.

Интересно. Можно поподробней?

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

P>Тогда кстати не было класса CSharpCodeProvider. Пишите свой "сканпелятор".

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

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

K>>Nuget — это жалкая пародия MS на "пакетные менеджеры" из Линупса. Причём бесполезная.

IB>Интересно. Можно поподробней?

Охотно!

1. Я категорически не приемлю во время работы, когда открытый проект лезет куда-то обновляться. Задержки неприемлемы. Несанкционированный выход в сеть тоже.
2. Новый пакет считается "чёрным ящиком", пока он полностью не протестирован. Очевидно, что занимаясь бизнес кодом, у меня нет ресурсов для проверки ещё и "нюгетины". Причём не одной.
3. Нюгетный пакет запросто может иметь breaking changes — никто вам не обязан поддерживать совместимость. А зареференсить нюгетину и потом самому же гемороиться "какая же последняя версия была хорошей" — ДАРОМ НЕ НАДО.
3. Нюгету вообще не место ни в проекте, ни в студии. Это всего лишь "обновлялка", сторонняя приблуда, имеющая 0.00001% пользы во время разработки. Хуже того — нюгет — сугубо .NET-ная фича, она не является "прозрачной" для операционной системы (как в Линупсе) — вы не можете обновить нюгетную либу так, чтобы какой-нть уже скомпиленный проект (уже инсталленый в Program Files) её подцепил.

Далее, если вы берёте сорсы чужого проекта:
Если вы пишете нечто с зависимостями от сторонних либ, хорошим тоном считается сопровождение сорсов этими (скомпиленными) либами. Потому что не редкость, когда сорсы — выкачал, принёс домой/в лес/в Мордор, тырнетов нет, а MS тебе радостно подмигивает нугетными ссылками. Вариант: тырнеты есть, а ссыламеого проекта — нет! Вариант: проект есть, но сделали breaking changes.

Ну и вот накой мне ВСЁ ЭТО надо? Если в рабочем проекте наступило "затишье" и босс сказал проверить — я с удовольствием лично облажу каждый сайт, скачаю либу по своему усмотрению (причём мне сорсы может нафиг не нужны — скачаю бинари) и в отдельной тестовой папке проверю, как работает проект с новыми либами.
Надеюсь, для здравомыслящих я не сказал ничего параноидального — обычные будни программиста, занятого бизнес-кодом, а не гонками за "что поновее".

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

K>Здравствуйте, igor-booch, Вы писали:

K>>>Nuget — это жалкая пародия MS на "пакетные менеджеры" из Линупса. Причём бесполезная.

IB>>Интересно. Можно поподробней?

K>Охотно!

K>1. Я категорически не приемлю во время работы, когда открытый проект лезет куда-то обновляться. Задержки неприемлемы. Несанкционированный выход в сеть тоже.
Поставьте ProGet для кеша в вашей сети и кладите туда только те пакеты, которые вы одобряете.

K>2. Новый пакет считается "чёрным ящиком", пока он полностью не протестирован. Очевидно, что занимаясь бизнес кодом, у меня нет ресурсов для проверки ещё и "нюгетины". Причём не одной.
K>3. Нюгетный пакет запросто может иметь breaking changes — никто вам не обязан поддерживать совместимость. А зареференсить нюгетину и потом самому же гемороиться "какая же последняя версия была хорошей" — ДАРОМ НЕ НАДО.
Ну так не обновляйте пакеты.
Кто вас заставляет ?
Используйте проверенный временем пакет какой-то там давности.

K>3. Нюгету вообще не место ни в проекте, ни в студии. Это всего лишь "обновлялка", сторонняя приблуда, имеющая 0.00001% пользы во время разработки. Хуже того — нюгет — сугубо .NET-ная фича, она не является "прозрачной" для операционной системы (как в Линупсе) — вы не можете обновить нюгетную либу так, чтобы какой-нть уже скомпиленный проект (уже инсталленый в Program Files) её подцепил.
Ну так расскажите всеми миру как надо делать, а там и MS подтянутся.
В добавок к NuGet-у есть ещё One-Get, Paket.
Можете хоть вручную выкачивать все зависимости, благо адрес легко получить.

K>Далее, если вы берёте сорсы чужого проекта:
K>Если вы пишете нечто с зависимостями от сторонних либ, хорошим тоном считается сопровождение сорсов этими (скомпиленными) либами. Потому что не редкость, когда сорсы — выкачал, принёс домой/в лес/в Мордор, тырнетов нет, а MS тебе радостно подмигивает нугетными ссылками. Вариант: тырнеты есть, а ссыламеого проекта — нет! Вариант: проект есть, но сделали breaking changes.
Предлагаете, чтобы все проекты включали в себя все исходники всех зависимостей ?
Проверяйте сначала сборку в виртуалке без интернета, а когда всё соберётся тогда и переносите всё в место без него.

K>Ну и вот накой мне ВСЁ ЭТО надо? Если в рабочем проекте наступило "затишье" и босс сказал проверить — я с удовольствием лично облажу каждый сайт, скачаю либу по своему усмотрению (причём мне сорсы может нафиг не нужны — скачаю бинари) и в отдельной тестовой папке проверю, как работает проект с новыми либами.
K>Надеюсь, для здравомыслящих я не сказал ничего параноидального — обычные будни программиста, занятого бизнес-кодом, а не гонками за "что поновее".
Так не пользуйтесь ничем.
В свой репозиторий положите всё, что надо и настройте сборку как надо.
Держите утилиты для работы с такими репозиториями Awesome Monorepo

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

_NN>Поставьте ProGet...
_NN>Ну так не обновляйте пакеты.
_NN>В добавок к NuGet-у есть ещё One-Get...

NN, ты правда не догоняешь разницу между "купи слона и обходи проблемы" и "вообще не покупать слона"?
Всё просто: слон не нужен. Нюгет тоже.

_NN>Предлагаете, чтобы все проекты включали в себя все исходники всех зависимостей ?

Для массовых перделок достаточно отдельной папки с бинарями-зависимостями. Да чё там, даже какой-нибудь Chromium собирался бы стократ легче, если бы вся шушара поставлялась в DLL-ках и компилился бы только браузерный код.

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

K>NN, ты правда не догоняешь разницу между "купи слона и обходи проблемы" и "вообще не покупать слона"?
K>Всё просто: слон не нужен. Нюгет тоже.
И всё остальное не нужно. И разные компиляторы тоже небось не нужны ?

_NN>>Предлагаете, чтобы все проекты включали в себя все исходники всех зависимостей ?

K>Для массовых перделок достаточно отдельной папки с бинарями-зависимостями. Да чё там, даже какой-нибудь Chromium собирался бы стократ легче, если бы вся шушара поставлялась в DLL-ках и компилился бы только браузерный код.
Это совсем другая проблема и касается она исключительно C и С++.
Принципиальной проблемы распространять "длл-ки" каждой платформы помноженной на все возможные компиляторы с разными версиями совсем нет, но мороки будет предостаточно.

Критикуешь — предлагай.

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

K>1. Я категорически не приемлю во время работы, когда открытый проект лезет куда-то обновляться. Задержки неприемлемы. Несанкционированный выход в сеть тоже.
K>2. Новый пакет считается "чёрным ящиком", пока он полностью не протестирован. Очевидно, что занимаясь бизнес кодом, у меня нет ресурсов для проверки ещё и "нюгетины". Причём не одной.
K>3. Нюгетный пакет запросто может иметь breaking changes — никто вам не обязан поддерживать совместимость. А зареференсить нюгетину и потом самому же гемороиться "какая же последняя версия была хорошей" — ДАРОМ НЕ НАДО.
K>3. Нюгету вообще не место ни в проекте, ни в студии. Это всего лишь "обновлялка", сторонняя приблуда, имеющая 0.00001% пользы во время разработки. Хуже того — нюгет — сугубо .NET-ная фича, она не является "прозрачной" для операционной системы (как в Линупсе) — вы не можете обновить нюгетную либу так, чтобы какой-нть уже скомпиленный проект (уже инсталленый в Program Files) её подцепил.

А как тогда предлагается использовать и обновлять библиотеки? А локальные пакеты даже TFS умеет теперь из коробки, там отдельный таб для этого есть

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

K>Ну и вот накой мне ВСЁ ЭТО надо? Если в рабочем проекте наступило "затишье" и босс сказал проверить — я с удовольствием лично облажу каждый сайт, скачаю либу по своему усмотрению (причём мне сорсы может нафиг не нужны — скачаю бинари) и в отдельной тестовой папке проверю, как работает проект с новыми либами.
K>Надеюсь, для здравомыслящих я не сказал ничего параноидального — обычные будни программиста, занятого бизнес-кодом, а не гонками за "что поновее".

+1

Работаю совершенно таким же образом. Мало того, все нужные бинари лежат в системе контроля версий.

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

K>А зареференсить нюгетину и потом самому же гемороиться "какая же последняя версия была хорошей" — ДАРОМ НЕ НАДО.
...
K> и в отдельной тестовой папке проверю, как работает проект с новыми либами.

Искать "последнюю хорошую версию", создавать папки для теста... может вам git попробовать использовать? Ну и научиться правильно пользоваться NuGet-ом.