AspNet Core AttributeRouting не обнаруживает маршруты, если запуск находится в другой сборке

Question

У меня есть сценарий, в котором у нас есть «стандартизированный запуск» для многих небольших веб-сайтов AspNet Core.

На первый взгляд очевидное решение для достижения этой цели состоит в том, чтобы преобразовать класс Startup.cs в отдельную общую сборку (какInfrastructure.Web.Core.Startup).Затем каждый небольшой сайт AspNet Core ссылается на общую сборку и вместо этого использует этот класс запуска:

        public static Microsoft.AspNetCore.Hosting.IWebHostBuilder CreateWebHostBuilder( string[] args )
        {
            return new WebHostBuilder()
                   .UseKestrel()
                   .ConfigureServices( collection => { } )
                   .UseContentRoot( System.IO.Directory.GetCurrentDirectory() )
                   .UseStartup<Infrastructure.Web.Core.Startup>(); //.UseStartup<Startup>();
        }

Каким-то образом это нарушает маршрутизацию атрибутов в том смысле, что маршруты не попадают.Нет ошибок, но нет маршрутизации. В тот момент, когда я копирую класс обратно в проект веб-сайта (с тем же кодом), он снова работает .

В качестве теста, если я обертываю класс Startup.cs в общей библиотекев локальном классе запуска (как показано ниже) он также работает:

    public class Startup
    {
        private readonly Infrastructure.Web.Core.Startup _startup;

        public Startup( IConfiguration configuration )
        {
            _startup = new Infrastructure.Web.Core.Startup( configuration );
        }

        public IConfiguration Configuration => _startup.Configuration;

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices( IServiceCollection services )
        {
            _startup.ConfigureServices( services );
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure( IApplicationBuilder app, IHostingEnvironment env )
        {
            _startup.Configure( app, env );
        }
    }

Если мне нужно было сделать предположение, возможно, это как-то связано с внедрением зависимости.

У кого-нибудь есть предложения?

К вашему сведению: он использует типичные проекты AspNet Core 2.1

ОБНОВЛЕНИЕ Кстати, если я использую наследование, это тоже работает, нопроизводный класс должен находиться в том же проекте, что и веб-сайт.Я думаю, это кажется очевидным, но я решил включить эту информацию для полноты:

    public class Startup : Infrastructure.Web.Core.Startup
    {
        public Startup( IConfiguration configuration ) : base(configuration)
        {
        }
    }

Answer 1

Вы можете исправить это, добавив следующую инструкцию к вашим службам в вашем методе Startup.cs.

services.AddApplicationPart(typeof(AnTypeInTheOtherAssembly).Assembly);

Это скажет Обнаружению View / Controller Discovery также проверить наличие нового местоположения.Ваш проект, который содержит файл Startup.cs, будет запускным проектом, а все остальные будут просто ссылками и библиотеками или аналогичными.

Начиная с .Net Core 3 вы можете использовать что-то под названием Razor Class Libraries, см. MSDN .Это автоматически добавит ваши контроллеры и представления в обнаружение, оно также будет иметь поддержку отладки и будет работать так же, как и обычная библиотека классов.