-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/2.1] Update to SQLitePCLRaw 1.1.15 #29433
Conversation
Need to mirror SQLitePCLRaw.bundle_green 2.1.2 |
@dotnet/dnceng can somebody help with this? |
This will also require a submodule update in aspnetcore's 2.1 branch, and (I think) a change to patchconfig.props - @dougbu will that be sufficient to get these EF packages building? |
May need to ask in First Responders channel. |
No, will need to change build/submodules.props in dotnet/aspnetcore. Also need to update versions.props and probably build/dependencies.props in this PR to align w/ next version. Or we should do a branding PR then merge this, both before updating the submodule in dotnet/aspnetcore and changing its build to build EF. |
See #15369 for example |
done :) |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
This comment was marked as outdated.
This comment was marked as outdated.
Looks like it's failing because it's using version 2.1.526 of the SDK which doesn't support NuGet's |
In other words, this will break compatibility with VS2017 |
@bricelam is there a workaround for the problem you described❔ Would be good to get this in this month. |
@bricelam Is there anything blocking this now that we have the go-ahead from Tactics on using the newer SDK? |
Hmm... Trying to manually verify the packages, I get Library e_sqlite3 not found. If I specify a RuntimeIdentifier, it works. @ericsink I don't think the build script is working as expected. Instead of a |
Coming up to speed here on the context... you're trying to use recent builds of SQLitePCLRaw (2.1.2) with EFCore 2.1? Which is several years old? It never occurred to me that my current builds would need to work with configurations that old, although I can't defend any reason why not. Anyway, that targets file for .NET Framework scenarios is a never ending source of problems. The last time somebody convinced me to make significant changes in that area was ericsink/SQLitePCL.raw#389 , the goal of which was to support It's also possible that I broke something with an associated change to the code in the dynamic provider. I'll need to dig into this to figure things out. If by chance you want to suggest a fix, feel free. |
So I constructed a quick test, and if I tweak the So it would seem that I also do still get that "one (arbitrary?) e_sqlite3.dll copied to the output directory". I'm not sure what's putting it there. Perhaps this is related to whatever |
Running a build with
Which seems consistent with the observation above that it is (no longer | not) safe to assume that I find the available documentation to be lacking when it comes to arcane details of the behavior of msbuild properties like this. Guidance welcome. |
@bricelam Any suggestions for what I should do here? My goal would be to find a way to fix that targets file such that:
But I'm not sure (yet) how to do that. It would seem that AFTER @AArnott suggested the current approach (the |
I doubt |
@AArnott 2.1 is still supported for ASP.NET Core applications targeting .NET Framework. This is for an MSRC relating to that. |
I used the term "default value" rather imprecisely, intending to mean "any value that property ever gets that was not assigned by the developer editing the csproj file". :-) |
@ajcvickers Makes sense. And what version of the .NET SDK (or Visual Studio) are you using? |
@AArnott I was using the 7.0 SDK to manually verify the packages. (With a project targeting .NET Framework) |
@ajcvickers @bricelam, is this a /cc @wtgodbe |
@dougbu We ran into issues with this change and have taken a new approach. As soon as the new build passes, yes, let's get it into the March 2.1.x patch. And yes, ASP.NET Identity should update its dependencies on these EF packages. |
We may need to mirror the 1.1.15 versions of these packages when they're available: (If we do that on 2.1)
|
IIRC, that happens automatically when we update dotnet/aspnetcore to produce dotnet/efcore packages. It's all hinged on a one-line change in aspnetcore. |
release/2.1 branches use |
@@ -684,6 +685,12 @@ public override void Select_datetime_millisecond_component() | |||
} | |||
#endif | |||
|
|||
[ConditionalFact(Skip = "Issue#21541")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, this actually passes on .NET Framework and isn't regressed there. Just skipping everywhere since that's what we did for a while in downstream branches.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Part of #29429