Closed DavidSSL closed 3 years ago
Hi @DavidSSL , most of the Bitwarden internal engineering team does their development on macOS using various tools including VS for Mac, VS Code, Rider and even vim. With that, a few of the folks use Rider which natively supports Microsoft's SQL projects on Mac/Linux which is a beautiful thing, I personally haven't moved over to that and when it comes to editing our dbproj sql files, I simply edit them in VS Code and cross my fingers that the DB will compile in our Windows build action. We don't actually using any of the compare + deployment operations provided, it's simply used for more easily/consistently version-controlling and reference checking of our SQL database. I'll take a look at what you've provided and linked as it looks promising, thanks for that!
Hi @cscharf, could you (most likely one of your colleagues) please elaborate on the following
a few of the folks use Rider which natively supports Microsoft's SQL projects on Mac/Linux
because I have Rider installed and for me when I try to build the solution without the modifications elaborated in the OP, I get:
The imported project "/usr/share/dotnet/sdk/3.1.401/Microsoft/VisualStudio/v16.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the expression in the Import declaration "/usr/share/dotnet/sdk/3.1.401/Microsoft/VisualStudio/v16.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" is correct, and that the file exists on disk. /home/david/Work/GitHub/Bitwarden/server/src/Sql/Sql.sqlproj
Hi @DavidSSL , I may have misunderstood what our other devs are doing with Rider (I don't personally use Rider) and apparently I misspoke, they don't really build the project, but they can at least edit/load the files and connect them to the database for queries, etc. I actually kind of like the proposed solution you had, however we'll likely approach it with a 1:1 swap of the dbproj with the proposed project type and directly include the SQL files in the same project directory (so a direct project swap in the solution). Since this project isn't used by our CI/CD pipeline currently it makes sense for how we're using it.
For you, as of right now, you can always just use VS Code or other editor for those SQL files in the project and/or unload/exclude the project from the build.
Is there any update on removing the Visual Studio dependency?
Hi @9p4 , I'll drop a note to our process improvement squad to see if anyone is interested in picking this up and evaluating what this would take (including our internal process for DB updates, etc.)
Since the project is developed in .net core I thought I would give it a go on a Linux box. However, the Sql project will not fail due to the integration of SSDT with Visual Studio.
Hence, what I ended up doing was follow the instructions I found here:
https://erikej.github.io/efcore/2020/05/11/ssdt-dacpac-netcore.html
and
https://shawtyds.wordpress.com/2020/08/26/using-a-full-framework-sql-server-project-in-a-net-core-project-build/
and I've managed to get the project to build. In fact I've forked the code here where you can find what I've done:
https://github.com/DavidSSL/server
However I've never used SQL projects before and I don't know whether that what I've done is correct. Having said that it is clear that the PostgresSQL section is not "working" since in my SQL.Build project I only look at the "dbo" folder.
My query is whether anyone is actually developing on Linux. If so, is there a "prescribed" way of doing so since I don't think that what I've done is correct?
Is it possible to somehow reference the SSDT nuget package and break the current dependency on the SSDT installed as part of Visual Studio?