-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Simplify sqlite authoring now that we're 64bit only #57836
Conversation
src/VisualStudio/CSharp/Test/Microsoft.VisualStudio.LanguageServices.CSharp.UnitTests.csproj
Show resolved
Hide resolved
…ing for some reasons
Also tagging @Therzok . Need to make sure this won't be an issue for VS4Mac. |
This change only impact our vsix, so VS4Mac should be fine (or rather, won't be broken because of this) |
cc @davidwengier for the VSMac awareness |
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.
Checked sqlitepcl.raw and it seems like probing is allowed for adjacent or RID. So we're safe.
LE: Just checked, we are bundling the native library ourselves, so we won't be impacted here, since Roslyn isn't responsible for loading the assemblies.
Thanks very much @Therzok . @davidwengier there should be no concerns here for you. Thanks all! |
if @Therzok is happy, i'm happy. |
<Content Include="$(NuGetPackageRoot)\sqlitepclraw.lib.e_sqlite3\$(SQLitePCLRawbundle_greenVersion)\runtimes\win-x64\native\e_sqlite3.dll"> | ||
<Link>runtimes\win-x64\native\e_sqlite3.dll</Link> | ||
<Link>Core\e_sqlite3.dll</Link> |
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.
❔ Can we not place it in Core\runtimes\win-x64\native\e_sqlite3.dll?
Fixes #57827
This also addresses the issue where on CoreCLR calling into sqlite woudl result in a dll-not-found exception happening. Effectively, we just place
e_sqlite.dll
next to all theSQLitePCLRaw.xxx
dlls we include. Being right next to them seems to always work for dynamic loading for our two supported scenarios.I'm hoping this simple approach is acceptable.
I have manually validated this both for normal OOP and CoreCLR oop.
Note: i'm not sure if this impacts VS4Mac.