Hi! I'm having some issues upgrading the ABP suite. I updated the CLI to 0.9.8 this morning, which worked fine, so I then decided to update the Suite.
I ran abp suite update and got the following error:
Tool 'volo.abp.suite' failed to update due to the following:
The settings file in the tool's NuGet package is invalid: Settings file 'DotnetToolSettings.xml' was not found in the package.
Tool 'volo.abp.suite' failed to install. Contact the tool author for assistance.
I also tried using dotnet tool update -g Volo.Abp.Suite --add-source https://nuget.abp.io/<my-private-key>/v3/index.json and this gave the same error.
Looking at the support forums, I noticed this post and based on that I tried uninstalling then re-installing the suite. The uninstall worked fine, but the install gives me the above error again.
Finally, based on the final comment in the linked post, I looked at deleting the c:\Users\my_username\ .dotnet\tools\abp-suite.exe file. However, that's not there on my machine now I've uninstalled the suire.
Do you have any ideas how I can get it working again please? It feels like it might be a misconfiguration in the nuget repository, but I'm happy to be corrected on that.
Thanks!
Hi there. We've run a SAST tool (GitHub advanced security for DevOps) on our Blazor server project and it has noted high severity vulnerabilities in the following packages, which are bundled as part of the ABP libraries:
Are these libraries due to be updated as part of the v9 release? If not, would it be possible to get them patched as part of the next upgrade please?
Thanks! :)
Hi there. Got a bit of a complex question regarding DbMigrator that's had me stumped for a couple of days now. Would love some guidance.
Background: I want to run the DbMigrator exe as part of an Azure Devops release pipeline. I also want to use AD authentication to authenticate the connection to the database as I don't want to have to have the SQL admin password in the connection string. As such, I'm running the exe in an Azure Powershell task. When I ran the exe in a Command Prompt task using SQL auth (with admin password in connection string) it worked fine.
Issue: When I attempt to run the exe in an Azure Powershell task, the migrator appears to run and then quit out straight after. There don't appear to be any errors though, nothing is written to the console and the Logs.txt file has nothing written to it.
To recreate this behaviour, I tried creating a Powershell script on my local machine to run the migrator. See below:
$filePath = 'C:\path_to_project\MyProject.DbMigrator\bin\Debug\net8.0\MyProject.DbMigrator.exe'
$proc = Start-Process $filePath -PassThru
$proc | Wait-Process
I saw the same behaviour: console window opens and then immediately closes, no logs written to Logs.txt or visible output from the app.
I put some Console.WriteLine and Task.Delay calls in the code of the migrator app and it then did start outputting stuff. It seems that the line that fails is in DbMigratorHostedService where the call await application.InitializeAsync() is made. It seems to basically just crash out the application at this point. I added a try catch block but no exception was raised.
I've put the customised code at the end of this message, but when running from Powershell, the last output I see is 44444444444444444444 (my debugging message) and then the console window closes.
It works totally fine using a command prompt. I see all my Console.WriteLines and it gets past that application.InitializeAsync part.
Question(s): Is it possible to run the DbMigrator from a Powershell script? Following on from that, is it possible to run it from an Azure Powershell task in an Azure DevOps CI/CD pipeline?
Alternatively: is there an alternative way I can run the migrator in my pipeline using AD authentication, meaning I can bypass this altogether?
DbMigratorHostedService.cs:
public class DbMigratorHostedService : IHostedService
{
private readonly IHostApplicationLifetime _hostApplicationLifetime;
private readonly IConfiguration _configuration;
public DbMigratorHostedService(IHostApplicationLifetime hostApplicationLifetime, IConfiguration configuration)
{
_hostApplicationLifetime = hostApplicationLifetime;
_configuration = configuration;
}
public async Task StartAsync(CancellationToken cancellationToken)
{
Console.WriteLine("33333333333333333333");
await Task.Delay(2000);
using (var application = await AbpApplicationFactory.CreateAsync<RopeManagementDbMigratorModule>(options =>
{
options.Services.ReplaceConfiguration(_configuration);
options.UseAutofac();
options.Services.AddLogging(c => c.AddSerilog());
options.AddDataMigrationEnvironment();
}))
{
Console.WriteLine("44444444444444444444");
await Task.Delay(2000);
try {
await application.InitializeAsync();
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
Console.WriteLine("55555555555555555555");
await Task.Delay(2000);
await application
.ServiceProvider
.GetRequiredService<RopeManagementDbMigrationService>()
.MigrateAsync();
Console.WriteLine("6666666666666666666");
await Task.Delay(2000);
await application.ShutdownAsync();
_hostApplicationLifetime.StopApplication();
}
}
public Task StopAsync(CancellationToken cancellationToken)
{
return Task.CompletedTask;
}
}
Hi. We are looking to understand how you decide to upgrade packages and when you choose to stick to certain versions.
A specific scenario we have right now is that we are currently seeing a critical issue reported by our SCA tool (mend.io) in the uppy.js dependency. ABP.io is currently using 1.X of uppy and are two major versions behind.
https://www.mend.io/vulnerability-database/CVE-2022-0086
Is uppy on a backlog list somewhere to be updated? Have you chosen not to upgrade this for a reason? I understand we could upgrade try and upgrade this ourselves but there would be a high likelihood of breaking changes that we would then need to resolve.
Any help here would be appreciated. Thank you