Activities of "sid@extranerds.com"

That seems to have fixed the issue. Thank you!

I actually don't know which file it should be looking for. If it's instead trying to locate the ClientAddressesDataSeedContributor.cs file then it's looking for the incorrect file in the correct folder of the correct project.

So either the folder name or the file name is incorrect, though I can confirm the project name was fixed.

I have installed CLI and ABP Suite to 8.0.2, and I updated my project's NPM and NuGet packages. After performing this update I compiled the application and tested it. No problems.

Next I tried to perform the actions that resulted in this ticket being created. I'm sorry to say that the fix mentioned did not solve the problem. Look at the screen shot below. It's slightly different than the one I provided previously (see the areas highlighted with red boxes). In this example, I have an entity called "AddressType" and another entity called "ClientAddress". I am attempting to edit the ClientAddress entity by adding a 1-n navigation property to AddressType.

Notice that previously (before I upgraded to 8.0.2) this incorrect path was being used, which resulted in the error I initially reported: \test\AProInspector.TestBase\AddressType\AddressTypesDataSeedContributor.cs In other words, it was searching for the correct file in the correct folder of the incorrect project.

Now, after the 8.0.2 update, the same error occurs but for a different reason. Now, this incorrect path is being used: \test\AProInspector.Domain.Tests\ClientAddresses\AddressTypesDataSeedContributor.cs In other words, it's searching for the correct file in the incorrect folder of the correct project. The folder it's looking is in "ClientAddress", but it should be looking in "AddressTypes". The confusion is probably because "ClientAddress" is the entity I'm currently editing instead of the entity I am trying to create a navigation property link to.

The correct path should be this. \test\AProInspector.Domain.Tests\AddressType\AddressTypesDataSeedContributor.cs In other words, I think that it should look into the "{ProjectName}.Domain.Tests" project, in the "{ReferencedEntity}" folder for the "{ReferencedEntity}DataSeedContributor.cs" file.

So it's now looking in the correct project (that was fixed), but now it's look in the incorrect folder (that was broken in the process).

Please advise.

Thank you for the response, the info about 8.0.2, and the temporary workaround. Can you tell me which Github issue or pull request the fix relates too?

Here's a screenshot of Visual Studio after ABP Suite generates the error. Note the two areas in the red squares. The file paths don't match.

Thank you. Since the "libs" folder is not included in the code by default when pushing to a Git repo, can anyone provide steps (YAML code) to restore the contents of the "libs" folder during an Azure DevOps build pipeline?

After sending stdout to a log file I was able to see the source of the problem...

Volo.Abp.AbpException: Could not find file '/libs/bootstrap/css/bootstrap.css'

In my Azure app service my "wwwroot" folder did not have a libs folder, and this was the reason for the error. So I investigated to find out why the libs folder is missing. It turns out that the .gitignore file produced by ABP Suite contains the following...

# Use abp install-libs to restore.
**/wwwroot/libs/*

So, when I committed my code, the contents of the "lib" folder were being ignored. I commented out the second line above and committed the entire contents of the "libs" folder to my code repo. Azure CI/CD then compiled, packaged, and deployed to the Azure app service. Finally the app loaded without errors.

I would like to understand more about why the .gitignore file generated by ABP Suite is configured by default to ignore the libs folder when it is clearly needed for the app to function. Is there an assumption that the developer will execute abp install-libs in the Azure DevOps build pipeline or on the server where the application is ultimately deployed?

As suggested in the linked question, I did the following:

1. I create a console app to generate two self-signed certificates
2. I uploaded both certificates into Azure
3. I obtained the thumbnails of each certificate
4. I added a WEBSITE_LOAD_CERTIFICATES app setting with a value of the two thumbprints, comma separated

The application event log no longer reports an error. It now says the following: Application 'C:\home\site\wwwroot\' started successfully. Process Id: 2912. File Version: 17.0.22341.2. Description: IIS ASP.NET Core Module V2 Request Handler. Commit: 7c810658463f35c39c54d5fb8a8dbbfd463bf747

However, when attempting to load the app in a browser I now see a different error.

I obtained the source of the error from the logs. Here it is.

Nevermind. I figured it out on my own. I had to uninstall ABP Suite, re-authenticate, create a new dummy application/solution, get the license key from the source code in that application, and copy it into the source code of my original application. The reason is because my application was created while I was still using the trial license. It wasn't clear that any applications created while using the trial license would need to be updated with a new license key (or how to do it). But, again, I figured it out.

hi

Please try to run app via dotnet run command the check the output and logs.

When we run the app via dotnet run we get the following output...

[10:16:50 INF] TRIAL-INFO - You are using the trial version of ABP and your expiry date is 2023-01-09
[10:16:51 ERR] ABP-LIC-0018 - djcw(redacted)jUX0: Your trial period has ended! - Please contact to license@abp.io to purchase a license.

I redacted some of the text above because I wasn't sure if it's private data. I went to the "Organization Management" page on the ABP Commercial website to view my license info. I see my API key, and I confirmed that this matches the API key we have on our NuGet.Config file (key="ABP Commercial NuGet Source").

Our license expires Jan 2, 2024. Our trial expired Jan 9, 2023, but as far as I know we are not using the trial license anymore. Is there some other place in our code we need to replace the trial license key with the purchased license key? In short, why is it still trying to use our trial license?