I didn't know about these nuget packages. Thanks Milan for sharing this topic. Writing and mantein clean code is very important and these helps are very important.
Very good topic! I usually provide the analyzers with its own .editorconfig. It's a bit tricky but it enforces all rules and allows rule updates via a own nuget package. The nuget provides its own *.props file on build. In that case, developers are not able to suppress errors they don't like because the .editorconfig is overridden on each build 😁 And they can't uninstall the analyzer nuget packages. Also, it's useful to have different analyzer rules for test projects. In normal projects its for example not allows to use "magic strings" but in test projects you're allowed to. That nuget approach is very useful on distributed systems where you usually have a lot small solutions with n projects. If someone is interested in that solution, just ask 🙂
This is a good introduction, thank you. I would only try to mention one more thing in such introduction. With .editorconfig it is possible to change the severity level of a rule. But it is also possible to configure the rule's internals, for example for the rule that checks line lengths, it is possible to configure the maximum allowed length, or for the rule that checks nestings - maximum nesting level and so on. A different way is needed to provide such configuration, specific to each nuget package, but usually, it is something similar to an XML file with a predefined name.
@@MilanJovanovicTech There is some documentation in StyleCop and Sonar analyzers projects, but it looks like I can't provide those links, comments just get deleted.
Hey. Very interesting topic with short helpful introduction into the topic ! Just a question. Are you using both static analyzers (StyleCop SonarAnalyzer) at the same time or they have same features and using just one of them should be enough ?
Very helpful video, thank you. I am having a problem in my project where I need to disable all analyzers in a specific project directory. I tried to suppress it in the .editorconfig file, but the rest of the rules are more specific, therefore it overwrites the suppression. How could I suppress those directories?
interesting, cool, but it's definitely not for a student, thanks, I went to finish my second project.) I fell into the trap when I watched your lessons, and I'm still figuring out the Rusult class. I liked him very much.
@Milan I also see CS1591 lines in my .editorconfig. These are Compiler warning that are configurable. Should these also be moved down. VS just plops those lines somewhere it looks. But some seem to be inside a [*.cs] selector, so they would only apply to *.cs files I think. In my case I think they are now in a [*.{cs,vb}] section so still apply to *.cs but do you know whether this is true, Ie. There position is important if you also have other extension sections in your .editorconfig ?
Thanks for the video. When you say a solution can contain up to 100 projects or even more. Can you please let us know how we can configure multiple projects on different repositories under the same solution. So the solution should be within the repo having few projects in the same repo but other projects can go in different repo.
This was very cool. Thank you. Question though if for instance you did not want other developers to be able to change the severity of the rule from the nuget package? Do you have a way?
All good until you mentioned the StyleCop - a real nightmare, same as his predecessor (fxCop). I prefer using SonarQube rules (via SonarLint) for sanity, .editorconfig for enforcing behavior, and the "old" roslyn analyzer. Also I prefer shipping the .editorconfig file via a NuGet package, with a custom task in the CI pipeline that's validating the the package presence. What's nice about this approach is the fact that you do not depend of a specific path, but you can opt to deliver it via the organization projects, and you can achieve the same with other package managers as well - maven, npm, others.
Dear can you make like a very small project from a to z using these tools to write a clean code . So for the newbies like me can understand clearly . Thank you
Been looking into throwing static code analysis into Git when making pull requests, to assert clean code only gets merged. Been looking at it lightly, but come across random issues. Have you looked into this?
How will this work remotely? Doesn't the csproj reference a bunch of Unity dlls that exist in the Editor Hub. From what I see Unity doesn't output relative path references for anything like that?@@MilanJovanovicTech
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Short but sweet information about Clean Code. Thank you.
Glad it was helpful!
I didn't know about these nuget packages. Thanks Milan for sharing this topic. Writing and mantein clean code is very important and these helps are very important.
This is super helpful in large teams to maintain code quality
I am currently writing an article on Clean Code and I guess this video will help me! I’ll mention you ;)
Just spread the good word about static code analysis, and I'll be more than happy 😁
Thank you!!... Your videos has been a great source of knowledge, quality, discovering and goodness.
Wow, thank you!
Very good topic! I usually provide the analyzers with its own .editorconfig. It's a bit tricky but it enforces all rules and allows rule updates via a own nuget package.
The nuget provides its own *.props file on build. In that case, developers are not able to suppress errors they don't like because the .editorconfig is overridden on each build 😁 And they can't uninstall the analyzer nuget packages.
Also, it's useful to have different analyzer rules for test projects.
In normal projects its for example not allows to use "magic strings" but in test projects you're allowed to.
That nuget approach is very useful on distributed systems where you usually have a lot small solutions with n projects.
If someone is interested in that solution, just ask 🙂
I think you can just place an .editorconfig under the /tests folder, and that should solve it. You have a great point there Marcus!
@@MilanJovanovicTech Thanks and yes, that would work 🙂
Could you somehow share your solution
@@kenank7053 Sure, I'll prepare something on Tuesday.
@@MarcusKaseder can you please share it too? thank you
This is a good introduction, thank you. I would only try to mention one more thing in such introduction. With .editorconfig it is possible to change the severity level of a rule. But it is also possible to configure the rule's internals, for example for the rule that checks line lengths, it is possible to configure the maximum allowed length, or for the rule that checks nestings - maximum nesting level and so on. A different way is needed to provide such configuration, specific to each nuget package, but usually, it is something similar to an XML file with a predefined name.
Have any documentation source for that?
@@MilanJovanovicTech There is some documentation in StyleCop and Sonar analyzers projects, but it looks like I can't provide those links, comments just get deleted.
Thanks for the video ,good work milan
Glad you enjoyed it
Great video with full of the info
Glad you liked it
Thanks for the video ,really helpful.
Glad it was helpful!
New video, new things to learn :)
I think this one can be particularly useful!
amazing video!
Thanks!
That was interesting!
Thank you, hopefully you can add it to your project 😁
Hey. Very interesting topic with short helpful introduction into the topic ! Just a question. Are you using both static analyzers (StyleCop SonarAnalyzer) at the same time or they have same features and using just one of them should be enough ?
I'm using both. They have some overlap surely, but they complement each other also
Very helpful video, thank you. I am having a problem in my project where I need to disable all analyzers in a specific project directory. I tried to suppress it in the .editorconfig file, but the rest of the rules are more specific, therefore it overwrites the suppression. How could I suppress those directories?
You can have .editorconfig in each directory
interesting, cool, but it's definitely not for a student, thanks, I went to finish my second project.) I fell into the trap when I watched your lessons, and I'm still figuring out the Rusult class. I liked him very much.
There's a nice library here: github.com/altmann/FluentResults
@@MilanJovanovicTech OMG thanks 🙏
Great!
Thanks buddy! 😁
@Milan I also see CS1591 lines in my .editorconfig. These are Compiler warning that are configurable. Should these also be moved down.
VS just plops those lines somewhere it looks. But some seem to be inside a [*.cs] selector, so they would only apply to *.cs files I think. In my case I think they are now in a [*.{cs,vb}] section so still apply to *.cs but do you know whether this is true, Ie. There position is important if you also have other extension sections in your .editorconfig ?
I don't think those are related to file types
Thanks for the video. When you say a solution can contain up to 100 projects or even more. Can you please let us know how we can configure multiple projects on different repositories under the same solution. So the solution should be within the repo having few projects in the same repo but other projects can go in different repo.
Well that doesn't make much sense from a code sharing perspective... How do you see that working?
Thanks for the Video, I have one question, How to get Directory.Build.Props to other projects that are in separate GIT repositories ?
You'll have to copy that file into the other repository 🤷♂️
Hello, and thank you for this video, i have a question: why in Repository with Update and Add functions you don't use async
I don't need to make them async. So why pay the price of having an async method?
what is your recommendation about configuring PrivateAssets and IncludeAssets?
I don't even think about that, to be honest
This was very cool. Thank you. Question though if for instance you did not want other developers to be able to change the severity of the rule from the nuget package?
Do you have a way?
Code reviews? 😅
Nothing else comes to mind
In your CI build pipeline you can pull in an editor configuration file from a secure place that will break the build.
All good until you mentioned the StyleCop - a real nightmare, same as his predecessor (fxCop). I prefer using SonarQube rules (via SonarLint) for sanity, .editorconfig for enforcing behavior, and the "old" roslyn analyzer.
Also I prefer shipping the .editorconfig file via a NuGet package, with a custom task in the CI pipeline that's validating the the package presence. What's nice about this approach is the fact that you do not depend of a specific path, but you can opt to deliver it via the organization projects, and you can achieve the same with other package managers as well - maven, npm, others.
It's all configurable via .editorconfig, so I don't see much problems with it.
Dear can you make like a very small project from a to z using these tools to write a clean code . So for the newbies like me can understand clearly . Thank you
Yes, sure
@@MilanJovanovicTech thank you so much . Deep appreciation for you
Been looking into throwing static code analysis into Git when making pull requests, to assert clean code only gets merged. Been looking at it lightly, but come across random issues. Have you looked into this?
Add it as part of your CI: th-cam.com/video/58mt3A2MNdg/w-d-xo.html
Version where you can copy the YAML: www.milanjovanovic.tech/blog/how-to-build-ci-cd-pipeline-with-github-actions-and-dotnet
How will this work remotely? Doesn't the csproj reference a bunch of Unity dlls that exist in the Editor Hub. From what I see Unity doesn't output relative path references for anything like that?@@MilanJovanovicTech
wtf ads
Out of my control 🤷♂️