Motivation
After #232: Add Support for Plugins in the Code Generation Process is finished, those plugins will likely want to introduce or reference types from external libraries — beyond what’s available in the standard .NET Base Class Library.
For instance, in the example from the #232, a plugin might generate helper code that integrates with ILogger from Microsoft.Extensions.Logging namespace. However, ILogger is not part of the standard library — it comes from a NuGet package that must be explicitly referenced by the consuming project.
Today, interoptopus outputs the generated bindings (commonly in a file like Interop.cs), but any required package references must still be added manually by the developer. This quickly becomes tedious and error-prone as plugins introduce more dependencies and, perhaps more worryingly, as it will be less clear for what version of the external library the plugin generates the code.
Proposal
Extend interoptopus to optionally generate build instructions alongside the existing code outputs.
For example, when generating C# bindings, interoptopus could emit an additional file such as Interop.props (or Interop.targets), containing MSBuild metadata. This file could include <PackageReference> elements or other project-level configuration required by the generated code.
For example Interop.props file like:
<Project>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.0" />
</ItemGroup>
</Project>Could be defined by the plugin like (for the lack of better idea for an API):
Plugin {
fn write(inventory: &Inventory, pipeline: &Pipeline) {
let build_instructions = r#"
<Project>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.0" />
</ItemGroup>
</Project>
"#;
pipeline.define_file("Interop.props", build_instructions);
}
}This would allow a plugin to express “this generated code depends on this NuGet package”, ensuring the generated project compiles without manual intervention.
Motivation
After #232: Add Support for Plugins in the Code Generation Process is finished, those plugins will likely want to introduce or reference types from external libraries — beyond what’s available in the standard .NET Base Class Library.
For instance, in the example from the #232, a plugin might generate helper code that integrates with
ILoggerfromMicrosoft.Extensions.Loggingnamespace. However,ILoggeris not part of the standard library — it comes from a NuGet package that must be explicitly referenced by the consuming project.Today, interoptopus outputs the generated bindings (commonly in a file like
Interop.cs), but any required package references must still be added manually by the developer. This quickly becomes tedious and error-prone as plugins introduce more dependencies and, perhaps more worryingly, as it will be less clear for what version of the external library the plugin generates the code.Proposal
Extend interoptopus to optionally generate build instructions alongside the existing code outputs.
For example, when generating C# bindings, interoptopus could emit an additional file such as
Interop.props(orInterop.targets), containing MSBuild metadata. This file could include<PackageReference>elements or other project-level configuration required by the generated code.For example
Interop.propsfile like:Could be defined by the plugin like (for the lack of better idea for an API):
This would allow a plugin to express “this generated code depends on this NuGet package”, ensuring the generated project compiles without manual intervention.