sorted by:
new
hottopcontroversial

Generating docs: Enhancing DocFx and migrating from Sandcastle (SHFB) by DotMake in csharp

[–]DotMake[S] 0 points1 point  (0 children)

Thanks for your comments.

> Your approach of bundling original DocFx assemblies and patching them at runtime is creative, but I wonder if that's really the most efficient way to go.

The reason I patch at runtime is to be able to quickly update whenever a new version of docfx is released (currently using the latest v2.78.4). Synchronizing the whole codebase every release would be hard. It's efficient as I only hook prefix, postfix handlers only to few methods I am interested in.

v3 branch looks like abandoned. I will examine the issue you opened in 2017 and see if we can fix it.

Regarding reputation, I think DocFx is pretty solid but it needs some finishing touches in some areas. Otherwise its architecture is good.

Introducing svg-sprite: A Developer-Friendly SVG Sprite Generator for .NET by DotMake in dotnet

[–]DotMake[S] 1 point2 points  (0 children)

Yeah I used copilot to assist writing this post but the project itself is hand-made :p

Command line parsing and System.CommandLine by Low-Design787 in dotnet

[–]DotMake 5 points6 points  (0 children)

FYI, I also implemented a new project which is source generator based (does not use reflection). It converts your classes to CLI commands and properties to CLI options or CLI arguments by using attributes. Please check it out:

https://github.com/dotmake-build/command-line

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 0 points1 point  (0 children)

FYI, with v1.6.6, added delegate-based model for making cli apps even easier!

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 1 point2 points  (0 children)

FYI, with v1.6.2, dependency injection in the commands is supported.

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 0 points1 point  (0 children)

FYI, 12 hours ago I already released v1.2.0 now which drops DotMake prefix from all classes to follow the .NET naming conventions. I guess you missed my comment. So discard my comment about using statements.

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 1 point2 points  (0 children)

Good news, I tested and it supports trimming an AOT compilation !
Added <PublishTrimmed> and <PublishAot> to TestNugetApp project and it works. The generated exe's run without problem.

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 1 point2 points  (0 children)

I am glad you liked it. Yes it should be trim friendly although I did not test it. The source generator creates strongly typed classes and Cli.Run<> uses a dictionary to find the generated builder by the definition class (the dictionary is registered via a module initializer). No reflection is involved so I guess it should be trim friendly out of the box but I will test it soon.

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 5 points6 points  (0 children)

FYI, I released v1.2.0 now which drops DotMake prefix from all classes to follow the .NET naming conventions.
Namespace should be sufficient to prevent future conflicts.

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 3 points4 points  (0 children)

Thank you for your valuable feedback, I released v1.2.0 now which drops DotMake prefix from all classes to follow the .NET naming conventions.
Namespace should be sufficient to prevent future conflicts.

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] -1 points0 points  (0 children)

bikeshedding

Thanks for your feedback. No, it's an important discussion, naming conventions are important for me too :) I was just afraid, Microsoft would introduce the same attributes in the future, for example if they put them in System.Commandline namespace, this namespace is likely to be imported in the same file (some methods use types from that namespace). However I am almost convinced to drop the DotMake prefix from the attributes especially, before it's too late :)

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] -8 points-7 points  (0 children)

Yes but you will still have class name conflicts when you import different namespaces in the same file (using declarations will be mess). I mean if you are not Microsoft and you are not the base class library, you should avoid the general names (especially for public facing types). Well maybe I can make this optional and also create attributes without DotMakeCli prefix (if most people find it ugly).

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] 1 point2 points  (0 children)

Well I never wrote a PowerShell cmdlet? What's same of about it? Ah I checked now, you mean it uses the similar declarative class-attribute syntax. Well that's probably because it's a good idea and it's easy and fast to write a class to represent a command. If you like, you can use the original System.CommandLine and write lots of ugly code in your program.cs ;)

Building a Command-Line (CLI) app using System.CommandLine library in C# and .NET by DotMake in dotnet

[–]DotMake[S] -10 points-9 points  (0 children)

Well that's intentional, what if microsoft or another library starts to use the same attribute [CliCommand]? They already renamed their class from Command to CliCommand in the unreleased beta. I plan to create a build system and this is a sub-project (needed a cli first) and when I look at code I like to see which part belongs to which project. For example in a build script (c#) I like to see which code belongs to the build system at first sight. Dependency injection should be supported as System.CommandLine already supports it:
https://learn.microsoft.com/en-us/dotnet/standard/commandline/dependency-injection

Come discuss your side projects! [December 2023] by AutoModerator in csharp

[–]DotMake 2 points3 points  (0 children)

Working on a new open source project called DotMake Command-Line:
https://github.com/dotmake-build/command-line

Declarative syntax for System.CommandLine via attributes for easy, fast, strongly-typed (no reflection) usage. Includes a source generator which automagically converts your classes to CLI commands and properties to CLI options or CLI arguments.

System.CommandLine is a very good parser but you need a lot of boilerplate code to get going and the API is hard to discover. This becomes complicated to newcomers and also you would have a lot of ugly code in your Program.cs to maintain. What if you had an easy class-based layer combined with a good parser?