You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, I'm a huge fan of sqlc and I use it every single personal go project where I need database support. Good work 🙏
I noticed that you have started adding support for other languages incl. typescript and kotlin. In my day to day work I write a lot of code in C# which use postgres database.
Would you consider adding support for C# based apps?
I might be able to help but I'm still learning Go so I might need some support in how to get started if you want help with this
Would you consider adding support for C# based apps?
I would. The main issue that I don't know what good C# support would look like. Kotlin support was added by a contributor, so I see no reason by C# couldn't be added the same way.
The first step would be to gather some more information. What does your current setup look like? What code are you writing by hand? What libraries are you using?
My setup is to hand write the C# classes and the sql, then dapper (micro orm) providing the mapping from sql to my C# POCO class with the help of reflection. The thing is that I need to manually keep track that my queries and the c# class needs to match - this can be a bit error prone at times.
Let me try and come up with an example of how the auto generated code could look like in the next couple of days.
Reacted by Erik Berkun-Drevnig, Ewout van Mansom, Bryan Kenote and Nicholas Preston
Just recently found that library and it looks really cool, especially when its use is considered for projects already managing DB entities with rather low-level ORMs like aforementioned Dapper.
@kyleconroy - is C# support is still something you'd still actively consider? There're in fact three main approaches when building an app in C# with DB communication in mind:
pure ADO.NET
Dapper as lightweight overlay for ADO.NET
Entity Framework which is in fact much heavier overlay for ADO.NET allowing for querying a DB with C# code instead of SQL queries
Dapper is a DB-agnostic ORM meaning it supports many (if not all) .NET ADO providers being an interesting safe choice. Pure ADO.NET may be closer to your original approach for sqlc, but is not a first choice for most of the projects (in terms of popularity Entity Framework is probably something used for most of business projects with complex domains).
I'd say the best option would be to get started with Dapper (as it abstracts many lower-level concepts from ADO.NET) and give it a try as the simplest option.
Personally I think pure ADO.NET with Npgsql is the right way to go. Dapper, IMO, adds an unnecessary layer of reflection-based object field mapping.
The point of sqlc is to generate simple, performant, type-safe code to access queries and query results. It doesn't really matter if that code ends up being verbose compared to what you can get with Dapper.
I also think there's a strong argument to be made for avoiding another dependency.
Codegen plugins are now stable enough. Both Python and Kotlin support has been migrated to plugins. This means that if someone would like to try their hand at C# support, you aren't blocked getting your changes into the sqlc codebase.
I'm trialing it and it's super-easy to set up C# DTOs and interfaces and run existing stored procedures or inline SQL.
It's like Dapper, but on steriods. No EF Context 💩. No need to fill in the gaps for ADO.NET. Just pure bliss as advertised (at least, so far that's been my experience).
For anyone interested in SQLC for C# @SockworkOrange and I have been developing a plugin for C# as said above.
Now we have a stable mature 1st version (v0.10.0) with support for MySQL and Postgres as well as all available .NET target frameworks, take a crack at it and we'd love feedback if you have any issues, PRs, just go for it 🎉
Activity
kyleconroy commentedon Mar 9, 2020
I would. The main issue that I don't know what good C# support would look like. Kotlin support was added by a contributor, so I see no reason by C# couldn't be added the same way.
The first step would be to gather some more information. What does your current setup look like? What code are you writing by hand? What libraries are you using?
eikster-dk commentedon Mar 14, 2020
Currently the following libraries are used when I work with postgres and c#:
My setup is to hand write the C# classes and the sql, then dapper (micro orm) providing the mapping from sql to my C# POCO class with the help of reflection. The thing is that I need to manually keep track that my queries and the c# class needs to match - this can be a bit error prone at times.
Let me try and come up with an example of how the auto generated code could look like in the next couple of days.
kamil-mrzyglod commentedon Aug 12, 2022
Hey,
Just recently found that library and it looks really cool, especially when its use is considered for projects already managing DB entities with rather low-level ORMs like aforementioned Dapper.
@kyleconroy - is C# support is still something you'd still actively consider? There're in fact three main approaches when building an app in C# with DB communication in mind:
Dapper is a DB-agnostic ORM meaning it supports many (if not all) .NET ADO providers being an interesting safe choice. Pure ADO.NET may be closer to your original approach for
sqlc, but is not a first choice for most of the projects (in terms of popularity Entity Framework is probably something used for most of business projects with complex domains).I'd say the best option would be to get started with Dapper (as it abstracts many lower-level concepts from ADO.NET) and give it a try as the simplest option.
d47id commentedon Sep 14, 2022
Personally I think pure ADO.NET with Npgsql is the right way to go. Dapper, IMO, adds an unnecessary layer of reflection-based object field mapping.
The point of sqlc is to generate simple, performant, type-safe code to access queries and query results. It doesn't really matter if that code ends up being verbose compared to what you can get with Dapper.
I also think there's a strong argument to be made for avoiding another dependency.
Jlll1 commentedon Sep 16, 2022
C# support would also mean the need for supporting SQL Server, since that's what the majority of C# projects are running.
kyleconroy commentedon Nov 9, 2022
Codegen plugins are now stable enough. Both Python and Kotlin support has been migrated to plugins. This means that if someone would like to try their hand at C# support, you aren't blocked getting your changes into the sqlc codebase.
nickpreston24 commentedon May 2, 2023
Hi there.
The easy way to get C# support is this magic library. https://github.com/jonwagner/Insight.Database
I'm trialing it and it's super-easy to set up C# DTOs and interfaces and run existing stored procedures or inline SQL.
It's like Dapper, but on steriods. No EF Context 💩. No need to fill in the gaps for ADO.NET. Just pure bliss as advertised (at least, so far that's been my experience).
SockworkOrange commentedon Feb 15, 2024
@doron050 and myself are starting work on C# support in here :)
doron050 commentedon May 18, 2024
For anyone interested in SQLC for C#
@SockworkOrange and I have been developing a plugin for C# as said above.
Now we have a stable mature 1st version (v0.10.0) with support for MySQL and Postgres as well as all available .NET target frameworks, take a crack at it and we'd love feedback if you have any issues, PRs, just go for it 🎉
TLDR
For further information refer to https://github.com/DaredevilOSS/sqlc-gen-csharp
SockworkOrange commentedon Jul 19, 2024
@kyleconroy can be closed then:)
doron050 commentedon Dec 27, 2024
Hi, @kyleconroy, just a reminder, can be closed :)
kyleconroy commentedon Mar 24, 2025
I was waiting for everything to be stable. Sounds like that just happened this month. Closing!