[RESOLVED] Publishing w/ COM objects

[ckabes]

I'm new to visual basic and have written a small program with a 3rd party reference (ChemDraw) which I have v16 installed on my computer. Everything works great. When I published my program and installed it on a different computer with ChemDraw v17, one form would not load due to unregistered libraries.

How can I package up my dll's when I publish my program? What I am I doing wrong?

Thanks for any ideas!

[jmcilhinney]

The Interop assembly generated when you build is presumably specific to version 16. You may need to install the trial of version 17 and build against that to get an appropriate Interop assembly. I'm no Interop expert but until recently, even Microsoft office required you to build against the specific version you intended to target. It took some work from Microsoft to allow multiple versions to be targeted without using late-binding and I doubt that the publishers of your software have done that work.

[gibra]

You actually use EARLY binding to a specific version, while should use LATE binding that will done using CreateObject() API function.

I have written an article about this, that solve many problems.
You can find the link for VB.NET (Excel, Word) and VB6.0

EARLY binding and LATE binding: using together!-VBForums
http://www.vbforums.com/showthread.p...=1#post4176842

In essence, the project demonstrates how EARLY binding can be used in development, while once the program is distributed, it will use LATE binding, thus solving the problem of the different versions of the library that is being used.
The 'canonical' examples are those for Excel and Word which are usually the most used programs for this kind of work.

It is sufficient to set a 'conditional compilation constant' and use it to understand if the program is executed in DEBUG or RELEASE mode, and based on this constant decide whether to use EARLY binding or LATE binding.

In the project I set the EarlyBinding=1 so will use the EARLY approach, linked to the local version of library.
When the project is executed on RELEASE, will use the LATE approach, As Object, that is version indpendent; therefore this work with ANY version.

#If EarlyBinding = 1 Then
Dim excelApp As Microsoft.Office.Interop.Excel.Application
Dim excelWorkbook As Microsoft.Office.Interop.Excel.Workbook
Dim excelWorksheet As Microsoft.Office.Interop.Excel.Worksheet
Dim excelRange As Microsoft.Office.Interop.Excel.Range
#Else
Dim excelApp As Object
Dim excelWorkbook As Object
Dim excelWorksheet As Object
Dim excelRange As Object
#End If
#If EarlyBinding = 1 Then
excelApp = New Microsoft.Office.Interop.Excel.Application
#Else
excelApp = CreateObject("Excel.Application")
#End If
The article is in Italian, but the code is very understandable, and the complete source project is available, which you can download.

[jmcilhinney]

@gibra, if I'm not mistaken, that means that you don't need to deploy an Interop DLL with your app at all, correct?

[gibra]

@gibra, if I'm not mistaken, that means that you don't need to deploy an Interop DLL with your app at all, correct?

Exatcly. Nothing to deploy.

The purpose of the code is to be able to use its own version of the library at the design stage, but then 'unlink' completely from this version when using the 'release' program on another computer that may have a different version of the library.

The other advantage in the design phase is that you can continue to use the intellisense to access the object model of the library, including the constants, which is impossible to do if you use CreateObject () only.

The only caution that must be applied is that you must explicitly declare all the intrinsic constants (of the library) that you use in the code , because obviously once distributed the program this constants will no longer be accessible.
For example: if you use Excel's intrinsic xlCenter constant you will have to declare it in your project:

Const xlCenter = -4108

EDIT

: added the English translation of the article.