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


S>> То есть твое утверждение, что " в рамках непосредственно C# такое и вовсе нереализуемо "
S>>Это ложь. Это не реализуемо в рамках конкретной реализации EF. Но никак не языка.

EP>Так я же говорю про "непосредственно C#", а не какие-либо внешние утилиты.
То есть например если это будет сделано в компиляторе .Net Native это внешняя утилита?
Она кстати использует Компилятор С++
https://rsdn.ru/forum/flame.comp/6497386.1

Автор: Serginio1
Дата: 10.07.16

.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.

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


S>> То есть твое утверждение, что " в рамках непосредственно C# такое и вовсе нереализуемо "
S>>Это ложь. Это не реализуемо в рамках конкретной реализации EF. Но никак не языка.

EP>Так я же говорю про "непосредственно C#", а не какие-либо внешние утилиты.
То есть например если это будет сделано в компиляторе .Net Native это внешняя утилита?
Она кстати использует Компилятор С++
https://rsdn.ru/forum/flame.comp/6497386.1

Автор: Serginio1
Дата: 10.07.16

.NET Native использует то же сервер, что и компилятор C++, который оптимизирован для статических сценариев предварительной компиляции.

Проблема динамического компилятора в том, что он не оптимизирует код.

При работе с провайдером ему подается ET которое он может скомпилировать и закэшировать.
То, что можно в динамике, можно сделать и в статике со статическим ET.

С заранее известному провайдеру можно пойти двумя способами.
1. Трансформация IL кода. Разобрав существующий IL код и встретив IQueryable, можно получить статическое ET скормить его провайдеру и получить IL код и заменить его.
2. Например можно создать для .Net Native расширения которые будут сразу компилировать.
Здесь проблема не в языке, а в компиляторе.