I\'ve been writing this program(FOO
), and it includes a reference to a dll(BAR
). All BAR
contains is methods which perform various di
You just have to make sure the dll for the Bar
project is in the bin for the Foo
project. As long as the method signatures haven't changed you're good.
If you change a formula contained in a method, there is no need to rebuild the program. However if you modify the signature of a method by changing the calling arguments it will be necessary to rebuild the program.
@vcsjones's comment raises an important point here.
You can drop in a new DLL as a replacement if and only if the assembly version does not change and you are not using strong named assemblies.
If the version does change then you may receive runtime errors because your program tries to load a specific version and gets a different version than it expects. This may however work fine if no method signatures have changed but I wouldn't guarantee it and would always recommend a recompile.
This is even more of a problem when using strong named assemblies since the strong name encodes both the version and a digital signature of the assembly. So if any code has changed in the assembly then the digital signature will change even if the version has not, hence the strong name changes.
Again this will cause runtime errors because the strong name your program expects will not match the assembly strong name. So in this case a recompile is always required.
To summarize:
Nope - you can drop in a new DLL as needed. As long as the new DLL doesn't break any old functionality, there is no need to rebuild the referencing project.
Concerning the case where the referenced assembly is strongly named: Suppose A is any assembly, B is a strongly-named assembly, and A references B. Then (in contrast to claims made above?) it is possible to change the contents of B without recompiling A. I just tried this, with a trivial console application for A and a class library for B. Changes to the strongly-named B caused no runtime error in A. There is a special case, however: If B makes the transition from not-strongly-named to strongly-named, then A needs to be recompiled, otherwise the will be runtime errors.