5 ms·

Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions? And this must be related to needing

Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions? And this must be related to needing to have pdb file or being unable to debug. I wish those two things were not the case. And nuget. I find C# wonderful except those particular decisions give me pain on a daily basis.

JamesBarney 8y ago
> Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions? I agree that having lots of projects is a pain in the ass, and projects should be used for organizing code into deployment units not for logical separation. But this isn't a feature of the language just a decision(I believe a poor one) a previous developer on your project made.
- scarface74 8y ago
  Projects should be used for logical separation. I think of having domain specific projects as “microservices” that are isolated and where you only interface with the module via well defined interfaces. You get the logical separation of microservices without the needless complications. If you need to share a module between teams, it’s easy to package it up as a versioned Nuget package. If you need to separate it out into its own http based microservice. It’s easy to put a Controller on top of it and create an auto generated proxy class if you are describing the API with Swagger. On the client side, have the proxy class implement the interface. Of course all this is made easier if you are using a DI framework.
  - JamesBarney 8y ago
    Sure but most of the gains for microservices are splitting up large teams into independent teams responsible for sub modules which is much larger scale than most C# applications.
    - scarface74 8y ago
      The other benefit of separating functionality into microservices [1], is that it keeps developers from stepping on each other’s toes and merge conflicts. It also lets you scale independently [2]. [1] again I’m not referring to starting out with out of process microservices. They can very well be logically separated within a monolith and using class access modifiers as appropriate. [2] if you have clean namespace boundaries within your monolith, you program against interfaces instead of classes, and you use a DI framework. Pulling out an assembly/“service” from a monolith becomes a mechanical exercise.
alkonaut 8y ago
The splitting is entirely optional though? You split if you want to produce more binaries. If you keep everything in a single project, you get a single artifact. Having debug symbols in the binaries also seems like an odd choice to do (at least by default) as they can eassily be 10x the size of the binary.
ygra 8y ago
(a) How you structure larger applications into projects (assemblies) is largely your own problem. If you have a component that's intended to be used from different projects, then it sometimes makes sense that it gets its own project as well. However, you can just as well cross-include the source file if you want. There aren't that many things that explicitly require separate assemblies. (b) Debug symbols have to be there for you to be able to have source-level debugging, of course. You can always debug the assembly code, of course. For Microsoft's tooling, PDB files are the debug symbols that link the assembly code to the source code. Other tools sometimes embed debugging information in the binaries. And if this information isn't there, you can't have source debugging either. (c) No one's forcing you to use NuGet, although I wonder what you particular problems are with it.
- james_s_tayler 8y ago
  (a) it's usually a problem you inherit when you join a team/project and you didn't make the choices about it but for some reason there is 200 .sln files and impossible to open the entire project in a single .sln file. Well, I've had that once but my current situation is better than that but still somewhat problematic. (b) debug symbols could just be included in the compilation unit and optionally stripped out using a flag when you compile. There isn't a need for it to be in a separate file. A lot of fun times attaching DnSpy to something to half-ass debug it through a decompiler because there was no .pdb and you can't debug without it. Just painful. Wish they never split the debug symbols into a separate file. (c) I guess my colleagues are forcing me to use Nuget as I can't just show up tomorrow and switch everything to Paket. I don't have to use it on my personal projects, which is nice. Nuget's problems stem from what I'm talking about here. You need Newtonsoft.Json in various different csproj files, so you reference it in both of them. If you're not careful it easily winds up in a situation where you have multiple different versions of .NET in a single .sln file and multiple different versions of Newtonsoft.Json and the dreaded "multiple conflicting versions of a dependent assembly" warning. Etc. Comparing it to my experience in the Java world I remember it's still possible to split the project up and open separate parts if I want, but the whole thing has one unified version of Java and a unified set of dependencies. Just never wound up with the messy tangles I see in .NET projects. It's about my only beef with .NET stuff. Really irks me. Paket looks like a step forward though in terms of Package management, but it's not the defacto standard.
manigandham 8y ago
I've worked on massive applications that were split between 3 projects in a single solution as well as the inverse. It has nothing to do with the language. You can organize your code however you want, but overall it's a far better setup than many other languages that are folder or path based instead.
- james_s_tayler 8y ago
  I don't know about that. I too have worked on .NET projects that were structured in very different ways. IMO when you see a lot of variance that's a smell. There isn't an obvious or known good way to do something or there is no convention you get a lot of entropy creeping in. I find the folder/path based stuff at least has a convention or two that keep things in roughly the same shape from project to project. I prefer that this is the case than what I see with C# projects. Anyway, it's just my pet peeve.
  - manigandham 8y ago
    There's infinite variance in software applications so I expect proportional variance in how those projects are structured. The convention is to just have a single project until you need to separate. It's not that complicated. But the point is that it has nothing to do with the language.
hestefisk 8y ago
I think that’s mostly a function of Visual Studio legacy, not C#.
jaabe 8y ago
I think splitting into projects with their own separate dependencies is/was actually one of the few advantages to C#, because it lets you replace an entire project and it’s dependencies seamlessly. This has been extremely handy for us as we’ve been slowly upgrading to .net core. Because we can literally do it one project at a time without even risking breaking anything. Before going to .Net core it made switching from Web Forns to MVC really, really painless because all the business logic lived in its own projects, allowing us to run and maintain the Web Forms project, while building its replacement within the same solution. I guess it requires you to think about the architecture of your solution, but what stack doesn’t? I say “is/was” an advantage though, because it’s primary use cases are frankly mostly related to the past or really bad practices. It allows you to keep a single project running on some really old .Net version, to utilise something legacy. That’s bad, but sometimes it has real works value, even if it’s bad. NUGET has been fairly terrible though, and despite its many improvements, frankly continues to be so.
- stult 8y ago
  My experience has been the same. It's great when the code base is designed and maintained by people who view assemblies as isolated, fully separable entities. But many programmers walk into dotnet not understanding the approach and make a mess of it.
  - james_s_tayler 8y ago
    It's for exactly this reason that I think anything that makes the _technically_ optimal set of choices is actually a bad bet because the probability it is understood well enough to be used in the correct manner is low and it's possible to use it an an incorrect manner. So that's mostly what you see.
    - tracker1 8y ago
      Agreed... imho, make the code as discoverable and simple as possible. It's easier to copy/paste or just replace classes as needed rather than make them composable or setting up huge injection profiles.
userbinator 8y ago
I think that's more due to culture. Java culture, to be precise. The same goes for the dozens of mostly-empty deeply nested directories and other fluff. You can write C# with far less bloat, and compile it using only the command line, but Visual Studio generates the usual project layout by default.
sebazzz 8y ago
Symbols can be embedded in the assembly nowadays, though it is not the default option. https://github.com/dotnet/roslyn/issues/12390 https://github.com/dotnet/roslyn/issues/12390

JamesBarney 8y ago

> Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions? I agree that having lots of projects is a pain in the ass, and projects should be used for organizing code into deployment units not for logical separation. But this isn't a feature of the language just a decision(I believe a poor one) a previous developer on your project made.

scarface74 8y ago
Projects should be used for logical separation. I think of having domain specific projects as “microservices” that are isolated and where you only interface with the module via well defined interfaces. You get the logical separation of microservices without the needless complications. If you need to share a module between teams, it’s easy to package it up as a versioned Nuget package. If you need to separate it out into its own http based microservice. It’s easy to put a Controller on top of it and create an auto generated proxy class if you are describing the API with Swagger. On the client side, have the proxy class implement the interface. Of course all this is made easier if you are using a DI framework.
- JamesBarney 8y ago
  Sure but most of the gains for microservices are splitting up large teams into independent teams responsible for sub modules which is much larger scale than most C# applications.
  - scarface74 8y ago
    The other benefit of separating functionality into microservices [1], is that it keeps developers from stepping on each other’s toes and merge conflicts. It also lets you scale independently [2]. [1] again I’m not referring to starting out with out of process microservices. They can very well be logically separated within a monolith and using class access modifiers as appropriate. [2] if you have clean namespace boundaries within your monolith, you program against interfaces instead of classes, and you use a DI framework. Pulling out an assembly/“service” from a monolith becomes a mechanical exercise.

alkonaut 8y ago

The splitting is entirely optional though? You split if you want to produce more binaries. If you keep everything in a single project, you get a single artifact. Having debug symbols in the binaries also seems like an odd choice to do (at least by default) as they can eassily be 10x the size of the binary.

ygra 8y ago

(a) How you structure larger applications into projects (assemblies) is largely your own problem. If you have a component that's intended to be used from different projects, then it sometimes makes sense that it gets its own project as well. However, you can just as well cross-include the source file if you want. There aren't that many things that explicitly require separate assemblies. (b) Debug symbols have to be there for you to be able to have source-level debugging, of course. You can always debug the assembly code, of course. For Microsoft's tooling, PDB files are the debug symbols that link the assembly code to the source code. Other tools sometimes embed debugging information in the binaries. And if this information isn't there, you can't have source debugging either. (c) No one's forcing you to use NuGet, although I wonder what you particular problems are with it.

james_s_tayler 8y ago
(a) it's usually a problem you inherit when you join a team/project and you didn't make the choices about it but for some reason there is 200 .sln files and impossible to open the entire project in a single .sln file. Well, I've had that once but my current situation is better than that but still somewhat problematic. (b) debug symbols could just be included in the compilation unit and optionally stripped out using a flag when you compile. There isn't a need for it to be in a separate file. A lot of fun times attaching DnSpy to something to half-ass debug it through a decompiler because there was no .pdb and you can't debug without it. Just painful. Wish they never split the debug symbols into a separate file. (c) I guess my colleagues are forcing me to use Nuget as I can't just show up tomorrow and switch everything to Paket. I don't have to use it on my personal projects, which is nice. Nuget's problems stem from what I'm talking about here. You need Newtonsoft.Json in various different csproj files, so you reference it in both of them. If you're not careful it easily winds up in a situation where you have multiple different versions of .NET in a single .sln file and multiple different versions of Newtonsoft.Json and the dreaded "multiple conflicting versions of a dependent assembly" warning. Etc. Comparing it to my experience in the Java world I remember it's still possible to split the project up and open separate parts if I want, but the whole thing has one unified version of Java and a unified set of dependencies. Just never wound up with the messy tangles I see in .NET projects. It's about my only beef with .NET stuff. Really irks me. Paket looks like a step forward though in terms of Package management, but it's not the defacto standard.

manigandham 8y ago

I've worked on massive applications that were split between 3 projects in a single solution as well as the inverse. It has nothing to do with the language. You can organize your code however you want, but overall it's a far better setup than many other languages that are folder or path based instead.

james_s_tayler 8y ago
I don't know about that. I too have worked on .NET projects that were structured in very different ways. IMO when you see a lot of variance that's a smell. There isn't an obvious or known good way to do something or there is no convention you get a lot of entropy creeping in. I find the folder/path based stuff at least has a convention or two that keep things in roughly the same shape from project to project. I prefer that this is the case than what I see with C# projects. Anyway, it's just my pet peeve.
- manigandham 8y ago
  There's infinite variance in software applications so I expect proportional variance in how those projects are structured. The convention is to just have a single project until you need to separate. It's not that complicated. But the point is that it has nothing to do with the language.

hestefisk 8y ago

I think that’s mostly a function of Visual Studio legacy, not C#.

jaabe 8y ago

I think splitting into projects with their own separate dependencies is/was actually one of the few advantages to C#, because it lets you replace an entire project and it’s dependencies seamlessly. This has been extremely handy for us as we’ve been slowly upgrading to .net core. Because we can literally do it one project at a time without even risking breaking anything. Before going to .Net core it made switching from Web Forns to MVC really, really painless because all the business logic lived in its own projects, allowing us to run and maintain the Web Forms project, while building its replacement within the same solution. I guess it requires you to think about the architecture of your solution, but what stack doesn’t? I say “is/was” an advantage though, because it’s primary use cases are frankly mostly related to the past or really bad practices. It allows you to keep a single project running on some really old .Net version, to utilise something legacy. That’s bad, but sometimes it has real works value, even if it’s bad. NUGET has been fairly terrible though, and despite its many improvements, frankly continues to be so.

stult 8y ago
My experience has been the same. It's great when the code base is designed and maintained by people who view assemblies as isolated, fully separable entities. But many programmers walk into dotnet not understanding the approach and make a mess of it.
- james_s_tayler 8y ago
  It's for exactly this reason that I think anything that makes the _technically_ optimal set of choices is actually a bad bet because the probability it is understood well enough to be used in the correct manner is low and it's possible to use it an an incorrect manner. So that's mostly what you see.
  - tracker1 8y ago
    Agreed... imho, make the code as discoverable and simple as possible. It's easier to copy/paste or just replace classes as needed rather than make them composable or setting up huge injection profiles.

userbinator 8y ago

I think that's more due to culture. Java culture, to be precise. The same goes for the dozens of mostly-empty deeply nested directories and other fluff. You can write C# with far less bloat, and compile it using only the command line, but Visual Studio generates the usual project layout by default.

sebazzz 8y ago

Symbols can be embedded in the assembly nowadays, though it is not the default option. https://github.com/dotnet/roslyn/issues/12390 https://github.com/dotnet/roslyn/issues/12390