search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.24k stars 1.35k forks source link

[Refactoring] make file structure correspond to namespaces #10544

Open JanProvaznik opened 3 months ago

JanProvaznik commented 3 months ago

There are interfaces e.g. ITranslator belonging to namespace Microsoft.Build.BackEnd in src/Framework. This is confusing when there is a src/Build/BackEnd folder.

maridematte commented 3 months ago

So, while I agree it is confusing and that we should review what goes into what dll there are some cases that this switch is intentional.

For example, in a recent PR I had to transfer a enum BuildRequestDataFlags to the src/Framework folder, but the namespace needed to be kept as Microsoft.Build.Execution.

Each folder represents a .dll file that we pack and ship, almost everything under those folders are packed with their respective .dll and have different dependencies between them. In the case that I'm talking about, we needed the BuildRequestDataFlags to be accessible in the Framework package, but it was localted was in the execution package. Framework does not depend on Execution so there were cases where the type was completely inaccessible. By having BuildRequestDataFlags be packed within Framework we guaranteed that it would be accessible by any code from Framework but we had to keep the namespace and type forward so we could keep backwards compatibility and have no changes in our API.

TLDR: Sometimes it is intentional that classes are in different namespaces than the folder they are under, but we should review this stuff for sure.

JanProvaznik commented 3 months ago

related: https://github.com/dotnet/msbuild/issues/10189 The three things: "Namespaces x Filesystem x DLLs" should be clarified what goes where, why and what should be moved.