Simplify sqlite authoring now that we're 64bit only#57836
Simplify sqlite authoring now that we're 64bit only#57836CyrusNajmabadi merged 3 commits intodotnet:mainfrom
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.
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. |
| <ItemGroup> | ||
| <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.
❔ 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.dllnext to all theSQLitePCLRaw.xxxdlls 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.