Adding EntryAssembly to AddRazorPages/AddControllers*

Background and Motivation

Currently, the default behavior in MVC to load the default ApplicationParts from the entryassembly is rely on the IWebHostEnvironment, however, as reported in the #10611, there are scenarios where the developer wants to just create a new ServiceCollection and configure as needed. This scenario is not supported today because some providers will not be loaded, eg. RazorCompiledItemProvider required in Razor Pages.

The proposal is to add a new overload to all Add* methods available to include Assembly entryAssembly parameter that will be used to load the default ApplicationParts from.

Related:

• #10611

Proposed API

namespace Microsoft.Extensions.DependencyInjection
{
   public static class MvcServiceCollectionExtensions
   {
+      public static IMvcBuilder AddControllers(this IServiceCollection services, Assembly entryAssembly) 
+      {}

+      public static IMvcBuilder AddControllers(this IServiceCollection services, Assembly entryAssembly, Action<MvcOptions>? configure)
+      {}

+      public static IMvcBuilder AddControllersWithViews(this IServiceCollection services, Assembly entryAssembly) 
+      {}

+      public static IMvcBuilder AddControllersWithViews(this IServiceCollection services, Assembly entryAssembly, Action<MvcOptions>? configure)
+      {}

+      public static IMvcBuilder AddRazorPages(this IServiceCollection services, Assembly entryAssembly) 
+      {}

+      public static IMvcBuilder AddRazorPages(this IServiceCollection services, Assembly entryAssembly, Action<RazorPagesOptions>? configure)
+      {}

   }
}

namespace Microsoft.Extensions.DependencyInjection
{
   public static class MvcCoreServiceCollectionExtensions
   {
+      public static IMvcCoreBuilder AddMvcCore(this IServiceCollection services, Assembly entryAssembly)
+      {}
   }
}

Usage Examples

RazorPages

services.AddRazorPages(typeof(Startup).Assembly);

Controllers

services.AddControllers(typeof(Startup).Assembly);

Controllers with views

services.AddControllersWithViews(typeof(Startup).Assembly);

[brunolins16]

@dazinator After some discussion we decided that this API is not totally correct, and we should not add it, right now. What I will add instead, for now, is just a log message informing that no actions were detected and could be caused by a misconfiguration. Also point to this documentation Share controllers, views, Razor Pages and more with Application Parts that explains the usage of AddApplicationPart and ConfigureApplicationPartManager

[dazinator]

I really don’t think we should change the default/idiom here (including the template). Exposing that concept so early and for so many seems like a bad fit. For the vast majority of cases in an app, don’t we just want this to be the app assembly itself, which is the entry assembly already?

In my opinion, the way MVC detects the entry assembly is obscure and hard to find what is going on when errors similar to the reported in the issue happens, however, I think this behavior is there for so many years (i am not sure if the users complained or not before) that I agree with @DamianEdwards that is better no change the default and instead just add the new overload and we maybe we can include in the docs scenarios where they are a

Makes sense - just wanted to mention that if previous method remains, then it may be prudent to throw an exception when that method cannot locate the entry assembly due to missing prerequisite services, perhaps with the error indicating that you can call the new overload to provide the entry assembly as a param explicitly - that should catch cases like the issue linked?