Are there valid reasons for modifying the code of an application between build and release?

Question

In a question on stackoverflow the answer I received was basically "It happens if you replace a .dll file in an already built application".

That seems very dirty to me. I understand the need for marketing changes like renaming the executable and things like that, but here we are talking about changing the functionality/the code. If I am going to release a new version of an application, it should be a new build - stop me right here if I am wrong with this.

My first reaction was coming up with the question "Is this really done in professional software?". However, if a company earns money, that does not mean they don't do dumb things. On the other hand, trying to think pragmatic, there might be a situation where this is appropriate.

So, the question, as in the title is: Are there valid reasons for modifying the code of an application between build and release?

• JacquesB: I think you misunderstand the answer. It is not saying you would replace a DLL in your own application after building. Rather, it is explaining what happens if there is breaking change in a DLL by a third party, i.e. a shared library your application depends on is upgraded independent of your application. This is a very real concern, and the source of the dreaded "DLL hell".
• R. Schmitz: @JacquesB I misunderstood that indeed. I started out researching about good code in general and didn't notice ending up at an argument which is only relevant to a certain area.
• JacquesB: Yes, "best practices" are always context-dependent, but often they turn into slogans where context is lost. Having public fields is fine in many cases, but not if you are distributing libraries.

Answer 1

Your C# code is typically linked against DLLs of the .NET framework of a specific version. Now, when Microsoft is going to publish a security update or other bugfix for this particular framework version, they will replace ".dll" files your code is linked with, and they do not expect you to recompile your application because of these updates. So they should care a lot for not introducing any breaking changes if it is not absolutely necessary.

This can happen whenever you are a framework or component vendor, where the distribution of updates can happen indepently of the distribution of applications using these components.

• R. Schmitz: That makes perfect sense, but the people writing these shared libraries must be a rather small part of software developers? I guess I got a bit confused as "breaking changes" are often used as an argument for everybody to use properties instead of public fields.
• Doc Brown: @R.Schmitz: "rather small" is relative. One hair on my head is "few", one hair in my soup is many. If you have a system where you know exactly that none of the points mentioned by Jon Skeet matters for you, go ahead and use fields, and switch to properties as soon as you need them.