CleanArchitecture VS Roslyn

Looking at this, it has similar aspects as ASP.NET Core, and the same flaws as the Controller per class design used. Methods such as "create", "show" and "store" do not share a state, they shouldn't share a class either.

However, you can rectify this, by just not trying to share a class with any of those. In .NET Steve Smith, aka Ardalis shows how to do this with his Clean architecture idea [1], Idea is to make a class for each endpoint. This also makes it easier for "Update" classes to share functionality with other "Update" classes and so on.

[1]: https://github.com/ardalis/CleanArchitecture/tree/main/sampl...

🔴 [CleanArchitecture] (Learning Template + Docs): A starting point for Clean Architecture with ASP.NET Core. Clean Architecture is just the latest in a series of names for the same loosely-coupled, dependency-inverted architecture.

Here’s a few: - complex domain driven example using vertical slice - another DDD example - clean architecture template by Jason taylor - clean architecture template by ardalis

This repository is a good place to start with modern c# code, specifically ASP.NET

https://github.com/ardalis/CleanArchitecture

If you want to try clean architecture, you can check out Steve smith’s repo or Jason Taylor’s repo.

🔗 Clean Architecture repository | GitHub

C# has COMEFROM, too: https://github.com/dotnet/roslyn/blob/main/docs/features/int...

they make it cumbersome to use by hand, but not impossible

>> It is not a compiler error. It is never a compiler error (2017)

No, not always true. Even in modern compilers -- as matured and as modern as VS 2022-- you would still get bug.

I found one[0]. In my case it's easy to tell it's a compiler bug because the program just can't compile properly. But it's also not easy to reproduce, which just proves how well tested compilers usually are.

0: https://github.com/dotnet/roslyn/issues/74872

MSBuildLocator for .NET Framework can only search for MSBuild 15, 16, 17 (Visual Studio 2017, 2019, 2022). So, if a user has a fairly old project and is using Visual Studio 2015, Roslyn won't be able to find a suitable MSBuild. Even if the project is fully built on the system, Roslyn simply won't work. We've reported this issue on GitHub. To cut a long story short, the devs don't prioritize it, citing that VS 2015 and earlier versions are just outdated. However, it turns out that if the user has the .NET SDK, Roslyn starts using a backup plan. If you have a .NET Framework legacy project, Roslyn will try to use BuildHost for .NET Core. Most of the time, this works fine, but issues can occur if there's something that isn't supported by MSBuild for .NET Core. You'll see this in the description of the third issue.

C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) - this is what the base C# extension[1] uses. Both of these are licensed under MIT.

The only closed-source component is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].

[0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe...

[1]: https://github.com/dotnet/vscode-csharp

[2]: https://github.com/muhammadsammy/free-vscode-csharp

see also: https://github.com/dotnet/roslyn/pull/7850

The .NET runtime[1] and C# compiler[2] are both pretty easy to embed.

[1] https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...

[2] https://github.com/dotnet/roslyn/blob/main/docs/wiki/Scripti...

The C# compiler has an MIT license and is available on GitHub, which is about as FOSS as it gets.

https://github.com/dotnet/roslyn

My understanding is that the .NET team is working toward this with Interceptors: https://github.com/dotnet/roslyn/blob/main/docs/features/int...