Also, why are 2 separate copies of our license required? Why would we be required to keep multiple pieces of the same information, and track it in different places? This is exactly the type of maintenance burden that ABP is supposed to alleviate
These things are NOT both required under version 7 - we have the exact same configuration working with only the access-token.bin file in place - we are not setting any environment variables. Why has this been changed?
I wasted more time doing what you said, even though I already explained that it did not work previously. Here are the results.
At startup, my debug code logged:
2025-01-14 08:23:19 [13:23:19 INF] Location of access-token file:
2025-01-14 08:23:19 [13:23:19 INF] /root/.abp/cli/access-token.bin
2025-01-14 08:23:19 [13:23:19 INF] Access token file exists.
2025-01-14 08:23:19 [13:23:19 INF] Value of Environment variable 'AbpLicenseCode':
2025-01-14 08:23:20 [13:23:20 ERR] ABP-LIC-0020 - License code not found! Ensure that your appsettings.json or appsettings.secrets.json has "AbpLicenseCode" key with your license code.
I don't care if I need to populate it as a file (the way it worked in the past), or as an environment variable in the container, but it needs to work. We have been trying to migrate to ABP 9 and this is preventing us from doing so. We cannot use our commercial subscription without being able to deploy and debug in containers, and this is advertised as a working scenario.
It worked under ABP7, but that code no longer works under 9.0.3 which I stated in the initial post. Why doesn't it work as an environment variable?
I added debugging code:
2025-01-13 23:30:10 [04:30:10 INF] Location of access-token file:
2025-01-13 23:30:10 [04:30:10 INF] /root/.abp/cli/access-token.bin
2025-01-13 23:30:10 [04:30:10 INF] Access token file does not exist.
2025-01-13 23:30:10 [04:30:10 INF] Value of Environment variable 'AbpLicenseCode':PAB... (this value matches the appsettings.secrets.json file)
I then receive the error ABP-LIC-ERROR - License check failed for 'Volo.CmsKit.Pro.Public.HttpApi-v9.0.3.0'.
If i remove the environment variable, the error I receive is: ABP-LIC-0020 - License code not found! Ensure that your appsettings.json or appsettings.secrets.json has "AbpLicenseCode" key with your license code.
The license code is being found and loaded, why does it only work for some portions of the project?
abp login <username>.
2025-01-13 18:14:03 For more information, contact to license@abp.io.COPY ["../StructureCloud.NET/access-token.bin","/root/.abp/cli/"]
RUN chmod -R 777 /root/.abp/cli/
This used to work fine. Under ABP 9.0.3 and .NET 9, this no longer seems to work.
I tried using the contents of the access-token.bin file as a value for an environment variable named "AbpLicenseCode" but that did not work.
Based on other posts I have found (I did not find any documentation stating that a change was made), I tried adding an environment variable based on the appsettings.secrets.json that was created.
- AbpLicenseCode=PAB...
I am now getting different errors in each container. AuthServer: "ABP-LIC-ERROR - License check failed for 'Volo.Abp.AspNetCore.Mvc.UI.Theme.Commercial-v9.0.3.0'" HttpApi: "ABP-LIC-ERROR - License check failed for 'Volo.Abp.LanguageManagement.Domain-v9.0.3.0'" WebPublic: "ABP-LIC-ERROR - License check failed for 'Volo.Abp.LanguageManagement.HttpApi-v9.0.3.0'"
Why was this changed, why wasn't it documented, and what is the procedure to make it work?
DO NOT tell me to use PRODUCTION mode, I am doing development in VIsual Studio using Docker Compose, and this is the development environment.
We have also been unable to produce builds all day. The lack of response here is a serious problem. This has been going on for the entire work day in the US
We've been down all day, any updates?
Why was this question closed? It was not answered.
I am looking for the ABP Recommended way to create, compile, and run a new solution completely off of local source and done in a scripted, repeatable way. Going through the GUI is not an acceptable answer - there is too much room for error.
That's not what I'm saying. I can access the PACKAGES, but as a customer I do not have access to source for COMMERCIAL. I have access to source for everything else. When I reference all packages it is OK, when I switch to local source I am still referencing the package for commericial (like Volo.Abp.Commercial.Core and a couple others), and that is where I am getting "NU1106: Unable to satisfy conflicting requests for 'Volo.Abp.Core'" This was not a problem in version 7 of ABP and .NET 7, but it IS a problem with ABP 8 and .NET 8 (in this case, I am using ABP 8.3.1)