c# - Why I need re- reference dll on major change in library -


i implemented indexer in library base.dll

namespace base { public class bocollection<tkey, tvalue> : dictionary<tkey, tvalue> {     public bocollection() : base() { }     public bocollection(int capacity) : base(capacity) { }     public bocollection(iequalitycomparer<tkey> comparer) : base(comparer) { }     public new tvalue this[tkey key]     {                 {             lock(this)             {                 return base[key];             }         }         set         {             lock(this)             {                 base[key] = value;             }         }     } } } 

now change forcing me re-compile or re-reference base.dll in other library. cleaned web application problem still there. getting error : method not found: 'system.collections.generic.dictionary`2 base.get_child()'.

but once re-reference base.dll in project giving error got fixed. have 15 different libraries dll being referenced. can suggest doing wrong. application based on .net 4.0

note : had property beginning

public  dictionary<string,base> child {         { return _child = _child ?? new dictionary<string, base>(stringcomparer.ordinalignorecase); }       set { _child = value; }     }     protected dictionary<string, base> _child; 

now changed this

 public bocollection<string, base> child     {         { return _child = _child ?? new bocollection<string, base>(stringcomparer.ordinalignorecase); }         set { _child = value; }     }     protected bocollection<string, base> _child; 

your code has many different issues, , there's no way fix without changes dependent assemblies.

first, you've changed contract (the return type of child property has changed) should change assembly version , recompile dependents against new assembly.

second, you've hidden indexer in derived class. not do, because means indexer used only when refer bocollection in code. means if don't change code, 100% of code not use version lock @ all. that's incredibly unsafe design!

third, use concurrentdictionary. gives thread-safe access dictionary values out of box :)

you're not going avoid recompilation of dependent assemblies, it's simple that. now, if you're interested in future proofing, 1 of reasons want use small interfaces useful. example, instead of using dictionary<string, base> return type, use idictionary<string, base>. gives freedom change internal implementation without changing contract, , breaking dll compatibility.

the safe way change assembly without having recompile dependents avoiding change breaking. example:

  • changing const or efault method parameters values - bad idea, because they're evaluated @ compile time.
  • removing public or protected members
  • changing return types or parameters of methods , properties

you can make changes, though:

  • add new method overloads , new members
  • add new types
  • change pretty code - important thing not change existing definitions (and then, public , protected, , in cases internal).

even then, i'd advise against it. it's better idea keep synchronized, , versioned. saves lot of trouble.


Comments

Popular posts from this blog

c++ - OpenCV Error: Assertion failed <scn == 3 ::scn == 4> in unknown function, -

php - render data via PDO::FETCH_FUNC vs loop -

The canvas has been tainted by cross-origin data in chrome only -