Hi
No, it is not. This is for pushing packages - where a 409-Conflict makes absolutely sense. Here, we are not pushing any packages, it's just a package restore.
We are using docker to develop a solution using abp. This means docker will often need to download ABP packages. We often get the following error with multiple packages, sometimes for hours, and then the error suddenly disappears. We don't know what to do currently and would like to ask for help.
#132 43.50 /usr/share/dotnet/sdk/5.0.400/NuGet.targets(131,5): error : Failed to download package 'Volo.Abp.Account.Pro.Shared.Application.4.4.2' from 'https://nuget.abp.io/redacted/v3/package/volo.abp.account.pro.shared.application/4.4.2/volo.abp.account.pro.shared.application.4.4.2.nupkg'. [/src/src/company.product.AgentHttpApi.Host/company.product.AgentHttpApi.Host.csproj] #132 43.50 /usr/share/dotnet/sdk/5.0.400/NuGet.targets(131,5): error : Response status code does not indicate success: 409 (Conflict). [/src/src/company.product.AgentHttpApi.Host/company.product.AgentHttpApi.Host.csproj]
The step that provokes this is: RUN dotnet restore "src/company.product.AgentHttpApi.Host/company.product.AgentHttpApi.Host.csproj" --configfile "nuget.config"
Any idea what could cause this?
Thanks Michel
Any chance that this could be improved? We use a one-db-per-tenant approach as well, and having TenantID columns is just distracting :)
Hi @MichelZ
Yes, the release of 4.4.1 is still in progress, could you try again when the release is completed. We hope to complete it today.
Thanks,
Hi
The problem is not updating to 4.4.1, the problem is that all of my workflow starts to fail with the current version. All nuget restores for 4.4.0 started failing yesterday with the conflict message. This is very disruptive as I'm using docker to build this like every couple of minutes, and docker doesn't cache the packages, so I can't really build anymore.
I am currently getting "Response status code does not indicate success: 409 (Conflict)" when trying to do dotnet restore. It happens from time to time, and my best guess is that it has something to do with when a new release is put up there. As far as I can see 4.4.1 is in the process of being released currently.
I do have the same issue actually, but did not get around investigating it yet, as I'm waiting for something else to be fixed first.
hi
Is the samesite thing also required in the IdentityServer project?
Yes, It should be add in the project that using the IdentityServer.
Thanks, that was it!
When can we expect the next patch release?
I am having the same issue. The samesite thing from the article did not work for me. Is the samesite thing also required in the IdentityServer project?
The reason to want http is for development in Docker, it makes it easier not having to worry about certs
Hi
We are trying to make the DbMigrator project aware of different environments by using an appsettings.json per environment. This is usually straight forward by just creating appsettings.<Environment>.json file.
Unfortunately in the DbMigrator project this does not seem to work. While troubleshooting I have injected IConfiguration into the DbMigratorHostedService, and I did a Console.WriteLIne(_configuration.GetConnectionString("Default")); in the StartAsync method. Surprisingly, THIS WORKS and it gives the correct connection string! However, strangely it executes the DbMigration on the connection string from the original appsettings.json, instead of the one from IConfiguration..... I can't explain why. I can change the appsettings.json, and it connects to a different database, so it's definitely using that one.
Any ideas?
Thanks Michel