ASP.NET Core中类库被自动标记为ApplicationPart的解决方案

问题背景

在ASP.NET Core Razor应用程序开发中，开发人员经常会遇到一个典型问题：当主应用程序引用其他类库项目时，这些类库会被自动标记为[assembly: ApplicationPart]属性。这一机制原本是为了支持MVC和Razor Pages的发现机制，但在某些特定场景下反而会带来运行时问题。

问题现象

在一个典型的ASP.NET Core Razor应用程序结构中：

• 主应用程序(Sample.RazorApp)包含所有Razor页面
• 引用了两个类库(ClassLibrary.A和ClassLibrary.B)作为辅助功能库

编译后，通过ILSpy查看生成的Sample.RazorApp.dll，会发现类库被自动添加了如下程序集属性：

[assembly: ApplicationPart("ClassLibrary.A")]
[assembly: ApplicationPart("ClassLibrary.B")]

问题影响

这种自动标记会导致在应用程序启动时，services.AddRazorPages()方法会尝试加载所有标记为ApplicationPart的程序集。如果某些类库在生产环境中不可用(由于部署策略或其他限制)，就会抛出如下异常：

File name: 'ClassLibrary.A, Culture=neutral, PublicKeyToken=null'
at System.Reflection.RuntimeAssembly.InternalLoad(...)

解决方案

要解决这个问题，可以通过修改项目文件(.csproj)来禁用自动生成ApplicationPart属性的功能。具体方法是在主应用程序的项目文件中添加以下属性：

<PropertyGroup>
    <GenerateMvcApplicationPartsAssemblyAttributes>false</GenerateMvcApplicationPartsAssemblyAttributes>
</PropertyGroup>

技术原理

ASP.NET Core在编译时会自动扫描引用的程序集，并为它们生成ApplicationPart属性。这一机制主要用于：

1. 控制器发现：自动发现引用的程序集中的控制器
2. 视图组件发现：自动发现引用的程序集中的视图组件
3. Tag Helper发现：自动发现引用的程序集中的Tag Helpers

当引用的类库仅包含辅助方法而不包含任何MVC相关组件时，这种自动发现机制就显得多余且可能带来问题。通过禁用GenerateMvcApplicationPartsAssemblyAttributes，可以精确控制哪些程序集参与MVC组件发现过程。

最佳实践

1. 对于纯工具类库，建议禁用ApplicationPart自动生成
2. 对于确实包含MVC组件(控制器、视图组件等)的类库，保持默认设置
3. 在大型解决方案中，可以分层管理ApplicationPart的生成：
   • 基础层库禁用
   • 业务层库按需启用
   • 表现层库保持启用

总结

ASP.NET Core的ApplicationPart自动发现机制虽然方便，但在特定场景下需要手动干预。理解这一机制的工作原理，能够帮助开发人员更好地控制应用程序的组件加载行为，避免不必要的运行时依赖问题。通过项目文件配置，我们可以灵活地管理这一特性，使应用程序更加健壮和可维护。