EXE doesn't work on any other machines...

Okay, so I started writing something initially in VBA just for fun. Now I'm getting a little obsessed hehe. Program doesn't employ anything more than writing and reading from Excel workbooks.

Moved over to VB6 with some minor code adjustments. Program compiles and the EXE runs on the machine I coded it on WinXp Home. Although, on a WinXP Pro machine, it crashes at startup. Windows says the program encountered and error and closed.

I've looked around and the answer seems to be related to missing dependencies but a) i don't know what dependencies im using or missing and b) i don't get a message that suggests that, just death from the get go.

For fun, I tried to run it on a W7 machine. I get a run time error about Object variable or With block variable not set.

Any help is appreciated!

Run Package&Deployment Wizard, it can create an installer for you, and analyze and include dependencies along the way. Also, if you are working with Excel files you're probably using Office automation and referencing MS Office DLLs. If you are not using late binding than the machine you run on will have to have the exact version of MS Office installed in order to run.

In Windows 7 you have to use virtualization to be able to run programs like in XP: Windows 7's XP Mode: what it is, how it works, who it's for

You're apparently using dependencies that don't exist or aren't registered if VB6's or 3rd party controls are not installed. An installer would be a good idea to redistribute your application so that it's operational.

Red flags should be going off with the mention of Excel ... If you have referenced Excel ... then the versions of Excel MUST MATCH the same as on the dev machine... IE, if you reference Excel 2003.... then it's only going to work where Excel 2003 is installed.... earlier or later versions won't cut it. That would be the next thing I'd look at.

-tg

Quote:

---

Originally Posted by baja_yu

Run Package&Deployment Wizard, it can create an installer for you, and analyze and include dependencies along the way. Also, if you are working with Excel files you're probably using Office automation and referencing MS Office DLLs. If you are not using late binding than the machine you run on will have to have the exact version of MS Office installed in order to run.

---

I see what you mean here, since EXCEL in listed in the dependency list with a hard coded path. I was coding with Office2007 while the machine with the problem is using Office2003. I guess I have a problem there right?

I guess I'm going to have to find out what late binding is. Thanks very much for your help so far! Awesome leads :bigyello:

Quote:

---

Originally Posted by techgnome

Red flags should be going off with the mention of Excel ... If you have referenced Excel ... then the versions of Excel MUST MATCH the same as on the dev machine... IE, if you reference Excel 2003.... then it's only going to work where Excel 2003 is installed.... earlier or later versions won't cut it. That would be the next thing I'd look at.

-tg

---

Sorry, the red flags did go off, but I had no clue how to include and dependencies. Since I was using a machine with Office 2007 on it, do you guys think uninstalling the current version and replacing it with Office 2003, rebuilding, and repackaging work?

Late binding. As techgnome said, I already mentioned in post #2 that you need to use late binding when referencing MS Office libraries to avoid the user being required to have the exact version of Office. But they do have to have a version in order for your app to work. I think there is an article about late binding in the FAQ section.

EDIT: Got one http://www.vbforums.com/showthread.p...t=late+binding

Damn... ran into another problem. The user account on the target machine that I have doesn't have Admin rights and it seems difficult to obtain Admin rights. System32 is read only for my account...

Any ideas on how I can get around this? The users for some reason don't wanna use VBA. They want a standalone EXE.

I know Framework 1.1 at the least is on these machines.

Code:

---

*** ERROR: C:\WINDOWS\system32\stdole2.tlb
*** ERROR: An access violation occurred while copying the file.
*** ERROR: (User Responded with 'Ignore')
*** DURING THIS ACTION: SystemFile: "C:\WINDOWS\system32\stdole2.tlb"

*** ERROR: C:\WINDOWS\system32\asycfilt.dll
*** ERROR: An access violation occurred while copying the file.
*** ERROR: (User Responded with 'Ignore')
*** DURING THIS ACTION: SystemFile: "C:\WINDOWS\system32\asycfilt.dll"

*** ERROR: C:\WINDOWS\system32\olepro32.dll
*** ERROR: An access violation occurred while copying the file.
*** ERROR: (User Responded with 'Ignore')
*** DURING THIS ACTION: SystemFile: "C:\WINDOWS\system32\olepro32.dll"

*** ERROR: C:\WINDOWS\system32\oleaut32.dll
*** ERROR: An access violation occurred while copying the file.
*** ERROR: (User Responded with 'Ignore')
*** DURING THIS ACTION: SystemFile: "C:\WINDOWS\system32\oleaut32.dll"

*** ERROR: C:\WINDOWS\system32\msvbvm60.dll
*** ERROR: An access violation occurred while copying the file.
*** ERROR: (User Responded with 'Ignore')
*** DURING THIS ACTION: SystemFile: "C:\WINDOWS\system32\msvbvm60.dll"

---

Are these standard dependancies for VB6 applications? Can I place them anywhere else and get the program to run? Manual registration? Anything? I placed all the .dlls in the same dir as the .EXE and I still get a runtime error... Sorry for being such a nub.

msvbvm60.dll is the main runtime library that all applications made in VB6 need. There's a redistributable installer package from MS that can install it (and others) but I think it too will need admin rights to install.

EDIT: here it is http://www.microsoft.com/downloads/e...displaylang=en

Quote:

---

Originally Posted by baja_yu

msvbvm60.dll is the main runtime library that all applications made in VB6 need. There's a redistributable installer package from MS that can install it (and others) but I think it too will need admin rights to install.

EDIT: here it is http://www.microsoft.com/downloads/e...displaylang=en

---

Yup, it does. Back to the drawing board I guess! Thanks again for your help.

Make a web application instead, then all that a user needs is a browser... (and you need a server)

Quote:

---

Originally Posted by CVMichael

Make a web application instead, then all that a user needs is a browser... (and you need a server)

---

LOL, can't get admin rights but a server should be an easy grab. (sarcasm)

I thought of recoding in VBA, and simply hiding Excel and showing my form at startup. Can you guys think of any downsides? Thanks again.

If they want a stand alone EXE then how can you automate Excel? Do you know the target machines will have a version of Excel installed that's at least at the Office 2000 level?

The VB6 runtime components have been preinstalled with Windows for a long time (back to 98SE?). The main risk in not deploying them is that the older the OS the older the version of the runtime bits your program might encounter. Often it's a pretty safe bet though.

There is no need to screw around with XP Mode in Windows 7 if your VB6 program is properly written.


How viable all of this is depends on what your program needs to do and who needs to use it. If users are to install it for their own use there are ways to do per-user installs that don't require admin rights. This gets into advanced deployment topics though and even per-user installs can be blocked through Group Policy.