SQLite is pretty much the only remaining native dependency in my C# codebases, and as much as I love the engine, I wish that could go away.
Replacing System.Data.SQLite with Microsoft.Data.Sqlite already helped with Apple ARM builds (despite all the small differences that only showed up in actual use), but pretty much the only native debugging I do these days is related to the "batteries" -- the linked article outlines the general strategy pretty well.
On the one hand, I feel bad about turning into a "pure-Java only" kind of developer (I mean, limiting yourself to H2, the horror...), but on the other hand, I'm increasingly starting to see their point. Oh, well, if AI actually works, I'm sure Microsoft.Native.Data.Sqlite is just around the corner (and, later edit, to prevent confusion: the abuse of 'Native' here is mostly making fun of Microsoft naming conventions -- they'd call it 'Interop' if it were like truly native).
I guess you would need to switch to a dotnet native database, like litedb. Even if you would use postgres, there would be native code left, decoupled from the dotnet application though.
It would be interesting though, if it's possible to run webassembly inside the CLR (dotnet runtime).
But I don't really get the issue with native code inside a dotnet application. In the end everything you do in dotnet ends up being executed as native code. Even a simple console.writeline() is implemented in native code.
Exactly because of the benefits of this, there is the meme CGO is not Go, as any package with native dependencies kills the possibility to cross-compile with the Go toolchain.
Same applies to the pain of using native dependencies in Perl, Python, Ruby,...
Many .NET developers are only now slowly the pain of having so many dependencies to C++ DLLs, COM and C++/CLI.
One of the reasons why we still do so many .NET Framework projects at my employer agency.
> One of the reasons why we still do so many .NET Framework projects at my employer agency.
What's the issue with porting them to .net (core)? Most of that stuff is still supported, if you only have native windows DLLs you would still be constrained to windows only, but still better than staying on ancient .net framework.
I fail to understand why they feel the need to test their setup with the latest Alpine while at the same time using out of date and unsupported versions of .NET.
I really don't get why people still bother with unsupported dotnet versions. There might be a few edge cases that prevent upgrading, but in 99% an upgrade from dotnet 3.1 to dotnet 10 is completely smooth.
Running in an unsupported dotnet version also means that there won't be any security patches. Not great.
SQLite is pretty much the only remaining native dependency in my C# codebases, and as much as I love the engine, I wish that could go away.
Replacing System.Data.SQLite with Microsoft.Data.Sqlite already helped with Apple ARM builds (despite all the small differences that only showed up in actual use), but pretty much the only native debugging I do these days is related to the "batteries" -- the linked article outlines the general strategy pretty well.
On the one hand, I feel bad about turning into a "pure-Java only" kind of developer (I mean, limiting yourself to H2, the horror...), but on the other hand, I'm increasingly starting to see their point. Oh, well, if AI actually works, I'm sure Microsoft.Native.Data.Sqlite is just around the corner (and, later edit, to prevent confusion: the abuse of 'Native' here is mostly making fun of Microsoft naming conventions -- they'd call it 'Interop' if it were like truly native).
I guess you would need to switch to a dotnet native database, like litedb. Even if you would use postgres, there would be native code left, decoupled from the dotnet application though.
It would be interesting though, if it's possible to run webassembly inside the CLR (dotnet runtime).
But I don't really get the issue with native code inside a dotnet application. In the end everything you do in dotnet ends up being executed as native code. Even a simple console.writeline() is implemented in native code.
Exactly because of the benefits of this, there is the meme CGO is not Go, as any package with native dependencies kills the possibility to cross-compile with the Go toolchain.
Same applies to the pain of using native dependencies in Perl, Python, Ruby,...
Many .NET developers are only now slowly the pain of having so many dependencies to C++ DLLs, COM and C++/CLI.
One of the reasons why we still do so many .NET Framework projects at my employer agency.
> One of the reasons why we still do so many .NET Framework projects at my employer agency.
What's the issue with porting them to .net (core)? Most of that stuff is still supported, if you only have native windows DLLs you would still be constrained to windows only, but still better than staying on ancient .net framework.
Would the WebAssembly version of SQLite be OK for you?
I fail to understand why they feel the need to test their setup with the latest Alpine while at the same time using out of date and unsupported versions of .NET.
On the flip side, good debugging!
I really don't get why people still bother with unsupported dotnet versions. There might be a few edge cases that prevent upgrading, but in 99% an upgrade from dotnet 3.1 to dotnet 10 is completely smooth.
Running in an unsupported dotnet version also means that there won't be any security patches. Not great.