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.