daohualiuxiang
/
AspNetCore.Docs
mirror of https://github.com/dotnet/AspNetCore.Docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
AspNetCore.Docs/aspnetcore/mvc/advanced/app-parts.md

6.9 KiB
Raw Blame History

title author description keywords ms.author manager ms.date ms.topic ms.assetid ms.technology ms.prod uid
Application Parts ardalis ASP.NET Core, riande wpickett 1/4/2017 article b355a48e-a15c-4d58-b69c-899963613a98 aspnet asp.net-core mvc/extensibility/app-parts

Application Parts

View or download sample code

An Application Part is an abstraction over the resources of an application, from which MVC features like controllers, view components, or tag helpers may be discovered. One example of an application part is an AssemblyPart, which 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 MVC app. The main use case for application parts is to allow you to configure your app to discover (or avoid loading) MVC features from an assembly.

Introducing Application Parts

MVC apps load their features from application parts. In particular, the AssemblyPart class represents an application part that is backed by an assembly. You can use these classes to discover and load MVC features, such as controllers, view components, tag helpers, and razor compilation sources. The ApplicationPartManager is responsible for tracking the application parts and feature providers available to the MVC app. You can interact with the ApplicationPartManager in Startup when you configure MVC:

// create an assembly part from a class's assembly
var assembly = typeof(Startup).GetTypeInfo().Assembly;
services
	.AddMvc()
	.AddApplicationPart(assembly);

// OR
var assembly = typeof(Startup).GetTypeInfo().Assembly;
var part = new AssemblyPart(assembly);
services
    .AddMvc()
    .ConfigureApplicationPartManager(apm => p.ApplicationParts.Add(part));

By default MVC will search the dependency tree and find controllers (even in other assemblies). To load an arbitrary assembly (for instance, from a plugin that isn't referenced at compile time), you can use an application part.

You can use application parts to avoid looking for controllers in a particular assembly or location. You can control which parts (or assemblies) are available to the app by modifying the ApplicationParts collection of the ApplicationPartManager. The order of the entries in the ApplicationParts collection is not important. It is important to fully configure the ApplicationPartManager before using it to configure services in the container. For example, you should fully configure the ApplicationPartManager before invoking AddControllersAsServices. Failing to do so, will mean that controllers in application parts added after that method call will not be affected (will not get registered as services) which might result in incorrect bevavior of your application.

If you have an assembly that contains controllers you do not want to be used, remove it from the ApplicationPartManager:

services.AddMvc()
    .ConfigureApplicationPartManager(p =>
    {
        var dependentLibrary = p.ApplicationParts
            .FirstOrDefault(part => part.Name == "DependentLibrary");
        if (dependentLibrary != null)
        {
           p.ApplicationParts.Remove(dependentLibrary);
        }
    })

In addition to your project's assembly and its dependent assemblies, the ApplicationPartManager will include parts for Microsoft.AspNetCore.Mvc.TagHelpers and Microsoft.AspNetCore.Mvc.Razor by default.

Application Feature Providers

Application Feature Providers examine application parts and provide features for those parts. There are built-in feature providers for the following MVC features:

Feature providers inherit from IApplicationFeatureProvider<T>, where T is the type of the feature. You can implement your own feature providers for any of MVC's feature types listed above. The order of feature providers in the ApplicationPartManager.FeatureProviders collection can be important, since later providers can react to actions taken by previous providers.

Sample: Generic Controller Feature

By default, ASP.NET Core MVC ignores generic controllers (for example, SomeController<T>). This sample uses a controller feature provider that runs after the default provider and adds generic controller instances for a specified list of types (defined in EntityTypes.Types):

[!code-csharpMain]

The entity types:

[!code-csharpMain]

The feature provider is added in Startup:

services.AddMvc()
        .ConfigureApplicationPartManager(p => 
			p.FeatureProviders.Add(new GenericControllerFeatureProvider()));

By default, the generic controller names used for routing would be of the form GenericController`1[Widget] instead of Widget. The following attribute is used to modify the name to correspond to the generic type used by the controller:

[!code-csharpMain]

The GenericController class:

[!code-csharpMain]

The result, when a matching route is requested:

image

Sample: Display Available Features

You can iterate through the populated features available to your app by requesting an ApplicationPartManager through dependency injection and using it to populate instances of the appropriate features:

[!code-csharpMain]

Example output:

image