471,887 Members | 1,083 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,887 software developers and data experts.

Class does not support Automation or does not support expected interface

Hey guys!
I'm having some issues with one of my installer packages i compiled with Microsoft Visual Studio 2005. (VB installer is buggy as hell and wouldn't work on half of our machines no matter what we did with it) The installer wraps a VB 6.0 application. When i install the package on my machine everything works flawlessly. When i installed it on the user's machine, once again, everything ran great. When we uninstalled it and installed it again, we ended up getting the following error:
Run-Time Error 430 "Class does not support Automation or does not support expected interface"
Here is the kicker, when we try to open the actual project on user's machine in Visual Basic 6.0, he can run and execute the application without any problems whatsoever. No missing dependecies - nothing! However, when he tries to run it from a shortcut that the installer puts on his desktop he gets the message mentioned before.
The shortcut itself is passing command-line arguments. When we tried getting rid of these arguments and simply hardcoding their values into the code, the application ran fine from the shortcut on his desktop; even though the application wasn't using command-line arguments from the shortcut. I tried manually creating the shortcut but that didn't solve the problem either. I really don't know what can be wrong. I check MDAC versions on mine and his computer and both are identical.
Any suggestions?

P.S. This behavior is not happening on the dev. machine of course :(
Jun 26 '07 #1
2 17753
8,435 Expert 8TB
Just as another check on what's happening, have you tried filling in the arguments in the Project | Project Properties | Make | Command Line Arguments option in VB on the problem machine? Or is that what you meant when you said you hard-coded them in the program?
Jun 27 '07 #2
Thanks for the response!
The actual project has command-line arguments saved in the properties of the project. During start-up, the command-line is parsed and the arguments are saved into 2 variables. What we did is just skipped the parsing and manually set the variables to what the user is passing through the command-line like so:
Expand|Select|Wrap|Line Numbers
  1. strEnvironment = "test"
After more research, it doesn't even look like it has anything to do with the command-line. It looks like when the user compiles the application in VB environment it starts working. This is what i don't understand, even though the references would show components that got moved out onto their machine from the installer, something is still off as it wouldn't run outside of the VB environment. But when they try compiling with the same components it works. I'm think i'm about as lost as one could possibly be.
Jun 27 '07 #3

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

4 posts views Thread by jabailo | last post: by
3 posts views Thread by Robert | last post: by
15 posts views Thread by qwweeeit | last post: by
10 posts views Thread by Joe | last post: by
8 posts views Thread by Gregory | last post: by
52 posts views Thread by Ben Voigt [C++ MVP] | last post: by
reply views Thread by zermasroor | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.