License nag screen appears if we rename the executable file

Posted by: vsaldana on 28 September 2020, 9:47 pm EST

  • Posted 28 September 2020, 9:47 pm EST

    Recently we updated our applications to reference the 4.5.2 framework C1 components from 4.0.
    Everything works fine but if we build the project and rename (or copy) the executable file then the licensing nag screen appears (it doesn't appear if it has the original name).
    Previously to the update we didn't have this behaviour.

    In our case we need to distribute copies of the executable with different file names, is there a way to get around it?

    I'm attaching a simple project to show this behaviour, it's just a form with a C1Ribbon. In the bin/release folder you'll find the original exe (C1LicenseTest.exe) which doesn't prompt the nag screen and a copy of the same file (C1LicenseTest-copy.exe) which does.

    Thank you very much for your help.
  • Replied 30 September 2020, 2:35 am EST


    I can see that renaming the executable shows a nag screen. However, as I understand it is by-design since the licensing system obtains the run-time license.
    Starting July 29 2020, GrapeCity has introduced new license, I would suggest you to kindly check the following page [heading 'HOW DOES LICENSING WORK?']:

    >In our case we need to distribute copies of the executable with different file names, is there a way to get around it?
    I am discussing it with the team and will get back to you soon.

  • Replied 6 October 2020, 2:59 am EST


    Just wanted to share the issue has been forwarded to the developers [ID: 466745]. We will get back to you as soon as there is some information.

  • Replied 7 October 2020, 10:49 pm EST

    Thank you very much.
    In the meantime we are trying to get around the issue by copying the executables (with the original name) in different subfolders and overriding the assembly resolver to check for dlls on the parent folder.
  • Replied 22 October 2020, 6:23 am EST


    The team has confirmed that this behavior has always been true for WinForms/etc applications where the runtime license is embedded in the application using licenses.licx file and the license compiler.

    The team shares following information:
    The license compiler reads the licenses.licx file and queries each control listed for a runtime license. The controls return a valid runtime license if a design time license is present/an eval license if available and throw an exception or nag otherwise. If a runtime license is returned, it is added to a hash table which is embedded as a resource in the application with the name <exe assembly name>.licenses.
    When the control check for a runtime license during runtime instantiation, it queries for a runtime license by passing in the name used to store it during design time. It looks at the application resources and assumes the resource will be named <exe assembly name>.licenses (in this case, C1LicenseText.exe.licenses). If you change the assembly file name the licensing resource cannot be found with the new name, only the old name. With no licenses found, the control throws and exception or nags.

    The included sample also contains another resource C1LicenseText.gclicx. The .gclicx can also provide a license regardless start of the name because the new license mechanism checks for a resource of any name that ends with .gclicx. Checking the contents of the C1LicenseTest.gclicx file (the contents of this are used to generate the resource), you can see that the entry starts with "331cf6cd-b73c-429f-ba79-fa2f85eebd68". This is guid for the new English Studio Enterprise license.

    We suspect that in the past, you had a valid Studio Enterprise Evaluation license that has since expired. If the eval license was renewed, then the application would not nag when the exe assembly name is changed.
    If the .glicx file contained a valid full license (rather than an eval license), then you could rename it at will.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels