C# and VB.NET have no concept of 'linking' object files, so if a single
source file changes in your project then all the source files for the
assembly have to be rebuilt. I guess Microsoft took this approach to make
building an assembly a simpler procedure than the two step compile and link
that occurs with C++.
Managed C++ does have the concept of linking, so you compile C++ source
files to .obj files (with cl.exe) and then link them (with link.exe) to get
the assembly. If one source file changes and the .obj's for the other source
files exist then building the assembly only involves compiling the single
source file and linking together the .obj's.
Neither .NET, nor Win32, have a concept of 'merge [a compiled source file]
to the original DLL, to upgrade it'. The reason is that when the assembly is
built the compiler creates a hash value of the module and any modules it
uses and these are place in the assembly manifest. When the assembly is
loaded these hashes are created again and compared to the stored values to
see if the assembly has been tampered with.
The actual process is not quite that simple, because if you have a multi
module file modules are only loaded when the types in them are specifically
requested. In fact, you can use this as a way to get round your problem. If
you put the code for the types that are likely to change into a .NET module,
you can recompile this at a later stage and copy it into your app directory
to replace the old version. However, this will only work for assemblies that
have not been signed. Once you sign an assembly (provide a
[AssemblyKeyFile]) the hash for the module is checked when it is loaded, and
so if you replace it with another version the hash will be different and a
FileLoadException will be thrown.
Richard