If you’re working in the .net ecosystem, you need to grok msbuild. Is not exactly painless or elegant, but is incredibly powerful. Creating a nuget package that applies settings and configuration files to consuming projects is the tip of a very deep iceberg.
I’m the author and owner of a similar code style/code quality package in a fairly large company and went through a very similar process, culminating with writing our own Roslyn-based analyzers to enforce various internal practices to supplant the customized configuration of the Microsoft provided analyzers. Also, we discovered that different projects need different level of analysis. We’re less strict with e.g test projects than core infrastructure. But all projects need to have the same formatting and style. That too can be easily done with one nuget using msbuild.
> If you’re working in the .net ecosystem, you need to grok msbuild.
Agreed, it makes a huge difference.
Sadly Visual Studio made that difficult from the start of .net, given its history with attempting to hide the .csproj files from developers and thus reduce their exposure to it. Its a real shame they decided to build visual studio like that and didn't change it for years.
Huh? You could always access the csproj by right clicking on the project.
Not quite. It required you to unload project, then you could right click and edit. And then reload project. And the load could take some time.
Now with sdk style project you just click on the project and the .*proj file comes up and is editable.
as the other person stated, earlier versions of Visual Studio wouldn't let you directly edit the .csproj in the IDE. You were forced to "unload" it first. If you ran an extension to override this behaviour you'd end up with glitches. Its one of the main reasons I moved to Rider given I much prefer to edit the .csproj manually in many cases as opposed to going through the GUI.
There's other little niggles, the Visual Studio gui for example offers a "pre-build" and "post-build" window that's kinda hacky. If you have more than one line in either of the windows the build no longer is able to push the _actual_ error back into the build. So its better to do this with separate target elements (that don't show up in this gui) or just run a pure msbuild file (.proj) to perform these tasks.
Older visual studio was just a bad habit generator/crutch which babied a lot of developers who could have learned better practices (i.e. more familiarity with msbuild) if they had been forced to.
>But all projects need to have the same formatting and style.That too can be easily done with one nuget using msbuild.
That's like using a car for "traveling" 3 meters. Why not just use dotnet format + .editorconfig , they were created just for this purpose.
It doesn’t scale as well across a large org.
We have hundreds of repos, thousands of projects. It is hard to ensure consistency at scale with a local .editorconfig in every repo.
Also, with a nuget I can do a lot more than what editorconfig allows. Our package includes custom analyzers, custom spell check dictionaries, and multiple analysis packages (i.e not just the Microsoft provided analyzers). We support different levels of analysis for different projects based on project type (with automatic type detection). Not to mention that coding practices evolve with time, tastes, and new language features. And those changes also need to be consistently applied.
With a package, all we need to do to apply all of the above consistently across the whole company is to bump a single version.
> Why not just use dotnet format + .editorconfig
And let the IDE take care of that. Pre-commit Hook and it's all done.
They're talking about how to sync the .editorconfig if projects are not in a mono-repo.
It's a combination of practices, some at develop-time and some at CI-time. The general goal is to have code as clean and standardized as possible as early as possible, especially on larger teams where human enforcement doesn't scale as much.
While msbuild is powerful, I strongly believe it should have been a standard C# language build system instead of a XML-based one.
Any non-trivial thing to do is a pain to figure out if the documentation is not extensive enough.
I really love C#, but msbuild is one of the weak links to me, almost everything else is a joy to use.
I completely agree that it shouldn’t be XML. Then again, I worked with Gradle in the past, which is based on Groovy syntax plus DSL. And that didn’t feel good either (though I must admit that I knew less about Gradle than I do about msbuild). Perhaps the problem of designing a good build system is harder than it seems.
You could check out FAKE. It’s pretty popular in the F# community. While not C#, the terser syntax may be beneficial for a build DSL and you still have access to .NET APIs.
https://fake.build/
But you augment it with tools written in c# which is best of both worlds. Builds are defined declaratively and custom actions are defined in code. Not the horrible hybrid of eg ant or cmake.
I remember using nant back in 2010 or so. Lol those were the days.
I've met teams that strongly prefer Cake [1] and it seems well maintained.
Personally, I think there's too much baby in the MSBuild bathwater unfortunately and too much of the ecosystem is MSBuild to abandon it entirely. That said, I think MSBuild has improved a lot over the last few years. The Sdk-Style .csproj especially has been a great improvement that sanded a lot of rough edges.
[1] https://cakebuild.net/
I agree with you on MsBuild being powerful.
I often really hate certain technologies like MsBuild and use them begrudgingly for years, fighting with the tooling, right up until I decide once and for all to give it enough of my attention to properly learn, and then realise how powerful and useful it actually is!
I went through the same thing with webpack too.
MsBuild is far from perfect though. I often think about trying to find some sort of simple universal build system that I can use across all my projects regardless of the tech stack.
I’ve never really dug much into `make`… Maybe something like that is what I’m yearning for.
I find this experience a lot with a lot of Microsoft technologies. People bemoan powershell, NT, DirectX, even C# itself, and other Windows APIs but when you get to really learn them you start to miss them on Linux. I sometimes see a meme from beginner programmers lamenting how the world would be better if Windows was POSIX compliant but once you've learned a bit about some of the Windows API calls, POSIX feels absolutely ancient. Some stuff is really dated like Win32 windowing stuff
> I often really hate certain technologies like MsBuild and use them begrudgingly for years, fighting with the tooling, right up until I decide once and for all to give it enough of my attention to properly learn, and then realise how powerful and useful it actually is!
I had a similar expreience with Cmake. Note, I still hate the DSL but what it can do and what you nowadays actually need to do (or how you organize it) if you are writing a new project can be relatively clean and easy to follow.
Not to say its easy to get to that point, but I don't think anyone really would say that.