3 ms·

I once got into a heated argument with a colleague. We were working on a legacy C# project where the initial architecture was such that a RAKEFILE (ruby-make)

by alexc05 11y ago

I once got into a heated argument with a colleague. We were working on a legacy C# project where the initial architecture was such that a RAKEFILE (ruby-make) was used to make a call to CSC.exe (the C# compiler). "It's easy, we use Ruby to compile our C# so we can use wildcards .cs" (to say nothing of the problems caused by the loading of '.DLL' from the bin folder on app start) Over time, when I was finally comfortable with the project, and after days of trial and error, I added CSPROJ files for each of the projects and was finally able to compile, run, and debug in visual studio. When I tried to commit the CSPROJ files into git, he deleted them on the next commit. When I asked why he removed the files is was a gongshow. "Why in hell should I allow you to put your shit in my repo?" He snapped. When I explained that using intellisense & debugging were both incredibly valuable. He countered with "why don't you just memorize the namespace (because that is what better programmers do)" And "why don't you just use print statements to inspect values? (because that is what better programmers do)" Skipping stack overflow is a similar sort of self hamstringing that I can't get behind. Getting the job done quickly is part of what we're paid for. (Caveat* optimally quickly of course, there are plenty of times when taking a bit longer pays off in the long run) Anyways, TL;DR skipping stack overflow is dumb.

ld00d 11y ago
To play devil's advocate: merging csproj files is a PITA. It's too bad VS can't just read the file system to determine what files/namespaces are in a project like virtually everyone else does.
- alexc05 11y ago
  You're right about the PITA, and they start out seeming like a wildly complicated and painfully documented dog's breakfast. I'm happy that .net CORE is moving to dynamic inclusion via "magic" However, once you are used to CSPROJ, they're actually ok to understand & merge. Additionally, if you're a c# shop, using msbuild & msdeploy gives you a lot more than hand rolling 100% of your compilation tools. If you stick to the framework, you save money. Occasional minor merge conflicts around file includes are minor relative the the ability to step-through-debug the code and get project wide code completion via intellisense.
douche 11y ago
This begs the question of how legacy something would have to be for them to initially setup the project in such a shitshow fashion in the first place. Too cheap to buy VS licenses, back when the community edition/express editions weren't a thing? Or maybe that I have so much Stockholm Syndrome from living inside Visual Studio world for too long.
- alexc05 11y ago
  Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.
- alexc05 11y ago
  Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.

by alexc05 11y ago

ld00d 11y ago

To play devil's advocate: merging csproj files is a PITA. It's too bad VS can't just read the file system to determine what files/namespaces are in a project like virtually everyone else does.

alexc05 11y ago
You're right about the PITA, and they start out seeming like a wildly complicated and painfully documented dog's breakfast. I'm happy that .net CORE is moving to dynamic inclusion via "magic" However, once you are used to CSPROJ, they're actually ok to understand & merge. Additionally, if you're a c# shop, using msbuild & msdeploy gives you a lot more than hand rolling 100% of your compilation tools. If you stick to the framework, you save money. Occasional minor merge conflicts around file includes are minor relative the the ability to step-through-debug the code and get project wide code completion via intellisense.

douche 11y ago

This begs the question of how legacy something would have to be for them to initially setup the project in such a shitshow fashion in the first place. Too cheap to buy VS licenses, back when the community edition/express editions weren't a thing? Or maybe that I have so much Stockholm Syndrome from living inside Visual Studio world for too long.

alexc05 11y ago
Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.
alexc05 11y ago
Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.