Open obiwanjacobi opened 4 years ago
I couldn't add an area label to this Issue.
Checkout this page to find out which area owner to ping, or please add exactly one area label to help train me in the future.
@jkoritzinsky
There's limitations in the SDK around the restore and publish process for C++/CLI. I'm going to transfer this issue to the dotnet/sdk repo since they own the SDK-side of the experience.
Is this where issues are sent to die...?
Sorry for the delay.
You can use msbuild /t:pack
on command line if the head project(the one with exe) is a c# project.
As for the assembly reference, dep.json. If they are in
I don't understand your ask well, could you give me the command to build your repo and could you show me what is expected to present in the build result?
Ok, lets start with my first goal: I want to build a nuget package for my 3 assemblies (Core, Interop and Framework). I am trying to find a way to get this the dotnetcore technology to work with the C++/CLI project (Jacobi.Vst.Interop) that seem to be causing all the trouble.
build /t:pack
results in an error error NETSDK1118: C++/CLI projects targeting .NET Core cannot be packed.
(the C++/CLI project, Interop is not an exe!).
So the question is: is it possible to create a nuget package with 2 dotnetcore3 libraries and on C++/CLI dotnetcore3 library?
If the head project is a C++/CLI project it is not supported today
'Not supported' as in: no way this will ever work? Or 'not supported' in that there are no tools / automation for it, but it can be done if you do it yourself in the correct manner? If the latter: can you steer me towards information I need to make that happen?
It is not easy to do so without tooling. You can reference https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-using-a-nuspec & https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#advanced-extension-points-to-create-customized-package
to create a nupkg with your desire layout.
Ok - I think I have that (nuget package) working.
My second goal is to be able to copy over all the dependencies of a project using my library.
The problem that I am seeing now is that when I do a dotnet publish
I do get the 1st level of dependencies in the folder (-o
option) but not the recursive dependencies (of dependencies etc).
Is there a way to let the tooling grab the entire dependency tree? If not - what would be a good approach to create a tool that could do that? (following deps.json files?)
bump! Anybody home?
You can try following this comment https://github.com/NuGet/Home/issues/4704#issuecomment-315915898
I may not understand your suggestion, but what I gather that is for adding to a NuGet package...? (similar to the link you've provided earlier?) My problem is knowing what to add - the dependencies of my mixed assembly...
How do you discover the dependencies of a mixed assembly/project?
How do you discover the dependencies of a mixed assembly/project?
I don't think there is a tool to discover dependencies of mixed assembly/project today. Since you will need to pinvoke the native assemblies right?
Ok, just the managed dependent assemblies then?
yes. the build result should have all the necessary dlls in the output folder
Not of the nuget packages (with managed assemblies) I use...
I see just the project binary (and related files) and a project referenced assembly. Not any of the #usings
I do in the code... (like Microsoft.Extensions.Configuraiton
)
Could you show me a sample repo of your project?
Sure: https://github.com/obiwanjacobi/vst.net/blob/master/Source/Code/Jacobi.Vst.Interop/Bootstrapper.cpp This is a cpp file in a mixed cpp/cli project with usings. Navigate up for more context.
Bump! Any news?
Sorry, we have a high volume of work these few month. Please expect a long delay.
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 thrudotnet pack
.Doing
> dotnet pack --no-build -o ./pack Jacobi.Vst.sln
Results in
There are two goals I want to achieve:
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