It turns out the root cause was that the JSON configuration files (including appsettings.json and appsettings.secrets.json) were not being copied into the container during deployment. What confused me was that even previously working containers started giving the same license error after a restart. Since it’s not possible to check the container content before it starts, I couldn’t verify whether the appsettings files were present or not.
After adding the license as an environment variable, the container started successfully. This helped me realize the JSON files were missing. Once I fixed the deployment pipeline to include these files, the issue was resolved.
Thank you for your support.
As mentioned in my initial message, I also restarted a previously running container that was working fine before, and it now shows the same license error. This suggests that the issue is not related to the current container’s configuration or contents.
Is there anything else that could be causing this problem, possibly on the ABP license validation service side?
The issue has been resolved for now. I’m able to build on our pipeline again.
The Azure pipeline uses the NuGet.config file provided in our project, which only includes api.nuget.org and nuget.abp.io. This issue starts to occur after midday. On my local development machine, when I try to list nuget.abp.io packages, the IDE asks for a username and password.
We are also experiencing the same issue. Our pipeline cannot restore the Volo.* packages, even though I provided the correct key. I tried your solution, but unfortunately, it did not resolve the problem.
