✅ Circular References
Being unable to do circular references seems like an unnecessary roadblock in some cases, at least for private projects.
See the following example. (Image)
Common represent a general helper project, while Pool project represent, for the purposes of this example, memory management helpers.
Pool benift from the Common helpers, but Common also uses some memory management helpers internally.
They are separate projects for code cleanliness reasons and also for the fact that they contain quite different functionality in general and could be used independently.
Obviously I am aware that leaving one of their resulting dlls out if this was allowed would cause some features in the remaining dll to break, that isn't the point.
Way 1 of fixing this "properly" is to add a Common Common project for the common project where the very very common code goes... Sure. At that point the natural progression of things is way 2.
Way 2 of fixing this "properly" would be to merge the two dlls or internally implement whatever are needed from each other which is generally what I have done.
But both is extremely ugly, I have them separated for a reason.
And some projects implement types that are exposed publicly so would require exposing duplicate of such types which is a mess in it self.
Another way is to reference the resulting dlls of a project instead of an actual project reference, which is pretty hacky and breaks ide features.
It's also pretty interesting that if editing the .csproj file manually visual studio basically fails to load the projects properly silently in terms of code analysis but then msbuild breaks with a nuget error code?
Rider is mostly the same.
Don't tell me the only reason this is hard blocked is because nuget doesn't allow it? I have exactly zero interest in uploading anything to nuget anyway, why does nugets dependency rules effect the entire language?
You can tell me it's bad coding in general to do circular references all you want, It certainly would be if the projects were intended to be published independently / publicly but they are not. It's just for basic organization and is not for public release.
Am I willing to make pointless abstractions to half of my code for no reason? No.
See the following example. (Image)
Common represent a general helper project, while Pool project represent, for the purposes of this example, memory management helpers.
Pool benift from the Common helpers, but Common also uses some memory management helpers internally.
They are separate projects for code cleanliness reasons and also for the fact that they contain quite different functionality in general and could be used independently.
Obviously I am aware that leaving one of their resulting dlls out if this was allowed would cause some features in the remaining dll to break, that isn't the point.
Way 1 of fixing this "properly" is to add a Common Common project for the common project where the very very common code goes... Sure. At that point the natural progression of things is way 2.
Way 2 of fixing this "properly" would be to merge the two dlls or internally implement whatever are needed from each other which is generally what I have done.
But both is extremely ugly, I have them separated for a reason.
And some projects implement types that are exposed publicly so would require exposing duplicate of such types which is a mess in it self.
Another way is to reference the resulting dlls of a project instead of an actual project reference, which is pretty hacky and breaks ide features.
It's also pretty interesting that if editing the .csproj file manually visual studio basically fails to load the projects properly silently in terms of code analysis but then msbuild breaks with a nuget error code?
Rider is mostly the same.
Don't tell me the only reason this is hard blocked is because nuget doesn't allow it? I have exactly zero interest in uploading anything to nuget anyway, why does nugets dependency rules effect the entire language?
You can tell me it's bad coding in general to do circular references all you want, It certainly would be if the projects were intended to be published independently / publicly but they are not. It's just for basic organization and is not for public release.
Am I willing to make pointless abstractions to half of my code for no reason? No.
