Какой код на самом деле работает в веб-приложении .NET Core в этом случае?

Контекст

VS 2019, .NET Core 3 Preview 5. Я создал совершенно новое веб-приложение ASP MVC. Теперь изучаем код StartUp:

// ...
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
//...

Когда я пытаюсь увидеть, что делают эти методы расширения, я иду к источнику (в моем случае Ctrl + щелчок, который вызывает декомпилятор JetBrain), я получаю это:

// Decompiled with JetBrains decompiler
// Type: Microsoft.AspNetCore.Builder.AuthAppBuilderExtensions
// Assembly: Microsoft.AspNetCore.Authentication, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
// MVID: A1CE531C-37CE-4C8A-B143-24C2AC9CFE19
// Assembly location: C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\3.0.0-preview5-19227-01\ref\netcoreapp3.0\Microsoft.AspNetCore.Authentication.dll

namespace Microsoft.AspNetCore.Builder
{
  /// <summary>
  /// Extension methods to add authentication capabilities to an HTTP application pipeline.
  /// </summary>
  public static class AuthAppBuilderExtensions
  {
    /// <summary>
    /// Adds the <see cref="T:Microsoft.AspNetCore.Authentication.AuthenticationMiddleware" /> to the specified <see cref="T:Microsoft.AspNetCore.Builder.IApplicationBuilder" />, which enables authentication capabilities.
    /// </summary>
    /// <param name="app">The <see cref="T:Microsoft.AspNetCore.Builder.IApplicationBuilder" /> to add the middleware to.</param>
    /// <returns>A reference to this instance after the operation has completed.</returns>
    public static IApplicationBuilder UseAuthentication(
      this IApplicationBuilder app)
    {
      throw null;
    }
  }
}

Вопрос

Когда я отлаживаю код, я не получаю Exception, поэтому кажется, что код не работает. Мой вывод, что проект ссылается на фиктивные пустые сборки (см. строку комментария // Assembly location: C:\Program Files... в декомпилированном исходном коде), но я не понимаю механизма, почему во время выполнения будут загружены другие сборки?

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


person g.pickardou    schedule 08.05.2019    source источник
comment
Вы отлаживаете декомпилированный код, как описано здесь: stackoverflow.com/a/32788309/3212610?   -  person AirLancer    schedule 08.05.2019
comment
@JohanP Декомпилятор правильный, я буквально перешел к этой сборке (см. Комментарий о расположении сборки в декомпилированном исходном коде), и Reflector также декомпилирует все методы, чтобы выдать null. Вопрос в том, что это за фиктивные сборки, и что это за механизм, который гарантирует, что во время выполнения будут загружаться не эти муляжи, а настоящие реализации (и откуда?)   -  person g.pickardou    schedule 08.05.2019
comment
Это эталонные сборки. Предназначен для компиляции, а не для запуска. Реализация находится в Microsoft.AspNetCore.Authentication.dll в вашем каталоге bin.   -  person CodeCaster    schedule 08.05.2019
comment
См. также папку stackoverflow.com/questions/9701135/, github.com/dotnet /docs/issues/2638   -  person CodeCaster    schedule 08.05.2019
comment
@CodeCaster: Спасибо, ты прав. Все еще не ясно а) какой смысл в этих фиктивных эталонных сборках, почему мы не компилируем с реальными? б) Зачем Resharper декомпилирует эти пустышки, когда инструментарию сборки понятно, какие конкретно другие выводить, так и Resharper должно быть...   -  person g.pickardou    schedule 08.05.2019
comment
@g.pickardou g.pickardou, если вы ждете, что R # будет умным и последовательным в своих действиях, я могу только сказать вам, что жду много лет.   -  person springy76    schedule 29.05.2019
comment
@springy76: я понимаю это, поэтому я открыт для любого альтернативного решения, которое направляет меня к источнику в описанном случае.   -  person g.pickardou    schedule 29.05.2019
comment
@CodeCaster можно ли указать декомпилятору открывать не ref dll, а src dll?   -  person Legends    schedule 01.10.2019