CODEWITHSUNDEEP
c#.netvisual-studiodllassemblies
user467954
user467954

Reputation: 51

Test compatibility between DLL in .NET

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 :

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.

Upvotes: 2

Views: 1892

Answers (2)

user467954
user467954

Reputation: 51

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...

Upvotes: 0

D. Lambert
D. Lambert

Reputation: 1304

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.

Upvotes: 1

Related Questions