Request for Comment: dbatools 3.0 will be a C# binary module

[potatoqualitee]

I want it to load quickly like SqlServer and I want all the extras that come with C#. Tests will remain as ps1 files unless @andreasjordan wants differently (since he works in it the most) then I can accommodate.

Previously,

1. I don't know C# and that mattered
2. I wanted to keep dbatools accessible and functions are understood by more people, including me

We've had a drop in contributions, which is natural and understandable, so we can move forth with what is best for the project.

I was able to create an awesome module last night using the Ralph Wiggum and a great prompt. And beautifully, each unit had all the 4 parts Get/Set/Remove/Update. I'll be doing that for our commands AND I can make sure that they're pipable. So we can do best practices while we're at it.

I'll also remove some commands that need to go like Watch-DbatoolsUpdate or whatever it's called.

Accepting feedback from now till a get a chunk of time.

[andreasjordan]

Great idea. And a great chance for a lot of breaking changes to align the functionality of the commands.

That said: What about starting with a small subset of commands so that we have a base for discussion new rules for parameters etc.?

[potatoqualitee]

Agreed, we can have a dedicated branch for it, perhaps over at dbatools.library to start, and we go back and forth with the proposals. maybe do a whole section to start like the Ag commands.

[andreasjordan]

Some commands that should be in part 1:

• Connect-DbaInstance
• Get|New|Set|Remove-DbaDatabase
• Get|New|Set|Remove-DbaLogin
• Backup|Restore-DbaDatabase

And we can start with most of the Ag command as I can test them in my lab.

[potatoqualitee]

perfect, will do!

[niphlod]

Ahem/cough cough. It's difficilt to keep up with the current load of bugs/feature requests and we wanna move ALL the module to c#, while most of the *current* "maintainership" isn't well-versed in C# like he/She/them is in PS? Till the proposal is/was to turn *some functionality* like e.g. Connect-DbaInstance I'm up for It, not so much for the entire module. Please do mind that the most friction we historically had is, indeed, geared towards the c# parts of the module. Il lun 19 gen 2026, 20:10 Andreas Jordan ***@***.***> ha scritto:

…

*andreasjordan* left a comment (dataplat/dbatools#10103) <#10103 (comment)> Some commands that should be in part 1: - Connect-DbaInstance - Get|New|Set|Remove-DbaDatabase - Get|New|Set|Remove-DbaLogin - Backup|Restore-DbaDatabase And we can start with most of the Ag command as I can test them in my lab. — Reply to this email directly, view it on GitHub <#10103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA52BZEYMHN4Q332WY6I334HUT3TAVCNFSM6AAAAACSGCYBQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONRZG42TIOBSGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[potatoqualitee]

@niphlod what ifffffffff i get every command to pass all of our tests without any changes to the tests? and then it's loads faster? what could excite you into being on board?

While I'm convinced we need to be great software engineers to be great at AI-assisted coding, I don't think we need to know the language we're working in any longer.

[niphlod]

yeah, both yours and linus are bold statements.

Remember that the only problem we needed AI to solve for the library (ALC) ended up in not being resolved.

I do have a background in C# (last 4 years at least) but nothing on the "C# to PS glue" needed here (I'm always up for any challenge and glad for the opportunity to learn), but for both tests and coverage I think tests will need to be rewritten (or, at the very least, added) in C#.
Our test structure doesn't actually test much of the output, so we wouldn't be "automatically sure" everything is fine and dandy but being a major version, it may well output something different and be considered part of the "breaking changes ahead".
As for speeding up the module imports, huge ones took a completely different approach, which ON TOP of being already native in C#, have been splitted in sub-modules (looking at you, Az.*).

Again, I welcome the possible "breakage" where with 3.0 we may be able to resolve some concerns breaking backward compat with the existing functions, but if the goal is "speeding up the import" I think we should go down the path of a splitted module rather than "let's rewrite a zillion SLOCs in C#".

While we're discussing "high-level" things, are we going to write in .NET standard or in .NET ? I REEEALLY hope we don't wanna target .NET framework

[potatoqualitee]

@niphlod i recall you were concerned with that with the library but however it's setup, is not the problem you worry about! it'd be the same. just more things in the dll and less things in the ps1

i can add output tests before and after! I'll do that now 😊 i have an index somewhere.....

[dbaduck]

As long as you still have templates for creating a command in C# that fits into the dbatools infrastructure, I don't have any objections to moving this direction. I still have many commands to contribute, but they can definitely be done with C# instead. Looking forward to what 3.0 brings. What version of .NET is it going to be done in? .NET 8, 9, 10?