|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Componenet not installed correctly by PDWcomputer overseas. I created the setup program using deployment and packaging wizard and sent it to them. After hearing that they were having trouble running the test program, I decided to create a new PC system here and run the installation program here. I built a brand new installation of Windows XP SP2 using NTFS. I am the only user and have administrator rights. When I launch the program on the new PC, I get the dreaded message Run-time error 339: Component 'MSCOMCTL.OCX' or one of its dependencies not correctly registerd: a file is missing or invalid. Upon closer examination of the new system, I find that the ocx file was not even copied to $(WinSysPath). This is also true of other ocx files that were part of the package. Of course my program won't run if this is the case. Is it possible that the XP system doesn't understand $(WinSysPath)? Post the contents of SETUP.LST file, or at least the lines that deal with
OCX files. On Sep 1, 9:58 am, "Nobody" <nob***@nobody.com> wrote: That's wierd. There are no references to the OCX files in setup.lst at> Post the contents of SETUP.LST file, or at least the lines that deal with > OCX files. all. That explains why they were not installed, but not why they aren't in the file in the first place. Hmmm. Scott,
Did you use this one already? Regsvr32 http://support.microsoft.com/kb/249873 Success Cor "Scott M." wrote in message news:545cf143-f374-4644-902c-38f42fe4b135@q22g2000yqm.googlegroups.com... I have an old test program written in VB6 that I need to run on acomputer overseas. I created the setup program using deployment and packaging wizard and sent it to them. After hearing that they were having trouble running the test program, I decided to create a new PC system here and run the installation program here. I built a brand new installation of Windows XP SP2 using NTFS. I am the only user and have administrator rights. When I launch the program on the new PC, I get the dreaded message Run-time error 339: Component 'MSCOMCTL.OCX' or one of its dependencies not correctly registerd: a file is missing or invalid. Upon closer examination of the new system, I find that the ocx file was not even copied to $(WinSysPath). This is also true of other ocx files that were part of the package. Of course my program won't run if this is the case. Is it possible that the XP system doesn't understand $(WinSysPath)? I don't want to have to use regsvr32. I shouldn't have to since the
ocx files are part of the package. This program needs to be installed on PC's far away and to tell those guys to run regsvr32 is unacceptable. The funny thing is that I see the ocx files in the PDW and they are in my current Windows\System32 directory. "Scott M." <quan***@gmail.com> wrote in message You don't need to use regsvr32. Try creating the setup from scratch again. I news:e7908062-9f18-4a61-8264-208b96ffade5@x42g2000yqx.googlegroups.com... >I don't want to have to use regsvr32. I shouldn't have to since the > ocx files are part of the package. This program needs to be installed > on PC's far away and to tell those guys to run regsvr32 is > unacceptable. The funny thing is that I see the ocx files in the PDW > and they are in my current Windows\System32 directory. think there is a PDM file that keeps the old setup settings, so you need to delete it(after backup).
Show quote
Hide quote
On Sep 1, 10:41 am, "Nobody" <nob***@nobody.com> wrote: I will try creating the setup completely from scratch. That might work.> "Scott M." <quan***@gmail.com> wrote in message > > news:e7908062-9f18-4a61-8264-208b96ffade5@x42g2000yqx.googlegroups.com... > > >I don't want to have to use regsvr32. I shouldn't have to since the > > ocx files are part of the package. This program needs to be installed > > on PC's far away and to tell those guys to run regsvr32 is > > unacceptable. The funny thing is that I see the ocx files in the PDW > > and they are in my current Windows\System32 directory. > > You don't need to use regsvr32. Try creating the setup from scratch again.. I > think there is a PDM file that keeps the old setup settings, so you need to > delete it(after backup). "Scott M." <quan***@gmail.com> wrote in message There is no need to get another PC, there is a better option. Use the free news:545cf143-f374-4644-902c-38f42fe4b135@q22g2000yqm.googlegroups.com... >I decided to create a new PC > system here and run the installation program here. I built a brand new > installation of Windows XP SP2 using NTFS. I am the only user and have > administrator rights. MS Virtual PC. The advantage over a separate PC is that you can do a clean install of any OS, then save it as a template so you don't have to reinstall the OS again to perform a "clean install". You can "restore" to a clean OS install in under a minute(depending on file size) and retest your installer and software. You can also enable "Undo Disks" so you start from the clean install, test your software, then close the VM and choose to discard the changes. This leaves the OS at the clean install state. You can't do that with dedicated box easily. You can even create multiple duplicates with various service packs installed or different configurations. Each "PC" or VM is nothing more than 2 or 3 files that you can backup or restore as you wish, or use as template. http://www.microsoft.com/windows/virtualpc/default.mspx http://en.wikipedia.org/wiki/Windows_Virtual_PC
Show quote
Hide quote
On Sep 1, 10:46 am, "Nobody" <nob***@nobody.com> wrote: That sounds like a really neat tool. I'll check it out later.> "Scott M." <quan***@gmail.com> wrote in message > > news:545cf143-f374-4644-902c-38f42fe4b135@q22g2000yqm.googlegroups.com... > > >I decided to create a new PC > > system here and run the installation program here. I built a brand new > > installation of Windows XP SP2 using NTFS. I am the only user and have > > administrator rights. > > There is no need to get another PC, there is a better option. Use the free > MS Virtual PC. The advantage over a separate PC is that you can do a clean > install of any OS, then save it as a template so you don't have to reinstall > the OS again to perform a "clean install". You can "restore" to a clean OS > install in under a minute(depending on file size) and retest your installer > and software. You can also enable "Undo Disks" so you start from the clean > install, test your software, then close the VM and choose to discard the > changes. This leaves the OS at the clean install state. You can't do that > with dedicated box easily. You can even create multiple duplicates with > various service packs installed or different configurations. Each "PC" or VM > is nothing more than 2 or 3 files that you can backup or restore as you > wish, or use as template. > > http://www.microsoft.com/windows/virtualpc/default.mspx > > http://en.wikipedia.org/wiki/Windows_Virtual_PC I solved the problem. It turns out that the Microsoft program that
creates the setup files (Package and Deployment Wizard) omitted a key dll file, MSDERUN.DLL, needed by the program that allows it to use Access databases. It took me two days to figure this out. This particular dll was already installed on all of our other test systems, so the problem never showed up until I created a fresh Windows XP installation. A search of my own test development system for this dll came up empty, throwing me off until I re-ran the search and included system and hidden files. I hope that this helps another developer some day. Scott "Scott M." <quan***@gmail.com> wrote in message That file is part of the Data Environment Designer, if it was used. It's news:9f7f4b34-e67a-429c-a5cd-5274ba84fbea@l32g2000prn.googlegroups.com... > MSDERUN.DLL, needed by the program that allows it to use > Access databases. avoidable, and one could use ADO directly instead. Windows 2000 came with ADO 2.5, and Jet 4.0 engine, so basically there is no need to include ADO, or MDAC_TYP.EXE in 2000+ if you avoid features that were introduced in later versions. On Fri, 3 Sep 2010 10:15:32 -0400, "Nobody" <nob***@nobody.com> wrote: I agree that the Data Environment has some warts, was poorly>"Scott M." <quan***@gmail.com> wrote in message >news:9f7f4b34-e67a-429c-a5cd-5274ba84fbea@l32g2000prn.googlegroups.com... >> MSDERUN.DLL, needed by the program that allows it to use >> Access databases. > >That file is part of the Data Environment Designer, if it was used. It's >avoidable, and one could use ADO directly instead. Windows 2000 came with >ADO 2.5, and Jet 4.0 engine, so basically there is no need to include ADO, >or MDAC_TYP.EXE in 2000+ if you avoid features that were introduced in later >versions. > implemented, and is essentially a work left undone (it should have been named Data Environment version 0.9). But to suggest to the OP that he can avoid including a specific component by completely re-engineering his product to either exclude data binding entirely or replace the DE with data aware components of his own design is a bit over the top, don't you think? <bg> [But then we also don't know much about the OP's product. There are other constructs and controls that use the services of the MSDE Runtime (or one particular situation, invokes a need for its presence even though it is never used directly!) besides just the Data Environment.] -ralph On Fri, 3 Sep 2010 10:15:32 -0400, "Nobody" <nob***@nobody.com> wrote: For lurkers Windows 2000 through Windows 7 and Windows Server 2008 R2>Windows 2000 came with ADO 2.5, and Jet 4.0 engine, come with a version of ADO and Jet 4.0/DAO 3.6 installed on them. It'll be interesting to see what happens in Windows 8 with those and also, dare I bring up the topic yet again, the VB6 runtime. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ On Fri, 3 Sep 2010 06:42:44 -0700 (PDT), "Scott M."
<quan***@gmail.com> wrote: >I solved the problem. It turns out that the Microsoft program that Thanks for replying back with the solution. Unfortunately so few>creates the setup files (Package and Deployment Wizard) omitted a key >dll file, MSDERUN.DLL, needed by the program that allows it to use >Access databases. It took me two days to figure this out. This >particular dll was already installed on all of our other test systems, >so the problem never showed up until I created a fresh Windows XP >installation. A search of my own test development system for this dll >came up empty, throwing me off until I re-ran the search and included >system and hidden files. > >I hope that this helps another developer some day. > posters do that. and yes it will help should some else having the same problem stubble across this thread. Also note this kind of problem can usually be avoided if one pays particular attention when they build the first P&D package from a VB Project. At some point, P&D came back with a message saying that dependancy information was missing for a particular component. You had the option to ignore the warning, to include the component, or to exclude it. The trouble is once you pick an option - that option stays set. P&D will never bother you again. <g> Most of the time we are familar with the particular component and skip on by, selecting a specific option by habit. However, this default behavior can come back to bite you. <g> Always good to stop for a moment and make sure. Another possible "Gotcha" with P&D is that it will include in its package the component it finds in the setup wizard \Redist folder and not necessarily the one the Project was compiled against. This was a problem years ago when there were different versions of MSDERun but less likely today. -ralph |
|||||||||||||||||||||||
Other interesting topics