Solved

New To VB - Question About Referencing

Posted on 2006-10-30
11
171 Views
Last Modified: 2010-04-30
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
Comment
Question by:shacho
  • 4
  • 3
  • 2
  • +2
11 Comments
 
LVL 3

Expert Comment

by:JRockSolid
Comment Utility
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
 

Author Comment

by:shacho
Comment Utility
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
 
LVL 76

Expert Comment

by:GrahamSkan
Comment Utility
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
 
LVL 13

Expert Comment

by:jmundsack
Comment Utility
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
 
LVL 13

Expert Comment

by:jmundsack
Comment Utility
(About #3, not sure if there is an #ifdef equivalent in VB.Net, but I would hope so.)
0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 
LVL 5

Expert Comment

by:Julian_K
Comment Utility
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
 

Author Comment

by:shacho
Comment Utility
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
 

Author Comment

by:shacho
Comment Utility
Any further input?
0
 
LVL 76

Accepted Solution

by:
GrahamSkan earned 500 total points
Comment Utility
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
 

Author Comment

by:shacho
Comment Utility
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
 
LVL 76

Expert Comment

by:GrahamSkan
Comment Utility
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

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Introduction In a recent article (http://www.experts-exchange.com/A_7811-A-Better-Concatenate-Function.html) for the Excel community, I showed an improved version of the Excel Concatenate() function.  While writing that article I realized that no o…
When trying to find the cause of a problem in VBA or VB6 it's often valuable to know what procedures were executed prior to the error. You can use the Call Stack for that but it is often inadequate because it may show procedures you aren't intereste…
Get people started with the process of using Access VBA to control Excel using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Excel. Using automation, an Access application can laun…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now