.NET Best Practice on Architectural Design for a Multi-Solution Project
Hello everyone!! ^_^
I wanna mention that I've been a self-taught .NET developer for almost 10 years now, and I feel like my experience is slowly but surely paying off. A while ago, I decided to enable all analyzers across my solutions and treat warnings as errors in order to improve my code quality and ensure it follows .NET standards and best practices.
However, after doing this, some parts of my codebase trigger certain warnings, including CA1515 warnings, which suggests that certain members should be marked
The issue is that my current architecture consists of multiple solutions that are separated for organizational purposes, and I need certain functions to remain accessible across these solutions. Because of that, simply making them
My questions are:
1. Is it practical to enable all analyzers and treat warnings as errors, or is that overkill for most real-world projects?
2. For the CA1515 scenario, what’s the recommended way to handle it when multiple solutions need to share access? Should I adjust the project structure, use
3. Are there situations where disabling or suppressing a warning is actually considered best practice?
- How can you tell whether a warning is truly unresolvable and suppression is the right approach?
- What criteria should I use to decide when to suppress instead of refactoring?
My main goal is to write cleaner .NET code without introducing unnecessary friction into the development process. :lizardo:
I appreciate everyone and truly do appreciate this community altogether for helping me throughout my code(s) in the past. Be harsh, don't hold back. Treat me like some intern that's about to get a reality check from a senior engineer who just :smh: at my code. (I haven't provided the code yet but if you'd like, let me know! ehe~)
I wanna mention that I've been a self-taught .NET developer for almost 10 years now, and I feel like my experience is slowly but surely paying off. A while ago, I decided to enable all analyzers across my solutions and treat warnings as errors in order to improve my code quality and ensure it follows .NET standards and best practices.
However, after doing this, some parts of my codebase trigger certain warnings, including CA1515 warnings, which suggests that certain members should be marked
internalpublicThe issue is that my current architecture consists of multiple solutions that are separated for organizational purposes, and I need certain functions to remain accessible across these solutions. Because of that, simply making them
internalMy questions are:
1. Is it practical to enable all analyzers and treat warnings as errors, or is that overkill for most real-world projects?
2. For the CA1515 scenario, what’s the recommended way to handle it when multiple solutions need to share access? Should I adjust the project structure, use
InternalsVisibleTo3. Are there situations where disabling or suppressing a warning is actually considered best practice?
- How can you tell whether a warning is truly unresolvable and suppression is the right approach?
- What criteria should I use to decide when to suppress instead of refactoring?
My main goal is to write cleaner .NET code without introducing unnecessary friction into the development process. :lizardo:
I appreciate everyone and truly do appreciate this community altogether for helping me throughout my code(s) in the past. Be harsh, don't hold back. Treat me like some intern that's about to get a reality check from a senior engineer who just :smh: at my code. (I haven't provided the code yet but if you'd like, let me know! ehe~)
