Forums Home / ComponentOne / WinForms Edition
Posted by: andreas.appelros on 14 January 2024, 9:20 pm EST
andreas.appelros
Posted 14 January 2024, 9:20 pm EST
When building one of our projects, the .gclicx in the obj folder is always recreated forcing the project to rebuild. This leads to rebuild of all dependent projects.
If nothing has changed, shouldn’t the .gclicx file be unchanged and the project not rebuilt?
Is there something we can do to avoid rebuilding, some configuration or similar to avoid rebuilds?
wknauf
Posted 15 January 2024, 1:17 am EST
Hi Andreas,
you could use this switch in csproj files to switch off the license generator. It is only necessary in starter projects.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
...
<DisableGclm>True</DisableGclm>
</PropertyGroup>I would link to a forum post where I asked about Gclm, but I don’t find my thread any more.
Best regards
Wolfgang
andreas.appelros
Posted 15 January 2024, 7:45 pm EST
Hi Wolfgang!
Thanks for pointing out the DisableGclm property. It made things better, fewer projects are rebuilt. The problem we still have is when using TDD. If we update a source file in our test assembly, all dependent “starter” projects will still be rebuilt. Any idea how that could be avoided?
Regards,
Andreas
wknauf
Posted 15 January 2024, 7:52 pm EST
Hi Andreas,
you might take a look at build acceleration: https://github.com/dotnet/project-system/blob/main/docs/build-acceleration.md
This should avoid building the starter projects.
But this is only a workaround for your initial Gclm question.
Best regards
Wolfgang
andreas.appelros
Posted 15 January 2024, 9:01 pm EST
Perfect! Now only the test assembly is built. Thanks!
Regards,
Andreas
aastha.gupta
Posted 15 January 2024, 9:31 pm EST
Hi,
@Wolfgang, thanks for your insights regarding this issue. Your expertise is highly appreciated.
@Andreas, it seems that the issue has been resolved at your end. Please feel free to reach out to us for any further help.
Thanks & Regards,
Aastha
andreas.appelros
Posted 16 January 2024, 1:31 am EST
Yes, I’ve been able to work around the problem. The best thing, in my opinion, would be that gclm.exe didn’t update the .gclicx file if there are no license changes, thereby giving no reason for the assembly to be recreated.
Regards,
Andreas
aastha.gupta
Posted 17 January 2024, 1:05 pm EST
Hi Andreas,
While we understand your request to disable the regeneration of the gclicx file, it’s important to note that the workaround provided is not intended to be a permanent solution. If your project includes C1 references, our licensing model performs checks to ensure the proper licensing of the build machine, enabling the generation of the runtime license accordingly.
Disabling the regeneration of the gclicx file is generally discouraged, as it may lead to a breach of company policy. We appreciate your understanding in this matter.
Thanks & Regards,
Aastha
andreas.appelros
Posted 17 January 2024, 9:55 pm EST
I don’t request to disable the regeneration of the gclicx file. But I would like that the timestamp on the .gclicx-file didn’t change unless its content changes. As it is now, the .gclicx-file is regenerated every time the project builds, even if nothing has changed at all. This forces msbuild to generate a new dll each time, forcing all dependent projects to rebuild. If gclm could detect that the .gclicx file is unchanged, much time would be saved.
aastha.gupta
Posted 21 January 2024, 12:52 am EST
Hi Andreas,
The content of the gclicx file is generated based on the information like project name, product code, license key details and machine name. When a project containing C1 references is updated or any of its dependent projects is modified, the project build action regenerates the gclicx file. Please note that the actual content of the gclicx file remains unchanged, but it is regenerated. The regeneration serves as a check by our licensing model to verify the proper licensing of the build machine.
We would like to outline some case scenarios showing exactly when the gclicx file is regenerated. To demonstrate this, we have developed a sample project(A) that includes C1 references and has two project references. One of these dependent projects(B) contains the C1 reference, while the other one(C) does not.
Clean build the main project: A, B and C all gets rebuild. Gclicx file regenerated for A and B. Refer https://www.dropbox.com/scl/fi/ayf0qls495jeu8ekeg0ph/First_build.mp4?rlkey=fkx5t6dh33fsyww30ceazw7ta&dl=0
Update the main project(A) and build it: On A gets rebuild. Gclicx file regenerated for A only. Refer https://www.dropbox.com/scl/fi/p7q37wg1z773uvwho02bm/ChangeMainProj.mp4?rlkey=4nlw9if0oqap2bh91uj1q5qbt&dl=0
Update dependent project containing C1 reference(B) and build main project(A): Only A and B gets rebuild. Gclicx file regenerated for A and B. Refer https://www.dropbox.com/scl/fi/3nxa83j4clfb2d0103gxw/ChangeC1DepProj.mp4?rlkey=hdr21i46zo12gx5y07ha0jwpi&dl=0
Update dependent project that does not contain C1 reference(C) and build main project(A): Only A and C gets rebuild. Gclicx file regenerated for A. Refer https://www.dropbox.com/scl/fi/ty9wat8v3qc1jyjkw4ryn/ChangeWOC1Dep.mp4?rlkey=a26f0qvoamkc9zqpccmtynhq3&dl=0
The scenario is same if you build the entire solution instead of building the main project.
Please see the attached sample application for reference.
TestC1App.zip
This shows that the gclicx file for the dependent project is not regenerated until you clean-build or rebuild the main project, or make changes in the dependent project. Therefore, we request you please update the attached sample based on your use-case scenario so that we can understand your requirement in a better way.
Furthermore, we kindly request the following information for further analysis of this issue:
In case you are not comfortable in providing these details on this public forum, please feel free to generate a support ticket on our private support portal at https://developer.mescius.com/my-account/my-support. This will ensure that the information remains confidential and is accessible only to our team.
Thanks & Regards,
Aastha
andreas.appelros
Posted 31 January 2024, 2:02 am EST
Thanks for the information!
I’ve downloaded the test projects, and they do not show the same behaviour as our own projects do.
For further troubleshooting on my part, what type of changes are monitored in order to execute the gclm.exe license generation? There must be something (wrong?) we do which makes the license regenerate at every build. Any ideas how I could troubleshoot this? Is there any targets in the msbuild process I should look at?
Regards,
Andreas
aastha.gupta
Posted 1 February 2024, 1:05 am EST
Hi Andreas,
Thank you for the details. We need to know few more things to assist you with troubleshooting the issue on your end:
We request you please provide the above requested information so that we can investigate this issue further. Your cooperation is highly appreciated.
Also, if you are not comfortable in providing these details on this public forum, please feel free to generate a support ticket on our private support portal at https://developer.mescius.com/my-account/my-support. This will ensure that the information remains confidential and is accessible only to our team.
Thanks & Regards,
Aastha
andreas.appelros
Posted 1 February 2024, 8:16 pm EST
I’ve further investigated, and it seems that we had problems with Visual Studio’s “Fast Up-to-Date Check”. I enabled logging for FUTDC and there was marker files in one of the obj folders that never were updated, forcing projects to always rebuild.
Thanks for your help in putting me in the right direction.
Regards,
Andreas
aastha.gupta
Posted 4 February 2024, 4:11 pm EST
Hi Andreas,
We are glad to hear that the issue has been resolved on your end. Thanks for the updates.
Kind Regards,
Aastha
