0

I am stuck with assembly compatibility problems with my project.

1) I have a .NET project, where i specify a assembly version . "Major part.Minor part.Build part.Revision part". 2) For the next build, assembly version is incremented. 3) There are many files (dll) which doesn't have any changes but their assembly version is updated. 4) The newer "dll" files are not compatible with older versions of same dll files.

I tried to get more information to solve this online.

1) There is a concept of publisher policy , where i can specify the older version number. 2) Manifest file to be added in the project for all the classes and provide the range of possible version which can be used if current version is not available.

I am not sure, if i am doing right. What is the difference between publisher policy approach and manifest file approach.

Is it possible to do the backward compatible for "dll's".

Soner Gönül
  • 91,172
  • 101
  • 184
  • 324
Pawan Kumar
  • 241
  • 5
  • 20
  • I would go for a solution where DLL's are loaded dynamically and where you're in complete control of what gets loaded when for you're application. – CodingBarfield Jan 02 '13 at 14:19
  • 2
    Incrementing the [AssemblyVersion] when you build is in general a poor practice. Building an assembly doesn't make it incompatible with other assemblies. Only changing the code does that. If you are stuck with this practice then there's only one decent solution: rebuild *everything*. Trying to mess around with publisher policies that patch the problem only creates the **exact** problem that [AssemblyVersion] was designed to solve: DLL Hell. – Hans Passant Jan 02 '13 at 14:46
  • To add to Hans's comment see this question: http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin – Alex Jan 02 '13 at 17:09

0 Answers0