1

I'm working with Visual Studio 2010 and WinForms, .Net 4.0 (C#). I'm building an application with a lot of DLL (150). When I provide the application to my client, it's :

  1. The Executable (.exe)
  2. Dll files (.dll)

Each Dll is related to a module of the application, for example :

  • Ado.dll (provide access to database)
  • AccesManagement.dll (this module allows to manage users in the application)
  • Import.dll (this module allows the user to import data to the application)
  • etc.

When my client find a bug in the application, I correct it and I provide him impacted DLLs (in order to avoid him to test all the application). It can be for example the Import Dll.

The thing is, after some deliveries, we can have compatibility problems between Dll (a method that doesn't exist anymore in a new DLL for example). To avoid this problem, I would like to find a tool capable of checking compatibility between differents DLL.

I would like something like :

  1. I specify the directory of the program to analyse (executable + Dll)
  2. I launch the analyse
  3. The program tells me for example : Error between Import.dll and Ado.dll, there is a class xxx in Import.dll expecting a method named xxx in the class xxx of Ado.dll

I've found some tools able to compare two versions of a Dll and provide added and removed members (Libcheck, ApiChange), but it's too complicated for me to do that because there are to many changes.

Brian Tompsett - 汤莱恩
  • 5,195
  • 62
  • 50
  • 120
user467954
  • 41
  • 4
  • You are essentially looking for a dependency analysis tool. I would suggest you do more thorough testing of your application when you make changes to certain assemblies before you send these modified assemblies to your clients. – Bernard Feb 17 '12 at 13:41
  • 1
    Isn't what you describe called an Interface? You should take dependencies on interfaces not on concrete implementations. – rene Feb 17 '12 at 13:43
  • 3
    Take a look at [A definite guide to API-breaking changes in .NET](http://stackoverflow.com/questions/1456785/a-definite-guide-to-api-breaking-changes-in-net). I'm not aware of any tool which can test for these however awareness of what changes you can and can't make should help you avoid these sorts of problems in the future. – Justin Feb 17 '12 at 13:43
  • I'm using [CheckAsm](http://www.amberfish.net/) as a .NET Dependency Viewer. – Uwe Keim Sep 30 '15 at 08:54

2 Answers2

1

I think you may have a configuration management problem here -- at least as much as you've got a "compatibility" problem.

I'd recommend you find a way to track what versions of which assemblies each of your customers is using so that (1) you know what they're using when you decide what to ship, and (2) when they report bugs, you can replicate their setup (and thus, replicate their bug). If that sounds like a lot of work, it is. This is why a lot of software development shops take steps to ensure that there's a limit to the variation in setups among customers. It's nearly certain that you'll end up with some variation from customer-to-customer, but anything you can do to manage that problem will be beneficial.

Beyond the process implications, if you really need to create a "pluggable" environment, you probably need to create some interfaces for your objects to control the points where they connect, and you should probably look at Microsoft's Managed Extensibility Framework (MEF). MEF can help you manage the way objects "demand" behaviors from other objects.

Community
  • 1
  • 1
D. Lambert
  • 1,302
  • 6
  • 11
  • 1
    +1. I would also recommend automating the build, and note that revision/source control is not an option, it is mandatory. – TrueWill Feb 17 '12 at 14:10
0

I finally found a solution to my problem.

Since I'm :

  • Using SourceSafe and adding labels with the version of the application I'm building
  • Tagging each of my DLL with the version of the application

I built a program which is capable of :

  • Opening each Dll of a folder to read the version of the application in it
  • Getting from SourceSafe each project for the version specified in the DLL (With the functionnality "Get Label")

Then I just have to build the projet. If there is any compilation error, there is a compatibility problem.

This solution can avoid big compatibility problems, but you can still have compatibility problems which can't be seen with a compilation...

gturri
  • 10,843
  • 9
  • 35
  • 53
user467954
  • 41
  • 4