Posted 14 April 2021, 6:25 pm ESTI have several WPF applications (see attachment WPF-App-x) that use C1 WPF controls. The components used are defined and styled relatively the same.
For this reason, I want to create a WPF library (see attachment C1-Custom-Lib) with predefined controls, styles and functions. This WPF library uses a NuGet package (created by me, see attachment C1-Collection.nupkg) with a collection of C1-DLLs respectively their NuGet packages.
Subsequently, this WPF library is to be deployed as a NuGet package (see attachment C1-Custom.nupkg) on my non-public Azure feed.
To build the WPF library, I use a YAML pipeline. When building the WPF library, the GrapeCity License Manager is correctly called. This also licenses my WPF library properly. Then my WPF library is packaged as a NuGet package and published.
So far so good.
However, I have a problem with the integration of the WPF library/NuGet package into the various WPF application and C1 licensing. My WPF applications no longer use C1 components directly through the WPF library, but indirectly through derived or wrapped controls/class/functions.
When referencing the C1-Collection.nupkg package directly in the WPF library/NuGet package, the build of my WPF applications again invokes the GrapeCity License Manager.
If you put the C1 DLLs directly in the WPF library/NuGet package, e.g. as contentFiles, then the GrapeCity License Manager doesn't come at build time anymore. But at run-time, when you use the derived or wrapped controls/class/functions for the first time.
If I license my WPF library/NuGet package (see attachment orange area), then I don't need to license my WPF applications anymore.
Is my adoption possible? If yes, how?