@maliming I see there is a new version of ABP (7.3.1). When I update CLI to 7.3.1 and then run the abp update command, the NPM packages are updated to 7.3.1 however, the nuget packages are still 7.3.0. Is this the expected behavior of this release?
@maliming Do you guys have a contingency plan in case myget does not return?
From my perspective, this is looking very much like a dead project at this point.
Attempting to update my project from 7.2.3 to 7.3.0 using the ABP CLI update command gives an error.
$ abp update ABP CLI 7.3.0 Object reference not set to an instance of an object. System.NullReferenceException: Object reference not set to an instance of an object. at Volo.Abp.Cli.ProjectModification.VoloNugetPackagesVersionUpdater.GetLatestVersionFromMyGet(String packageId) in D:\ci\Jenkins\workspace\abp-volo-release\abp\framework\src\Volo. Abp.Cli.Core\Volo\Abp\Cli\ProjectModification\VoloNugetPackagesVersionUpdater.cs:line 281 at Volo.Abp.Cli.ProjectModification.VoloNugetPackagesVersionUpdater.UpdateSolutionAsync(String solutionPath, Boolean includePreviews, Boolean includeReleaseCandidates, Boolean swi tchToStable, Boolean checkAll, String version) in D:\ci\Jenkins\workspace\abp-volo-release\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\ProjectModification\VoloNugetPackagesVersi onUpdater.cs:line 42 at Volo.Abp.Cli.Commands.UpdateCommand.UpdateNugetPackages(CommandLineArgs commandLineArgs, String directory, String version) in D:\ci\Jenkins\workspace\abp-volo-release\abp\frame work\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\Commands\UpdateCommand.cs:line 80 at Volo.Abp.Cli.Commands.UpdateCommand.ExecuteAsync(CommandLineArgs commandLineArgs) in D:\ci\Jenkins\workspace\abp-volo-release\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\C ommands\UpdateCommand.cs:line 44 at Volo.Abp.Cli.CliService.RunInternalAsync(CommandLineArgs commandLineArgs) in D:\ci\Jenkins\workspace\abp-volo-release\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\CliServic e.cs:line 169 at Volo.Abp.Cli.CliService.RunAsync(String[] args) in D:\ci\Jenkins\workspace\abp-volo-release\abp\framework\src\Volo.Abp.Cli.Core\Volo\Abp\Cli\CliService.cs:line 77
We removed offline_access which helped resolve the original issue. If you close the browser and walk away for more than an hour, you now must login again to access the site.
However, it creates another problem with the angular application. Once the IdentityToken expires, but before the AccessToken expires, the application automatically logs the user out and back in. If they are in the middle of a editing form when this happens, their data is lost as they are returned to the home page.
You have already user id in our test system at https://synergyz-test.otised.net if you want to see what happens for yourself.
We added the following code to the PreConfigureServices method in the HostModule so that we could iterate faster on the testing. The login succeeds, after 4 mins, the user is automatically logged out and back in without being prompted for a user / password.
PreConfigure<OpenIddictServerBuilder>(builder =>
{
builder.SetAccessTokenLifetime(TimeSpan.FromMinutes(5));
builder.SetIdentityTokenLifetime(TimeSpan.FromMinutes(2));
});
Thanks for the screenshot. Is that information available anywhere so that your commercial clients can see it without opening a ticket?
Is there any place we can see the list of changes for LeptonX versions? I can see a new version "2.0.3" was pushed to the NuGet repository earlier today, but I cannot find any information on the fixes or enhancements in that version.
I will try that. Did you try running it without it being on the debugger? Since it is a timing issue, the debugger could potentially affect the issue.
No. I have not been able to reproduce this in a new project. The project with the issue was created using Suite v7.0.1. We have upgraded several of our projects to the latest version of ABP. This issue is only occurring in one of them. It is something specific to this project. However, I have not been able to isolate the problem.
This line of code:
var tenantConfiguration = await _tenantStore.FindAsync(tenantId);
From the MigrateAndSeedForTenantAsync method in the *TenantDatabaseMigrationHandler is blocking the insert statement for the new tenant record. Once this line of code fails with a timeout, the tenant record gets created. But there is no data seeded for the new tenant.
The tenant record creation should have been completed before MigrateAndSeedForTenantAsync is called. However, that is not the case in this project.
I can email you a link to a zip file of the project.
Trying to generate the proxies for angular gave the following message. Cannot read properties of null (reading 'replace')
Is there any way to get debug information when generating the proxies?
I tracked the problem down to the following issue. The {id} paramater in the route, was not in the parameters for the method. This worked in version 6, but it does not work in version 7. The solution was to remove the {id} parameter for the route since it was not being used. However, it took me 2+ hours to isolate this issue. Knowing which API endpoint caused the error could have saved me so much time.
[HttpGet]
[Route("{id}/available-models")]
public Task<PagedResultDto<LookupDt<int?>>> GetAvailableModelsAsync(LookupRequestDto input)
{
return _dictionaryAppService.GetAvailableModelsAsync(input);
}
Adding the code below resolved the problem and allowed all tests to run successfully to completion. After running this successfully multiple times, I then re-enabled the unit of work transactions and reran the tests. They ran successfully with the unit of work transactions enabled.
Configure<FeatureManagementOptions>(options =>
{
options.SaveStaticFeaturesToDatabase = false;
options.IsDynamicFeatureStoreEnabled = false;
});
Configure<PermissionManagementOptions>(options =>
{
options.SaveStaticPermissionsToDatabase = false;
options.IsDynamicPermissionStoreEnabled = false;
});