Question about packaging of Myriad dlls

[JordanMarr]

When a user installs a Myriad plugin, my understanding is that they need to have "Myriad.Core.dll" and "Myriad.Sdk.dll" installed into their project for the plugin to work (please correct me if I am wrong).

I'm wondering if it is possible to pull down those dependencies as "dev" dependencies only so that they are not included in the release. I think this is possible with Paket, but not with regular NuGet. (Maybe this isn't so much of a Myriad question, but I thought I'd ask anyway).

[7sharp9]

Sorry forgot to comment on this, I think I can adjust the non essential libs but I think it requires certain options to be enabled on the client, I really should of added the comment at the time as I cant remember the specifics now :-)

[Andreas-Dorfer]

I started my first Myriad plugin only very recently, so I might be missing something. That said, here are my experiences with packaging my plugin. Maybe it's helpful to you:

In your consuming project: You don't need Myriad.Core. You do need Myriad.SDK. That's because the Myriad.SDK package contains all relevant files - including Myriad.Core - in its tools folder anyway.

In your plugin project: You do need Myriad.Core. You don't need Myriad.SDK. However, if you publish your generator as a tool as well, Myriad.Core doesn't have to flow to your consuming project. To prevent Myriad.Core from flowing to the consuming project, you have to set PrivateAssets="all" for the Myriad.Core PackageReference (see docs).

Btw, you can make installing your plugin even easier by adding a reference to Myriad.SDK in your plugin project. That way, a consumer must only install your plugin package and gets Myriad.SDK automatically. However, for that to work you have to set PrivateAssets="none" for the Myriad.SDK PackageReference in your plugin project. If you don't set PrivateAssets="none", the Myriad.SDK package's build folder won't flow to the consuming project.

Here's my project file for reference.

I hope I didn't misunderstand you questions and that my experience is actually relevant to you.

[7sharp9]

@Andreas-Dorfer No this is relevant thanks for adding this, I think need to tweak the proj files to allow this to be easier but the client also needs to do the steps you mentioned to avoid adding unnecessary dependencies.

[7sharp9]

@JordanMarr / @Andreas-Dorfer The reason only the SDK needs and includes the others is theres a step in the pack process that merges the nupkg together:

        sprintf "dotnet-mergenupkg --source \"%s/Myriad.Sdk.%s.nupkg\" --other \"%s/Myriad.%s.nupkg\" --tools --only-files"
            nugetDir latestEntry.NuGetVersion nugetDir latestEntry.NuGetVersion

This was due to one of the ways the dotnet tools worked where transient dependencies had to be included otherwise they could not be found or located easily. This can be seen in the props/targets where there needs to be a location of the myriad tool in order to invoke the code generation:

<MyriadSdk_Generator_Exe>$(MSBuildThisFileDirectory)../tools/net5.0/any/Myriad.dll</MyriadSdk_Generator_Exe>

So because the nupkg's is merged the myriad executable can be easily found, you could probably do this with installing myriad as just a tool but that's another step for the user to do on where I wanted to 'try' and make this as easy as possible, which can be quite difficult...

[7sharp9]

#121

[7sharp9]

Docs are as is unfortunatly.