cjard
Well-known member
- Joined
- Apr 25, 2006
- Messages
- 7,081
- Programming Experience
- 10+
Once upon a time, I would set the AssemblyVersion attribute of all my apps to be 1.0.*
The IDE would fill in the version as it built the apps and everything was fine.. I didnt need to remember to keep changing versions etc.
I ran into a problem recently, where Program A uses DLL Y and DLL Z. DLLY also uses DLL Z.
Because A and Y build at different times, they would be linked to differently built versions of DLL Z, even though the two versions of DLL Z (for example 1.0.2669.20001 and 1.0.2669.20003) were code-wise identical they had different version numbers.
This meant that my apps were failing because Program A would load up, and use DLL Z. Then DLL Y would load and attempt to find a different version of DLL Z, and fail (because I wasnt including it, the idea of a shared library being that there arent hundreds of copies).
I only found this out while writing a custom AssemblyResolve handler for the odd cases I was getting where plugin DLLs used their own specific DLLs that werent being loaded (because the plugins directory isnt on the probe path and altering the probe path is a deprecated concept.)
If anyone else can think of some potential pitfalls of plugin architectures where the plugin dlls use a mix od their own and the main app's dlls, or each other, then let me know..
The IDE would fill in the version as it built the apps and everything was fine.. I didnt need to remember to keep changing versions etc.
I ran into a problem recently, where Program A uses DLL Y and DLL Z. DLLY also uses DLL Z.
Because A and Y build at different times, they would be linked to differently built versions of DLL Z, even though the two versions of DLL Z (for example 1.0.2669.20001 and 1.0.2669.20003) were code-wise identical they had different version numbers.
This meant that my apps were failing because Program A would load up, and use DLL Z. Then DLL Y would load and attempt to find a different version of DLL Z, and fail (because I wasnt including it, the idea of a shared library being that there arent hundreds of copies).
I only found this out while writing a custom AssemblyResolve handler for the odd cases I was getting where plugin DLLs used their own specific DLLs that werent being loaded (because the plugins directory isnt on the probe path and altering the probe path is a deprecated concept.)
If anyone else can think of some potential pitfalls of plugin architectures where the plugin dlls use a mix od their own and the main app's dlls, or each other, then let me know..
