CODEWITHSUNDEEP
vb.net
dabark
dabark

Reputation: 33

Reference VB.NET Interface in Different Assembly without Recompiling?

I have been asked to help with a product that comprises DLLs written in VB.NET. Customers' executable files reference these DLLs. To abstract the situation:

BACKGROUND:

Version 1 of product LocationProduct contains Location1.dll, which includes interface ICounty in namespace Country.Province. Customers compiled their executables with references to Location1.dll.

 Namespace Country.Province

     Public Interface ICounty 
         Property District As String
     End Interface

 End Namespace

Version 2 of LocationProduct contains Location2.dll in addition to Location1.dll. The interface ICounty was moved from Location1.dll to Location2.dll with the interface and its namespace unchanged. New customers used Version 2 of LocationProduct and compiled their executables with references to Location1.dll and Location2.dll.

PROBLEM:

A customer whose executable referenced Version 1 of LocationProduct tried to upgrade to Version 2. The customer received an exception, "Could not load type 'Country.Province.ICounty' from assembly 'Location1...".

If the interface ICounty is moved back to Location1.dll from Location2.dll, executables compiled with Version 2 get a similar exception, "Could not load type 'Country.Province.ICounty' from assembly 'Location2...".

Is there a way to change LocationProduct so that no customer will need to recompile?

Upvotes: 2

Views: 115

Answers (1)

Martin Verjans
Martin Verjans

Reputation: 4796

You must first understand what's going on here.

If your customer compile the executable using Version 1, it means they expect the interface to be in Location1.dll.

If you change this, you have a compatibility breach and therefore must recompile. Done, that's it, no way around my friend..

However you might have an option : use the ObsoleteAttribute (see MSDN link), this will create a warning into your customer's IDE and they will see they are not supposed to use this interface anymore. But they still need to recompile.

That being said, there is the ultimate question : why on earth would you want to do that ?

You have a library that is released to your customers, you don't move things around. When you design a public Framework, you should only add things, not change or remove them, because your customer will have to recompile every time you introduce a compatibility issue !

Here is a link to MSDN Framework Design Guidelines, which explains how you should design a library (or framework).

Upvotes: 1

Related Questions