Custom WPF library and C1 licensing

Custom WPF library and C1 licensing

Posted by: uwe.seiler on 15 April 2021, 3:25 am EST

• 

  uwe.seiler

  • Post Options:
  • Link
    Copy
  • Jump To Answer

  Posted 15 April 2021, 3:25 am EST - Updated 4 October 2022, 8:41 am EST

  I 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.

  Current state:

  • "

  • "
    
    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.
    
    "

  "

  Assumption:
  
  If I license my WPF library/NuGet package (see attachment orange area), then I don’t need to license my WPF applications anymore.

  Question:
  
  Is my adoption possible? If yes, how?

  

  881×726 16.7 KB

• 

  kartik.sagar

  

  • Post Options:
  • Link
    Copy

  Posted 16 April 2021, 11:14 am EST

  Hi Seiler,

  I apologize for the delay.

  We are discussing this with the licensing team and will let you know once there is any update. (Internal Tracking ID - C1-3104)

  Best Regards,
  
  Kartik

• 

  greg.lutz

  

  • Post Options:
  • Link
    Copy

  Posted 19 April 2021, 6:48 pm EST

  Hello,

  If I understand your scenario correctly, it’s not possible to license only the component package first. For your scenario to work you will need to license each final application, meaning every machine that compiles the final application/exe needs to be licensed. Our developer license model works this way - and each key allows up to 3 activations to handle build machines, etc.

  If the machine building the application is already activated (licensed) and you still see the GCLM invoked, you might be able to work around this by generating the license file manually. The licnese file (.gclicx) needs to be generated for the application, just like it’s being generated for the component package build. Normally, the .gclicx file is automatically generated but you can also generate this file manually in Visual Studio by Tools - GrapeCity - License Manager - Create Runtime License. This will generate the .gclicx file in your project solution.

  Regards,
  
  Greg Lutz

• 

  uwe.seiler

  • Post Options:
  • Link
    Copy

  Posted 20 April 2021, 11:23 am EST

  Thanks for the hint with the Runtime License. It helped in my project.