Missing reference to adodb.dll

run this as a batch file and make sure that the adodb.dll generated from this command is referenced from teh project. At that point you can deploy adodb.dll to the end users system.

@echo off
call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"
sn -k c:\adodb.snk
tlbimp.exe C:\Progra~1\Common~1\System\ADO\msado15.dll /keyfile:snk\c:\adodb.snk /out:c:\adodb.dll
 

                                              

1:
2:
3:
4:
5:

Be careful with talker2004's suggestion.  

1. You must reference the exact same version that you compiled against or you may have issues.

2. You should not sign the assembly yourself.  You should use a Microsoft published version, or you may conflict with other software.

This download http://www.microsoft.com/downloads/details.aspx?FamilyId=3C9A983A-AC14-4125-8BA0-D36D67E0F4AD&displaylang=en includes the Microsoft ADODB PIA.

This gives us full control of the generated assembly and it runs side by side with Microsoft's Published version. I don't believe the published version is strong named so good luck strong naming your own assembly.

Absolutely agree that the choice is with the author, but best practice is to use a published version:

http://msdn2.microsoft.com/en-us/library/y06sxw56.aspx
http://msdn2.microsoft.com/en-us/library/w0dt2w20.aspx

Note also the particular logic that .NET will use the vendor-provided PIA if it is installed.

The test machine, if it has Visual Studio installed, will almost certainly be using a Microsoft PIA.

Here's an extract:

By definition, primary interop assemblies are always signed by their publisher to ensure uniqueness. As the single, official definition of the types they describe, you can expect popular primary interop assemblies to be installed in the global assembly cache even if you deploy the same assembly to an application directory. The common language runtime always directs your application to the primary interop assembly in the global assembly cache when both the global assembly and your local assembly have the same vendor signature. In this case, your application is not insulated from version changes initiated by the vendor. When your application requires such insulation, generate your own interop assembly by using Type Library Importer (Tlbimp.exe) instead of using the primary interop assembly.

---
Note as well that you may not be able to legally redistribute a PIA with your product that you produce yourself for another company/organisation's product.


Finally, I'd recommend that you consider migrating to ADO.NET although this may require a medium-to-long-term approach.

We are using adodb.dll for porting legacy code. Other than that i would also recommend ado.net.

I agree that is an appropriate scenario for using the interop assemblies.

I don't mind about the points, though I don't think a refund is appropriate, but again I'd like to stress that this is an incorrect solution and would advise everyone to follow a standard, supported deployment method.