Deployment request for new preview nuget package: 5.2.0-preview4

[Havunen]

Hi,

Our application is having constantly slowness related to #2120 #2121

The estimated release date was supposed to be in the last month #2120 (comment) #2120 (comment)

Could we have a new release or preview release please!

[Havunen]

Is there any particular reason why the current main branch cannot be released as a new preview Nuget package? If its waiting for some fixes can't those be included in the next preview version?

[Havunen]

Or if there are some major issues with the current main branch, could those be opened as tickets to Github so the community could possibly help resolving them?

[David-Engel]

The current holdup is the team is working on internal escalations and a round of hotfix releases that are pushing out work on the next preview release. Looking forward, the next preview release should land sometime in November.

[Havunen]

Are there any blockers why current main branch cant be released as a new preview as is?

[Wraith2]

Time. The blocker is always dev time. You just have to get used to things moving slowly here.
In general there is no reason that you couldn't compile and use your own version from main until a release happens. Nothing inherently unsafe has been added as far as I'm aware.

[Havunen]

If I compile the nuget myself how can I override the dependency of existing third party libraries like EF?

[Havunen]

Would it be acceptable to have CI publish nightly releases to Nuget.org? Then if it would be automated every night if there are new commits it could publish a new package automatically and developers does not need to do it manually?

[ErikEJ]

If I compile the nuget myself how can I override the dependency of existing third party libraries like EF?

Not an issue, EF Core uses your explict reference

[ErikEJ]

Would it be acceptable to have CI publish nightly releases to Nuget.org? Then if it would be automated every night if there are new commits it could publish a new package automatically and developers does not need to do it manually?

Publishing daily builds to NuGet is not how you usually do this, you would set up an alternate NuGet server, and this is not something the team has done yet. You can however use the output package from the latest CI build: https://sqlclientdrivers.visualstudio.com/public/_build?definitionId=1139&_a=summary

[Havunen]

I downloaded the Artifact from the CI main branch and installed it as a local nuget package. However now C# compiler is throwing error about:
Error CS0012 The type 'SqlConnection' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Data.SqlClient, Version=5.0.0.0, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5'.

Comparing the nuget packages from CI pipeline to the published nuget packages in nuget org, it seems the CI artifact does not have public key token? Why is that?

Browsing through the package tree in Visual Studio shows that the package does get resolved but the code does not compile due to that error from AspNetCore.HealthChecks.SqlServer -Nuget startup configs

I dont think there is any relevant change in SqlConnection between 5.2 -preview3 and latest main branch that would cause this so it has to do something with the published CI artifact

@ErikEJ

[David-Engel]

You might need to make consuming packages of MDS a little more lenient in what they accept (if that's possible). We don't sign PR validation packages. (That would allow anyone to produce a signed package just by submitting a PR here.) I believe we also don't use the strong naming key on PR packages, which I believe is the problem you are hitting.

[Havunen]

That package is however out of my control. Also the way it depends on Microsoft.Data.SqlClient seems very standard to me https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks/blob/master/src/HealthChecks.SqlServer/HealthChecks.SqlServer.csproj#L11

[roji]

@Havunen you can take a direct reference to a newer version of Microsoft.Data.SqlClient in your application's csproj. That will use the newer package for your entire application, overriding the older transitive dependency via AspNetCore.Diagnostics.HealthChecks.

[Havunen]

@roji That is exactly what I did.

I downloaded the CI artifact.
I created a nuget.config file and added a local directory as a feed to the nuget.config.
I placed all the CI artifacts to the local nuget folder.
I changed entry level project package reference to <PackageReference Include="Microsoft.Data.SqlClient" Version="5.20.0-pull.29401" />
Then I try to compile the project and it fails to the error above.

I created a full repro here: https://github.com/Havunen/cant_use_microsoft_data_sqlclient_artifact/tree/main

[Santas]

+1 on separate nightly build or releasing the package more often.

[Havunen]

@David-Engel Is it possible to have a new preview version of the SQL Client published to Nuget please? Because of this issue #2179 (comment) it is not possible to build the Nuget manually. Or if it is not possible having a hotfix to fix the GC pressure works as well

This is the commit where the performance problem was fixed.
8323175
and it was a bug fix on top of this: #1866

[ErikEJ]

@Havunen Can you not download the artifact from the CI build?

[Havunen]

@ErikEJ I can download it, but I cannot use it. #2179 (comment)

full repro here: https://github.com/Havunen/cant_use_microsoft_data_sqlclient_artifact/tree/main just git clone and open it in visual studio

[ErikEJ]

@Havunen preview 4 is out now

[ErikEJ]

@JRahnama Could this be closed?

[Havunen]

Yes, I think this issue can be closed. If the GC issue still occurs I can open a new ticket. Thanks.