Can't Deploy on Other Machines

[GrexD]

Is it possible to convert VB.Net apps to VB.6. I'm about ready to ditch VS2005 if I can't get my apps to run on other machines. First it needed Office 03 installed and now I'm getting another error having to do with OLE DB.

Obviously something is not registered, but WHAT! This was the second one I got. The first one was a Windows Imaging DLL that was not sent along with the installation package. I copied it over and registered it. Now this.

The initial log-in screen loads but fails when I attempt to log-in to the DB and then load the main form. I thought it was MDAC but it appears to be installed (MS Component Checker Utility - Google cc_pkg.exe - appears to indicate that several versions of MDAC are installed)

Anybody, please help. Does anyone have these kinds of problems. I'm using VS2005/SP1. I've written 2 applications so far and I can't get either to install and run on any other PC except my development machine. The Deployment wizard seems to work without error and the set-up seems to work without error, but the damn things won't run without generating errors.... Oops, I mean without throwing exceptions.

System.InvalidOperationException: An error occurred creating the 
form. See Exception.InnerException for details.  The error is: Class not 
registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)) 
---> System.Runtime.InteropServices.COMException (0x80040154): Class not 
registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

   at System.Windows.Forms.UnsafeNativeMethods.CoCreateInstance(Guid&
 clsid, Object punkOuter, Int32 context, Guid& iid)
   at System.Windows.Forms.AxHost.CreateWithoutLicense(Guid clsid)
   at System.Windows.Forms.AxHost.CreateWithLicense(String license, Guid clsid)
   at System.Windows.Forms.AxHost.CreateInstanceCore(Guid clsid)
   at System.Windows.Forms.AxHost.CreateInstance()
   at System.Windows.Forms.AxHost.GetOcxCreate()
   at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state)
   at System.Windows.Forms.AxHost.CreateHandle()
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.AxHost.EndInit()
   at AuthView.frmMain.InitializeComponent()
   at AuthView.frmMain..ctor()
   --- End of inner exception stack trace ---
   at AuthView.My.MyProject.MyForms.Create__Instance__[T](T Instance)
   at AuthView.frmLogIn.cmdOK_Click(Object eventSender, EventArgs eventArgs)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.PerformClick()
   at System.Windows.Forms.Form.ProcessDialogKey(Keys keyData)
   at System.Windows.Forms.TextBoxBase.ProcessDialogKey(Keys keyData)
   at System.Windows.Forms.Control.PreProcessMessage(Message& msg)
   at System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
   at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)

 

[GrexD]

I think I may have figured it out. The little component checker app has a whole slough of "Unknown" files listed on my development PC. Many of these are OLEDB. The other PC does not have these "Unknown" files listed by the component checker app.

So now the questions is two fold: First, since this utility is stumped by what is on my development machine, how do I tell what version of MDAC I'm running. Two, why the hell didn't the deployment wizard package up all of the files that are referenced in the program. It wasn't just the MDAC - if that is the real problem. Both of the apps I've tried to deploy have failed.

Am I doing something wrong when I click Publish? Am I missing a step. I'm developing in a professional atmosphere. I convinced my department head to upgrade to VS2005. So far I can't produce. I can write the programs, I just can't deploy them. It is very frustrating.

 

[cjard]

The stack trace seems to indicate that your software is using some kind of shareware activex control?

As a simple intro to a DB aware program, follow the DW2 link in my sig, section "Creating a Simple Data App".. get it working on your dev machine, then publish it to an MSI, install it on the target machine and we can go from there.. I've never encountered the problems you outline here, and I've published several .NET apps to a LAN, all of them have used an oracle database (they don't install the oracle client themselves; that must be done separately), some use TCP networking, file systems, crystal reports.. Never really had a problem, so I definitely advocate going back to bare bones simplicity and adding stuff until it breaks

 

[GrexD]

I'm using the Windows Imaging Acquisition library to display TIF files and a freeware Scrolling PictureBox control (came with VB.Net source code). I'm also using an Adobe made control for displaying PDFs. This came with the Acrobat SDK. The setup program did not install the Windows Imaging Acquisition library. At this point I don't know about the Acrobat control or the PictureBox control. I've been trying to get past the REGDB_E_CLASSNOTREG exception.

If it runs on my computer it should run on another computer 5-feet away with the same OS and same software. I do need to do some backwards engineering to figure out what is not being installed. I've written more than a dozen database apps with VB6 and installed them with either the Wise installer or the native VB program installer. I've never had this problem either.

I found it very frustrating that I can't see what is actually being included or not included in the deployment process like I can with Wise and the VB6 installer. It was rare that either of those would get it right the first time but at least I could make changes during the process of creating the package.

Both of my apps that have not installed are based on the same idea. They both use similar controls and connect to the same database. One detects incoming faxes. It allows the user to view them, log them, and time-stamp them. It then converts them to PDFs and routes them to different folders. The other detects new PDFs in the folders and based on the name of the folder interacts with one of 6 SQL Server databases to pull in other data. Its not rocket science. The failure seems to be in the weak deployment wizard that comes with VS2005.

 

[cjard]

"Deployment Wizard" ?

You mean you added a project of type "Setup & Deployment" subtype "Setup Project", added the relevant controls/dlls/merge modules in accordance with their EULAs and built the MSI?

 

[GrexD]

No, I mean I chose "Publish" from the build menu and a dialog titled "Publish Wizard" goes through 4 or 5 screens and creates setup program on our server. What you are describing does not sound like a "Wizard" at all.

I trying to read between the lines of your post, but it seems you do much more than just use the Publish Wizard.

 

[GrexD]

Ok, so I got the damn thing to install. It had nothing to do with a wrong MDAC version. I saw the "DB" in "REGDB_E_CLASSNOTREG" and assumed that is what was going on. There was no CLSID listed so I couldn't attribute it to a specific DLL or OCX. In the end, the problem was that none of the 3rd party DLLs were distributed with the setup package. Go figure.

Since this is in-house only, I just made a batch file (That is so 80s!) that copies the correct files to the users Win/Sys32 folder and then registers them.

Still, the $64,000 is, why aren't the files included, and/or how can I include them. The publishing wizard does not give em the option to modify the a file list or anything.

The one thing I really like about the publishing wizard and deploying off the network, is the application automatically looks for new versions each time the users starts the application and installs it if one is available.

 

[GrexD]

I'll add this as an FYI for anyone else that has this problem.

Not installing and registering the DLLs is by design with the "Click Once" installation. I'm not sure what the logic behind it is, but it is working as expected.

The Publish option from the Build menu runs according to the settings on the Publish tab. It has some very nice features, but for the first time out, expecting to things to work for me like they have in the past, it has been a little frustrating.

 

[cjard]

Mmm.. Try going to PROJECT menu>> PROPERTIES>> PUBLISH tab and have a look at:

Application Files
Prerequisites

In there should be listed your third party DLLs etc etc. If you've used them in your app, then you surely have referenced them, in which case (if they came from a merge module) VS will install them, or build them into your setup package (if they are referenced DLLs without an installer and are set to be copied to your build output directory)

As for registering DLLs and COM stuff, making an MSI has always done that for me. If youre using a free version of VS this option might not be available to you

 

[cjard]

expecting to things to work for me like they have in the past

An intrinsic preference for traditionalism is perhaps the biggest hinderance to progress

 

[GrexD]

Hey, thanks, that is so helpful and makes me feel so good about wasting so much of my time.

 

[cjard]

Time you enjoy wasting, is never time wasted. (You might have to wait a while before you see the enjoyment of it.)

 

[GrexD]

Time you enjoy wasting, is never time wasted. (You might have to wait a while before you see the enjoyment of it.)

These are clever sayings, but they are out of context. Wasting time sitting under a tree when I should be mowing the lawn is enjoyable. Wasting time clicking on dead links and reading dead-end forum threads is never enjoyable. Ultimately, I figured it out on my own, so there is some enjoyment in that, but the process was not enjoyable at all. I have way to much work on my desk to enjoy that sort of thing.

 

[cjard]

I have way to much work on my desk to enjoy that sort of thing.

Don't take it too seriously.. Smoke kills

 

[GrexD]

Don't take it too seriously.. Smoke kills

Hmmm...you lost me on this one.