17

I've been writing this program(FOO), and it includes a reference to a dll(BAR). All BAR contains is methods which perform various different calculations. FOO will be able to be installed and deployed on multiple computers. My question is, if I change a formula in one of the methods(i.e. change x + y to x - y), will I need to rebuild FOO against the new BAR? More importantly, is it safe to just deploy the new version of BAR?

EJC
  • 2,062
  • 5
  • 21
  • 33
PiousVenom
  • 6,888
  • 11
  • 47
  • 86

5 Answers5

13

@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:

  • Code Change, No Version Change and No Strong Names - OKs
  • Version Change and No Strong Names - May require recompile, recommended
  • Code Change and Strong Named - Requires recompile
  • Version Change and Strong Named - Requires recompile
RobV
  • 28,022
  • 11
  • 77
  • 119
  • 2
    The above is wrong. The purpose of strong named assemblies _is_ to facilitate fine-grained control over which version of a component gets loaded by allowing you to specifying when a newer version is a suitable replacement for an old one. This can be done on the application side, the component side, or on a system (by an admin). For example if the publisher of Bar makes a new v1.5, they can push this onto all applications (e.g. Foo) that uses v1.3-v1.4, because v1.5 is meant to work as a drop in for those. (Use with care!) [See here!](https://msdn.microsoft.com/en-us/library/ms973869.aspx) – AnorZaken Aug 26 '15 at 15:41
  • I've heard a lecture by Uncle Bob where he says that if your code doesn't use interfaces, but have a direct dependency from one class to another, when you change class B you'll have to recompile and redeploy class A (which would be avoided if you'd use an interface). I wonder if he meant to the specific case where the assembly's are strong names like you mention or there could be some other scenario? – BornToCode Dec 31 '15 at 19:19
  • If the assembly version is same and file version is changed for the reference assembly, do I need to rebuild the project – krish Dec 03 '19 at 10:08
7

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.

Mark Taylor
  • 1,843
  • 14
  • 17
2

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.

EJC
  • 2,062
  • 5
  • 21
  • 33
2

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.

Carsten Führmann
  • 3,119
  • 4
  • 26
  • 24
1

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.

trebuchet
  • 1,483
  • 9
  • 14