DNN has many build warnings riddled throughout the entire solution which are usually indicators of issues with the code. Be it legacy code that has not been cleaned up or wasted memory footprints when allocating data that is never used. We should be treating all build warnings as errors to ensure a high level of code quality.
This is a massive undertaking with the size of DNN, I recommend we do this for the DotNetNuke.Abstractions project as it is the newest project and smallest project.
.csproj to treat build warnings as errosN/A
N/A
Code Quality Enhancement
N/A
We could also do this for DotNetNuke.DependencyInjection
Should I create an epic level issue and start creating tasks like this?
I expect it'll be a while before we're ready to turn this on for any other projects, so I'm not sure how helpful that top-level task would be (it'll probably just get closed after getting stale)
I think there is something going on with stylecop for DotNetNuke.DependencyInjection. After turning build warnings as errors on for that project I get an interesting error
1>------ Rebuild All started: Project: DotNetNuke.DependencyInjection, Configuration: Debug Any CPU ------
1>CSC : error SA0001: XML comment analysis is disabled due to project configuration
1>Done building project "DotNetNuke.DependencyInjection.csproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
See the SA0001 documentation. We need to turn on generation of the XML doc file for the project for StyleCop to check the validity of the comments.
That helped, now I Just need to remove the warnings 馃憤
I agree on turning that on on small new projects like this, but yeah we still have a lot of work to do before even thinking about turning that on elsewhere 馃槵
Most helpful comment
We could also do this for
DotNetNuke.DependencyInjection