Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 186
  • Last Modified:

New To VB - Question About Referencing

I have been developing VBA Office tools for a few years and am starting to move to VB using VB 2005 Express.  I will have several questions over the next few weeks as I try to get educated on the language and the development environment.  To begin:

If I include a reference to Microsoft's COM interface to Excel, and subsequently program objects in that namespace, what happens when I deploy the application?  In other words, what will happen when the application runs on another machine?  Will the reference hold, or will the user experience a run-time error?  Is it standard practice to use early binding for Office automation, as I am attempting to do, or do programmers normally create objects as needed, given the uncertainty of the host environment?  These may seem like stupid questions, but bear with me, I'm just getting started.

Thanks in advance,

Mike
0
shacho
Asked:
shacho
  • 4
  • 3
  • 2
  • +2
1 Solution
 
JRockSolidCommented:
You must do dependency scanning on your app to make sure the propper files are transfered and registered on all the PC's that the app will run on.  I use VB6 and it has a dependency scanner but I choose to use installshield as well.  Is this anything near the answer that you needed?
0
 
shachoAuthor Commented:
Specifically I meant, what will happen if I make and explicit reference to the
Excel object model, rather than declaring a general object variable and using
CreateObject.  This may sound like a nonsensical question, but I don't really know
how it all fits together yet.

Private Sub OpenExcel( )
    Dim XLApp as Excel.Application
    XLApp = New Excel.Application
    XLApp.Visible = True
    XLApp = Nothing
End Sub

VS.

Private Sub OpenExcel( )
    Dim XLApp as Object
    XLApp = CreatObject("Excel.Application")
    XLApp.Visible = True
    XLApp = Nothing
End Sub
0
 
GrahamSkanRetiredCommented:
Hello Mike

In VB(6) and VBA, the two methods are called Early and Late binding repectively. You don't need references for late binding.

Early binding is much easier to work in, because properties and object variables are known at compile time. However there is a risk that changes in subsequent versions of libraries on which ealy binding depends will cause problems in your application. My advice is always to develop with Early binding, and to change the declarations to Objects for distribution

It seems to be the same in VB.Net. Personally, I like to think that this TA is for legacy VB, and that .NET/2005 questions are best asked in that area.
Here are some similar questions from there:
http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/VB_DOT_NET/Q_21468898.html
http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/VB_DOT_NET/Q_21333245.html
0
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

 
jmundsackCommented:
I completely agree with GrahamSkan: develop early-bound so that you can take advantage of IntelliSense design-time feedback, and before you deploy, remove the reference and change all objects from "Excel.Whatever" to "Object", and "= New" to "= CreateObject".

Another note: since all the enums are only available while you have the reference set in your project, once you remove the reference all those constants will be undefined, so make sure everywhere you use an enum member, you replace that with the constant value of the enum member--or better yet, create a module in which to store your own constant declarations of those values.

One final note: it might be helpful to use #ifdef to have both your early- and late-bound object and constant declarations in the source code, and switch back and forth using a conditional compilation argument.
0
 
jmundsackCommented:
(About #3, not sure if there is an #ifdef equivalent in VB.Net, but I would hope so.)
0
 
Julian_KCommented:
I definately suggest LATE binding. Using early binding is dangerous, becouse it is dependent on the version of the Excel. This means, that each and everyone of your clients should have the same versions of Excel as yours.

Using late binding, you can connect to most of the versions of excel transparently.
0
 
shachoAuthor Commented:
What I'm trying to get at is what it means to early-bind in VB.  If I set up a reference to an external object model in Excel with VBA, the reference is stored by my installation of Excel, and every subsequent piece of code it comes across with explicit references to that object model will be handle appropriately, regardless of what file contains the code.  But in VB, the host application is Windows Scripting Host, if I understand correctly.  If I set up a reference when I'm building an application in the VB IDE, I don't understand what it means because it appears to be bound to the executable itself - not the script host.  Am I way off here?  Do you see what I'm trying to grasp?

Cheers,

Mike
0
 
shachoAuthor Commented:
Any further input?
0
 
GrahamSkanRetiredCommented:
Sorry Mike,
I missed your penultimate comment.

In both early and late binding you are in fact connecting to the external object by means of a DLL belonging to the external application. If you use early binding, your application uses a library to understand the object model. With late binding your application has to interrogate the dll itself before it can create the objects.  

In VBA, the version of the object model goes with the application, so early binding to itself does not have version problems, though you could have a problem if you, say, connect to Word from Excel, and the Word version changes.

Legacy VB programs need a run-time DLL when executed ( a different one for each version). .Net programs need the Net framework.

Windows Scripting Host has little to do with compiled VB (1 to 6) applications. It needs to be there to run VBscript, which cannot be compiled.
0
 
shachoAuthor Commented:
Graham,  

I didn't mean to click accept just yet, although your answer is in principle enough information to justify it.  However, if you feel inclined to answer further, I would really appreciate your comments.  This is the source of my confusion.  If I set an explicit reference in the VBA host application to an external library, any subsequent execution of any code that contains early-bound explicit object references will not result in a syntax error at compile time.  Furthermore, If I run the same code on someone else's machine, whether or not I get an error is solely a function of whether or not that reference is also present on the other machine - regardless of whether or not the dll is actually installed.  I was able to 'set a reference' in my VB project from the development environment.  Once that reference was set, I could call object interfaces directly with Intellisense and compile without issue.  The question is - what happens If I run this application with explicit early-bound references on somebody else's machine?  If the dll I am referencing is installed, will the code function correctly?  My point is, I don't understand what setting references in the VB development environment actually means.  There is no 'host' like Excel or Word that I can open up on Machine 2 and manually set a reference to the dll - or is there?  Sorry I am having so much trouble getting my head around this.

Mike
0
 
GrahamSkanRetiredCommented:
Sorry for the delay.

As I understand it, after compilation, the reference libraries are no longer needed. The necessary information will be compiled into the new .exe or .dll

If you Run in design mode or try to compile, you will get an error if the machine does not have the library, but the compiled module will run OK.

The target application (Excel or Word, etc) must, of course be installed to run the code, though I'm not sure whether you would call it a Host.

This is Microsoft's article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;245115
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 4
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now