Activities of "Sturla"

I did this with suite and Blazor Server and it updates the package references in my Blazor project to a strange preview version of these two packages below. Try updating these to this

  <ItemGroup>
    <PackageReference Include="Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX" Version="2.3.*-*" />
    <PackageReference Include="Volo.Abp.AspNetCore.Components.Server.LeptonXTheme" Version="2.3.*-*" />
  </ItemGroup>

Please add to Suite creation information about each project in the UI. Is the project "tired, Blazor Server, PostgreSQL etc. This will make it easier to create a the same type of project to compare and update the code. And its just smart to have this information in the Suite to begin with for many other reasons.

And add a button in the dropdown, "create new version" that creates the same type of project using the same entities but with the newest version, this makes it easier to get a new version of the code to compare when updating between versions.

Add .editorconfig to all project/solution templates and update the code accordingly to have more consistency of code.

Like if I add this .editorconfig file, from David McCarter, to a brand new project I get over 70 errors, 400 warnings and 2200 suggestions...

There are probably lot in there that could be suppressed and not be used in this codebase but wouldn´t it be great to have some standard and help users from the start?

Update It's even much worse than that... because try to create a new vanilla solution and add some domain item and let it create code and there are default warnings in every single project.

So if I wanted to add <TreatWarningsAsErrors>true</TreatWarningsAsErrors> to the projects I would have to do lots of extra work cleaning up these warnings (that are now error) every time I add something with Suite.

Don´t you agree that for a framework this should not be like that?

Yes that´s correct. I chose probably the only symbol that didn´t work.

But it would be great to know how to enable the env´s and I would even go so far to say that they should be enabled by default...

I managed to make this work but only by using Environment.GetEnvironmentVariable("ConnectionStrings:Default")

I tried to add AddEnvironmentVariables() to CreateHostBuilder but that didn´t take.

So here is what I had to do.

docker run --rm \
-e ConnectionStrings:Default="$connection_string" \
${{ env.DEV_AZURE_CONTAINER_REGISTRY }}/dbmigrator:${{ github.sha }}

and the StartAsync()

public async Task StartAsync(CancellationToken cancellationToken)
{
        var envConnectionString = Environment.GetEnvironmentVariable("ConnectionStrings:Default");    
        if (!string.IsNullOrEmpty(envConnectionString))
        {
            _configuration["ConnectionStrings:Default"] = envConnectionString;
            Log.Logger.Information("Using ConnectionStrings:Default from environmental variable");
        }
        
        .... rest of the code..
    }
}

There was also one other issue and that is I was using a $ in my password and that doesn´t work because the docker run command is running in Linux using bash and then the $ is handled as a variable and it (and following letters) are skipped!

Ok that worked BUTI don´t want to have the database password hardcoded in the docker file/source control. That is not a a future solution!

I would think that the environment variable should take precedence over the appsettings.json file, correct? It seems like its getting part of the connection string at least since it tries to connect to the server (so it has read that part of the env connection string) but has problem with the password... I don´t get this..

And I don´t have any custom code at all in my DbMigrator.

So what do you recommend I do here?

Hi maliming sorry I don´t understand what you are referring to?

I am able to get the connection string into my docker image and it is able to try to connect to the server (if I put e.g. a wrong server it reports that there is no such server etc.)

And from the AbpDbConnectionOptions code and its documentation I can´t see anything that could help me there.

But there is something in the abp.io framework interfering in the connection but what and why?

Please make these windows that contain subdomain users a popup grid or something. Its super hard and dangerous to be working with it like this

Another Suite one

If you add an entity with relationship to Identity it will fail on creation because the dbContext does not have using Volo.Abp.Identity; so need to add that and re-run the creation in Suite.

It would be great if Suite could just add that using automatically.

I have few ideas for Suite functionality

Make it possible to

• Make Suite more design friendly so its easier to rationalise over the design before creating code.
  • Add description to classes and properties in the Suite UI that will then be added as comments in the code.
  • View the design as a Database Schema Diagram. That way you don´t have to navigate between entities or create the code, apply migrations to a db and then view the schema...
• Ability to add more than just domain services with Suite.
  • I would like to be able to easily add a service from UI to repository layer where it communicates with a 3rd party API (imagine any Azure service).
  • This would come with all the needed bells and whistles needed (Polly/Refit/etc).
  • No database/EF related stuff.
  • Ability to add the endpoint we want to communicate with into the UI for auto discovery and code generation (e.g. for response dto´s).
• Ability to load entities from a database with their relationships (many-to-x).

I think that Suite has lot of possibilities to be a even grater tool than its now!