"But replacing the new dll file will change other class and methods signature and logic, too."<p>Only if you don't make a real bugfix release, but throw the bugfix together with whatever you happen to have on your development machine.<p>Oh, and your "but in Python I can change a single file" leads to the exact problem, if you have continued development on that file.<p>That's all so incredibly stupid and irresponsible that I'd be inclined to say that OP's company doesn't have a problem with C#, but with its total lack of competence and responsibility in general.<p>What's frightening me even more is the number of "kudos" to that medium post.
Deployment should involve upgrading the .rpm or .deb on your production servers, or failing over to new instances which already have them. To try and decide <i>which</i> deployed files need to be replaced is very likely to leave you not actually knowing exactly which code you are running.<p>Deployment process is never a good reason for choosing a language. Deployment can (must!) be automated and reproducible. Language choice is about hiring, development speed, rate of mistakes, and hardware cost for sufficient capacity.
This article is full of FUD, and shows a very naive understanding of how to maintain and deploy software.<p>The "problems" he talks about are caused by so many other problems he has (no version control, not knowing what's in production, making breaking changes as part of a small bug fix, not testing changes, etc, etc).<p>And, his proposed fix - use a scripting language - would break too if he made a backwards-incompatible change.
I am simply frightened by this. Dependency freezing is a tenet of reproducible builds, reproducible builds a principle of engineering for any sort of reliability. This varies not a whit between interpreted or compiled languages. To extrapolate that to a massive generalisation like 'not good for web' is Not Even Wrong.