Deploy project with C++/CLI assembly with dependencies

I am trying to dotnet publish (or pack) a solution that contains a C++/CLI project. As I understand it this is not currently supported. It seems the context of the current directory is lost when going thru dotnet pack.

Doing > dotnet pack --no-build -o ./pack Jacobi.Vst.sln

Results in

[...]\Jacobi.Vst.Interop\Jacobi.Vst.Interop.vcxproj(29,3): 
error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. 
Confirm that the expression in the Import declaration "\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk. 

There are two goals I want to achieve:

1. Create a nuget package for my library that devs can use when they create a VST Plugin
2. Create a way for the dev to pack his Plugin together with assemblies from my library.

1. There are three assemblies, one of which (Interop) is C++/CLI mixed. I have a dependency on other nuget packages (like Microsoft.Extensions.Configuration).
2. Is a bit more complex. The Interop assembly needs to be renamed to the root name of the devs plugin and his managed assembly is given a different extension. The Interop assembly looks for this different extensions and loads the the actual managed plugin. The dev’s plugin assembly of course has dependencies on other nuget packages as well. I probably also need a correct runtimeconfig.json and deps.json (?).

I was trying to bring all the assemblies together in one folder (my library, a plugin with special extension and the Microsoft.Extension.Configuration.dll’s) During loading of my (renamed) Interop assembly into the unmanaged host application, the nuget dependencies did not (auto) load. I did have a runtimeconfig.json but not a deps.json. I figured using dotnet pack/publish would be the correct way to generate this deps.json for the plugin. That is if having a deps.json is the correct solution. It looks to be related to dotnet/runtime#18527 but I just wanted to make sure if having a deps.json would or would-not fix this.

Edit: After some more testing and digging through all the dependencies recursively (initially I forgot) the plugin loads. But its tedious to find all recursive dependencies by hand. Hoping that dotnet publish could automate this and gather all the dependent dlls for me.

I can’t remember the exact details of all the other things I have tried, but I have not been able to get it to work. I also know that I lack some knowledge of how dotnet core is deployed and how nuget packages are positioned in this whole story.

My Project https://github.com/obiwanjacobi/vst.net/tree/netcore3/Source.Core/Code

[obiwanjacobi]

Is this where issues are sent to die…?

[wli3]

Sorry, we have a high volume of work these few month. Please expect a long delay.