How should optional dependencies (plugins) work with deps.json?

[kendfrey]

Summary

We have an application referencing many libraries which are considered optional, and are only used as MEF plugins. Currently if one of these dlls is missing at runtime, the application fails to start with an error like "An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found". We would like to deploy copies of our application with a subset of these plugins, but this error prevents that. What do we need to do to ignore missing dependencies?

Details

Our MyApp solution contains the following projects:

• Core (library)
• MyApp (executable)
• PluginA (library)
• PluginB (library)
• etc.

The MyApp projects has references to all the Plugin libraries. All projects reference the Core library.

MyApp is considered a complete package, containing the "base" application (MyApp.exe) as well as a standard set of plugins (PluginA.dll, etc.). Plugins provide the business logic powering MyApp, and are loaded using MEF. The plugins and the base application are developed together with tight collaboration. We license the plugins to clients on a per-plugin basis.

The reason MyApp references its plugins is so that dotnet works seamlessly when running and publishing the application. Developers working on a plugin can set MyApp as their startup project, and pressing F5 in Visual Studio automatically builds the plugin and starts the application without requiring any extra build steps. Publishing the application is just one command, instead of publishing each plugin individually. This is why we have chosen to reference plugins from the base application, when there are no "real" dependencies.

We wish to remove any unlicensed plugins when a client downloads a release. Currently all plugins must remain in the application directory, because MyApp.deps.json requires them. Our current workaround is to disable plugins based on licensing information. This causes a potential problem, as clients may find a way to re-enable disabled plugins, and gain access to unlicensed features. This is why we want to completely remove unlicensed plugins.

The only feasible solution we've found is to modify the deps.json file generated by dotnet and remove the references to the plugins, so that the application can start without them. This is not a good solution, as it abuses dotnet infrastructure and may become brittle. What is the correct solution?

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[huoyaoyuan]

https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support

I think this is the documentation you need. Each optional assembly should be treated as a plugin and loaded dynamically.

[kendfrey]

I think this is the documentation you need. Each optional assembly should be treated as a plugin and loaded dynamically.

We already do this (using MEF). My question is not about how to load assemblies.

[huoyaoyuan]

There are sections about plugin dependencies, which should be useful.

[kendfrey]

I read it but I didn't see anything that helps with my specific question. If the solution to my problem is somewhere in there, please point me to it directly, as it is not clear.

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Summary

We have an application referencing many libraries which are considered optional, and are only used as MEF plugins. Currently if one of these dlls is missing at runtime, the application fails to start with an error like "An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found". We would like to deploy copies of our application with a subset of these plugins, but this error prevents that. What do we need to do to ignore missing dependencies?

Details

Our MyApp solution contains the following projects:

• Core (library)
• MyApp (executable)
• PluginA (library)
• PluginB (library)
• etc.

The MyApp projects has references to all the Plugin libraries. All projects reference the Core library.

MyApp is considered a complete package, containing the "base" application (MyApp.exe) as well as a standard set of plugins (PluginA.dll, etc.). Plugins provide the business logic powering MyApp, and are loaded using MEF. The plugins and the base application are developed together with tight collaboration. We license the plugins to clients on a per-plugin basis.

The reason MyApp references its plugins is so that dotnet works seamlessly when running and publishing the application. Developers working on a plugin can set MyApp as their startup project, and pressing F5 in Visual Studio automatically builds the plugin and starts the application without requiring any extra build steps. Publishing the application is just one command, instead of publishing each plugin individually. This is why we have chosen to reference plugins from the base application, when there are no "real" dependencies.

We wish to remove any unlicensed plugins when a client downloads a release. Currently all plugins must remain in the application directory, because MyApp.deps.json requires them. Our current workaround is to disable plugins based on licensing information. This causes a potential problem, as clients may find a way to re-enable disabled plugins, and gain access to unlicensed features. This is why we want to completely remove unlicensed plugins.

The only feasible solution we've found is to modify the deps.json file generated by dotnet and remove the references to the plugins, so that the application can start without them. This is not a good solution, as it abuses dotnet infrastructure and may become brittle. What is the correct solution?

Author:	kendfrey
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

I don't know if there's a way to have a ProjectReference which would include the output files into the main app's output, but NOT include them in the .deps.json. What is possible is something like:

<ProjectReference Include="..\Plugin1\Plugin1.csproj">
  <Private>false</Private>
  <ExcludeAssets>all</ExcludeAssets>
</ProjectReference>

This will build the Plugin1.csproj as a dependency, but it will not include the files in the app's output (and also not in the .deps.json). Then you can have a custom post-build task to copy the files over.

I'm going to move this issue to SDK since this is an issue with how SDK project dependencies and .deps.json generation works.

[jamers99]

The solution above may work, but seems less than ideal and perhaps even hacky. Is there no way for the runtime to just ignore a project that's in the .deps.json but doesn't actually exist?

[vitek-karas]

Is there no way for the runtime to just ignore a project that's in the .deps.json but doesn't actually exist?

Short answer: no. The runtime currently expects only input generated by the SDK. Since SDK should never do such thing, it doesn't allow this.

[nick-beer]

It's disappointing that there's not a better way to do this. We have this exact requirement for one of our applications, and it seems that there is no better solution than editing the .deps.json file to remove the plugin as a dependency.

Then you can have a custom post-build task to copy the files over.

This starts to get really messy if your plugin has many dependencies - especially if those dependencies are on NuGet packages.

Is there anything that can be done to improve this use case?

[vitek-karas]

In .NET 6 if there are no additional dependency files specified (typically done via .runtimeconfig.dev.json, but there are other ways) the host doesn't check file existence for all files in .deps.json anymore. So it should not fail if the file is not there. Note though that this was done as a perf optimization, it's not guaranteed that the host will not check.

As for truly fixing this, SDK would have to support a notion of "include in output but don't count as a dependency" on assemblies. I don't think it's currently available (but I'm no expert in this area).

[hymccord]

@kendfrey @nick-beer I have been running into a similar issue with stuff in the deps.json file showing up that I don't want to.

I poured over the SDK source (mainly the GenerateDepsFile task) and binary logs to come up with this. If all your plugins have a common naming scheme where you can use a string function, then you're in luck!

This is only going to remove the direct dependencies though. If PluginA references Newtonsoft.Json, you will still see that in the deps file. It's working from my simple setup seen below. I was able to delete PluginA and/or PluginB from the publish folder and the app still worked fine (app tested in windows sandbox with only the .NET 5 Desktop runtime installed).

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0-windows</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Composition" Version="5.0.1" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\Core\Core.csproj" />
    <ProjectReference Include="..\PluginA\PluginA.csproj" />
    <ProjectReference Include="..\PluginB\PluginB.csproj" />
  </ItemGroup>

  <!-- UserRuntimeAssemblies are going to be your project references and direct references -->
  <Target Name="_RemoveUserRuntimeAssemblies"
      DependsOnTargets="_ComputeUserRuntimeAssemblies"
      BeforeTargets="GenerateBuildDependencyFile">
    <ItemGroup>
      <UserRuntimeAssembly>
        <!-- You can use whatever string function you want on any of the available item metadata -->
        <IsPlugin>$([System.String]::Copy('%(Filename)').StartsWith('Plugin'))</IsPlugin>
      </UserRuntimeAssembly>

      <UserRuntimeAssembly Remove="@(UserRuntimeAssembly->WithMetadataValue('IsPlugin', 'true'))"  />
    </ItemGroup>
  </Target>
</Project>