基于ABP模板的插件动态获取现有程序集名称咨询

Hey there! Great question—this is a super common scenario when building reusable plugins for ABP templates, and yes, it’s absolutely feasible to configure your Plugin.Core.csproj to work with custom-named core projects instead of the default AbpTemplate.Core. Let me break down the best approach step by step:

The Problem with Hardcoded References #

When you hardcode a reference to AbpTemplate.Core in your plugin’s csproj, it’ll only work for projects that stick exactly to the template’s default naming. Since ABP users often rename their core projects (e.g., MyShop.Core, AcmeCorp.Core), we need a dynamic way to target their custom core assembly.

Solution: Use MSBuild Properties for Dynamic References #

The cleanest way to handle this is to replace your hardcoded project reference with a configurable MSBuild property. This lets you keep the default AbpTemplate.Core as a fallback, while letting users override it to match their project’s name.

Step 1: Modify Your Plugin.Core.csproj #

Open your Plugin.Core.csproj and replace any hardcoded <ProjectReference> for AbpTemplate.Core with this dynamic setup:

<!-- Define a default core project name, users can override this -->
<PropertyGroup>
  <AbpCoreProjectName>AbpTemplate.Core</AbpCoreProjectName>
  <!-- Optional: Set a default relative path (adjust based on your plugin's folder structure) -->
  <AbpCoreProjectPath>..\$(AbpCoreProjectName)</AbpCoreProjectPath>
</PropertyGroup>

<!-- Dynamic project reference that uses the configured property -->
<ItemGroup>
  <ProjectReference 
    Include="$(AbpCoreProjectPath)\$(AbpCoreProjectName).csproj"
    Condition="Exists('$(AbpCoreProjectPath)\$(AbpCoreProjectName).csproj')"
  />
</ItemGroup>

Step 2: Guide Users to Override the Property #

When sharing your plugin, tell users to add the following to their solution’s Directory.Build.props file (create it if it doesn’t exist) to match their custom core project name:

<PropertyGroup>
  <!-- Replace with their actual core project name -->
  <AbpCoreProjectName>MyCustomApp.Core</AbpCoreProjectName>
  <!-- Optional: If their core project is in a different location, override the path -->
  <!-- <AbpCoreProjectPath>../src/MyCustomApp.Core</AbpCoreProjectPath> -->
</PropertyGroup>

Alternatively, users can set this property directly in their own project’s csproj file if they prefer, but Directory.Build.props applies it across the entire solution, which is more convenient.

Why This Works #

• Flexibility: Users don’t need to modify your plugin’s code or csproj—they just set a simple property to match their project structure.
• Backward Compatibility: If someone is using the default AbpTemplate.Core naming, they don’t need to do anything extra; the fallback value will work automatically.
• MSBuild Native: This uses built-in MSBuild functionality, so it’s robust and doesn’t require any external tools.

Bonus: Runtime Assembly Resolution (If Needed) #

If your plugin needs to load the core assembly at runtime (beyond compile-time references), you can use reflection to locate it by its ABP-specific attributes (like AbpModule). For example:

// Find all assemblies that contain an ABP module
var coreAssembly = AppDomain.CurrentDomain.GetAssemblies()
    .FirstOrDefault(a => a.GetTypes().Any(t => typeof(AbpModule).IsAssignableFrom(t) && !t.IsAbstract));

This is useful if you need to dynamically interact with the user’s core module without tight compile-time coupling.

内容的提问来源于stack exchange，提问作者hitasp