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?

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.