Activities of "jon@steer73.com"

Great stuff - just tried it and it worked great! Thanks for the help!

Hi

you can use AzureCLI@2 task for running migrations with Azure AD integrated

Azure SQL connection string will look like below

thanks,

Ah ok thanks - I'll give that a try and let you know how I get on.

Hi Anjali - thanks for the reply. I used both of those links when setting up my project as it happens.

Unfortunately, they don't really address my issue. They both use SQL authentication (i.e. SQL login and password), rather than the preferred AD authentication.

Like I mentioned, I was able to get the migrator app to run in a command line task using SQL auth, but my specific problem arose when I tried to get it to use AD authentication.

The site itself is running fine using AD auth - it's literally just the DBMigrator I can't get working.

• ABP Framework version: v8.0.1
• UI Type: Blazor Server
• Database System: EF Core (SQL Server)
• Tiered: no
• Exception message and full stack trace: n/a
• Steps to reproduce the issue: See below

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;
    }
}

• ABP Framework version: v7.4.2
• UI Type: MVC
• Database System: EF Core (PostgreSQL)

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