AspNetCore.Docs/aspnetcore/mvc/advanced/app-parts.md

7.0 KiB

title author description ms.author ms.date uid
Application Parts in ASP.NET Core rick-anderson Share controllers, view, Razor Pages and more with Application Parts in ASP.NET Core riande 05/14/2019 mvc/extensibility/app-parts

Share controllers, views, Razor Pages and more with Application Parts in ASP.NET Core

By Rick Anderson

View or download sample code (how to download)

An Application Part is an abstraction over the resources of an app. Application Parts allow ASP.NET Core to discover controllers, view components, tag helpers, Razor Pages, razor compilation sources, and more. AssemblyPart is an Application part. AssemblyPart encapsulates an assembly reference and exposes types and compilation references.

Feature providers work with application parts to populate the features of an ASP.NET Core app. The main use case for application parts is to configure an app to discover (or avoid loading) ASP.NET Core features from an assembly. For example, you might want to share common functionality between multiple apps. Using Application Parts, you can share an assembly (DLL) containing controllers, views, Razor Pages, razor compilation sources, Tag Helpers, and more with multiple apps. Sharing an assembly is preferred to duplicating code in multiple projects.

ASP.NET Core apps load features from xref:System.Web.WebPages.ApplicationPart. The xref:Microsoft.AspNetCore.Mvc.ApplicationParts.AssemblyPart class represents an application part that's backed by an assembly.

Load ASP.NET Core features

Use the ApplicationPart and AssemblyPart classes to discover and load ASP.NET Core features (controllers, view components, etc.). The xref:Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartManager tracks the application parts and feature providers available. ApplicationPartManager is configured in Startup.ConfigureServices:

[!code-csharp]

The following code provides an alternative approach to configuring ApplicationPartManager using AssemblyPart:

[!code-csharp]

The preceding two code samples load the SharedController from an assembly. The SharedController is not in the application's project. See the WebAppParts solution sample download.

Include views

To include views in the assembly:

Prevent loading resources

Application parts can be used to avoid loading resources in a particular assembly or location. Add or remove members of the xref:Microsoft.AspNetCore.Mvc.ApplicationParts collection to hide or make available resources. The order of the entries in the ApplicationParts collection isn't important. Configure the ApplicationPartManager before using it to configure services in the container. For example, configure the ApplicationPartManager before invoking AddControllersAsServices. Call Remove on the ApplicationParts collection to remove a resource.

The following code uses xref:Microsoft.AspNetCore.Mvc.ApplicationParts to remove MyDependentLibrary from the app: [!code-csharp]

The ApplicationPartManager includes parts for:

  • The app's assembly and dependent assemblies.
  • Microsoft.AspNetCore.Mvc.TagHelpers.
  • Microsoft.AspNetCore.Mvc.Razor.

Application feature providers

Application feature providers examine application parts and provide features for those parts. There are built-in feature providers for the following ASP.NET Core features:

Feature providers inherit from xref:Microsoft.AspNetCore.Mvc.ApplicationParts.IApplicationFeatureProvider`1, where T is the type of the feature. Feature providers can be implemented for any of the previously listed feature types. The order of feature providers in the ApplicationPartManager.FeatureProviders can impact run time behavior. Later added providers can react to actions taken by earlier added providers.

Generic controller feature

ASP.NET Core ignores generic controllers. A generic controller has a type parameter (for example, MyController<T>). The following sample adds generic controller instances for a specified list of types:

[!code-csharp]

The types are defined in EntityTypes.Types:

[!code-csharp]

The feature provider is added in Startup:

[!code-csharp]

Generic controller names used for routing are of the form GenericController`1[Widget] rather than Widget. The following attribute modifies the name to correspond to the generic type used by the controller:

[!code-csharp]

The GenericController class:

[!code-csharp]

For example, requesting a URL of https://localhost:5001/Sprocket results in the following response:

Hello from a generic Sprocket controller.

Display available features

The features available to an app can be enumerated by requesting an ApplicationPartManager through dependency injection:

[!code-csharp]

The download sample uses the preceding code to display the app features:

Controllers:
    - FeaturesController
    - HomeController
    - HelloController
    - GenericController`1
    - GenericController`1
Tag Helpers:
    - PrerenderTagHelper
    - AnchorTagHelper
    - CacheTagHelper
    - DistributedCacheTagHelper
    - EnvironmentTagHelper
    - Additional Tag Helpers omitted for brevity.
View Components:
    - SampleViewComponent