Printable View
ok I have a program that uses lots of refernces of another
program on peoples PC's. Really I'm controling
that other application via VB.
so my real questions comes to the package .. do I
need to include all those dll etc from their app
in my package ? or can I pull those out, since they
should be there already.
or by me not including them do it not make the linking
work ?
this is all very new to me..
Are you installing their app as part of your package? If so, you need to include the references it needs.
Does your program have those references too? If so, and your program could potentially be installed without the other program, you should include them.
I'm not installing their software.. it should already be install on
that PC..
so really for this to all work.. they should have the other vendors
code on that PC and if they want our software to control
it then install my package..
they would/should not try to install my progam without install
the other vendors first.. but we know how it goes..
looks like if I do keep them in.. it will just try to overwrite their's in
windows\system32.. just trying to make my package smaller and
not cause any issues with theirs..
[Setup1 Files]
File1=@MDAC_TYP.EXE,$(AppPath),,,6/26/98 1:00:00 AM,8124720,4.71.1015.0
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),5/22/00 6:58:10 PM,1066176,6.0.88.62
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),6/6/02 1:34:34 PM,140288,6.0.84.18
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),5/15/07 4:43:10 PM,1320800,6.10.1200.0
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/26/07 12:20:44 PM,32768,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/26/07 12:34:32 PM,282624,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/26/07 12:31:56 PM,180224,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/27/07 1:05:56 PM,40960,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),3/14/07 7:48:52 AM,495616,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),3/2/07 1:33:08 PM,622592,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/26/07 12:24:34 PM,122880,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/26/07 12:30:38 PM,1056768,3.7.0.5
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),2/27/07 1:03:38 PM,36864,3.7.0.5
[email protected],$(WinSysPath),,$(Shared),6/23/08 12:12:05 PM,474112,6.0.2900.3395
[email protected],$(AppPath),,,10/23/08 2:10:36 PM,196608,1.0.0.0
As your program is reliant on theirs, you shouldn't need to install the same references as they do - just ensure that you install any extras that are needed.
Note that you shouldn't be installing MDAC on Windows XP or later, as it is pre-installed (with certain OS-specific 'tweaks'). I think from what has been posted before shlwapi.dll is similar, but don't use it myself.
Thanks SI.. I forgot about not putting in MDAC.. I just took it out.. and
yes its huge.. but now its small without it.. cool..
I always run into install issues with oleaut32.dll and versioning.. whats
the best way to deal with that.. include some ancient version in my package
so it keeps the one on their PC ? or can I just pull that out also since
its normally on their PC already ?
I'm not an expert on installation issues, so need to check that kind of thing myself when I make a package!
To try to get the experts involved, I've move this thread to our Application Deployment forum.
I think the documentation in the FAQs at the top of this forum gives some kind of answer to your last post.
See MS07-043: Description of security update for the Visual Basic 6.0 redistributable which points out one more reason why you want to be very careful about shipping VB6 runtime components as part of your application installer.
Shell and Common Controls Versions states that shlwapi.dll is part of IE and the Windows Shell and should not be redistributed.
Also see Installing and Redistributing MSXML 6.0, which cannot be safely redistributed using PDW without modifying Setup1 to run msiexec against the msxml6.msi at the right time.
ok thanks for the info.. some questions.. on oleaut32.dll .. how does one do this ??
If you want to build a single package or Setup program to handle all destination operating systems, use the following guidelines:• The package or Setup program must bundle all the different versions of the Oleaut32.dll file.
• During installation, the package or Setup program must detect the destination operating system. Additionally, the package or Setup program must select the correct copy of the Oleaut32.dll file to install.
and on the XML60.. I looked at that page.. it says "To redistribute MSXML 6.0 with your application, you should incorporate msxml6.msi into your application setup" but then when I goto the page that says it will tell you how to do it.. I dont see anything about it.. anyone know how to do this ?
why cant enything be easy !!!
What it is telling you is that the PDW is too old and simple to do this installation. You should use Visual Studio Installer 1.1 instead.
The alternative is to modify PDW's Setup1 program (you already have the source in the same folder as PDW itself - Setup1 is written in VB6). This may be more work than just learning how to use VSI 1.1, and the truth is VSI 1.1 probably won't give you enough control. It is old now too.
You can use VSI 1.1 if you add all of the different oleaut32.dll versions and set an OS condition on each one, and after building the new MSI you edit it via the Orca.exe tool or by some other method to add a Custom Action to run msiexec against the msxml.msi package.
Or else you can create several OS-specific setup packages as Microsoft suggested. Have you considered "Visual Basic" 2008 .Net Express?
An alternative is to move to a more sophisticated packaging tool (such as Installshield) which is a bit more flexible than VSI 1.1 and newer and more aware of these things. Another alternative might be to use an installation script written in VBScript that checks the OS and does what is needed.
This oleaut32.dll situation is why I tell people to stop installing VB6 runtime components anymore. You risk either reintroducing the original security vulnerability or putting wrong-OS code on users' machines (kaboom). This "solution" has its own drawbacks of course, and won't work at all if installing to an unsupported OS like Win95/98 that might have no VB6 runtime or a very old and buggy one.
Warning, political opinion:
VB6 is old. Life is hard. I blame Anders Hejlsberg and the rest of the anti-VB crowd at Microsoft myself. ;)
Anders Hejlsberg: Turbo Pascal
By rights we should be using a real VB9 with decent tool support by now. But VB was killed off in 2001. Have you considered "Visual Basic" .Net 2008 Express?Quote:
Anders Hejlsberg is one of Microsoft's handful of distinguished engineers. He is known for having developed the Borland Turbo Pascal compiler and for having been chief architect of Borland's Delphi technology. Hejlsberg left Borland, where he last served as chief engineer, to join Microsoft in 1996. Since joining Microsoft, Hejlsberg's greatest claim to fame has been fathering the C# programming language. Originally code-named "Cool," C# was designed to be Microsoft's Java killer.
...
Do you know that the man behind Delphi is Anders Hejlsberg, one of the original members of the Borland company. During his time with Borland he extended its' Turbo Pascal compiler. Eventually he became the chief architect for the team which produced the replacement for Turbo Pascal - Delphi. As a chief architect at Borland, Hejlsberg secretly turned Turbo Pascal into an object-oriented application development language, complete with a truly visual environment and superb database-access features. Once touted as the "VB killer," Delphi has remained a cornerstone product for Borland.
thanks again for the info.. I just use what tools work gives me..they
all still use vb60..not sure when they will move to .net..
but I know we use installshield.. I'll just need to get hold of it
and use that for the install I rekon.. I just need to get this
new app to the client this week.. so I'm in a time crunch.. I didnt
know PDW stunk so bad.
you think installshield will fix my MSXML issue also ?
Using Installshield should make it easier to roll the msxml.msi into your parent msi and execute it during the installation process. It is remotely possible that Installshield even offers a merge module for it, they often repackage things like this.