I am working on a program which uses Access 97 databases (with DAO350.DLL). My goal is to make this program use Access 2007 (and so ACEDAO.DLL) and then deploy the new version on several computers (win7 64bits sp1 without office at all), which don't necessarily had the previous version of the program installed.
I made a new setup by modifying the former setup of the program (created with Package & Deployment Wizard). I thought it was a good idea since PDW doesn't find all the dependencies of the program (former setup contained added-by-hand files) and so I added ACEDAO.DLL.
The setup is made of : Setup.exe, Setup.Lst (which list all files to install and their properties) and a bunch of .CAB archives that contain the files to install.
The line of Setup.Lst concerning ACEDAO is the following :
File97=#ACEDAO.dll,$(CommonFiles)\Microsoft Shared\OFFICE12\,$(DLLSelfRegister),$(Shared),08/21/11 04:52:00 PM,573440,12.0.6650.5000
When I execute Setup on an other pc, I get this error :
ACEDAO.DLL was loaded but entry point for DLLRegisterServer was not
found
I learned afterwards that ACEDAO does not contain DLLRegisterServer function, therefore it couldn't work.
Moreover, ACEDAO needs MSO.dll. When I add MSO to the Setup, this one keeps loading the last file (VB6FR.DLL) from [Bootstrap Files] section of the .Lst file forever :
Traitement de VB6FR.DLL (9/9)
My questions are :
What can I do to register ACEDAO using the setup ?
Any idea why the setup stops when I add MSO.dll ?
I apologize for the grammar quality, English isn't my native language.
Replacing/adding DLLs manually is not going to work, there is a large tree of additional file dependencies involved - for example the COM libraries that wrap ACEDAO.DLL driver.
You need to include the correct redistributable which is probably:
Microsoft Access Database Engine 2010 Redistributable
Your installer will need to run this to install all the files & prerequisites.
Related
We have a problem that a fie is not installed upon a major update
We have a major update with <MajorUpgrade Schedule="afterInstallInitialize"...
We an old component with 1 file (xyz.exe Version 12.34) from a external manufacturer
We have now a new file from a new manufacturer and with the same name (xyz.exe Version 2.34). The new file has a lower version number than the old one.
We created a new component in the install package and removed the old component (in fact we gave it a new guid)
Changing the name of the exe isn't possible, it would have to much influence upon documentation and internal functions.
On a normal installation everything is OK.
But what happens now on an update:
The installer starts.
And detects that the new component exists (xyz.exe) with a lower version, so it will not be installed.
the installer runs and removes the old component
But it doesn't install the new because it just detected that the component was already installed.
Doing a repair installation fixes the problem and the file is than again present.
Setting the KeyPath to the Component fixes the problem. But it seams wrong to me. The directory where this file is installed is the main installation directory.
How to force the installation of this component?
Similar Answer: How to Explicitly Remove dll During Majorupgrade Using Wix Toolset
Major Upgrade Downgrade: In order to overwrite binaries with higher version numbers on major upgrades there are a couple of preferred options:
The preferred approach would be to use a companion file (third party files).
Or if you can: compile a new binary with a higher version number (for your own files).
Companion Files: A snippet below on how to use companion files in WiX:
<..>
<Component Id="MyFile.exe" Feature="Main">
<File Id="MyFile.exe" Source="MyFile.exe"></File>
</Component>
<!-- Do not re-use any GUIDs in your own sources! (very important) -->
<Component Id="MyFile_2.exe" Guid="{00000000-0000-0000-0000-3D82EA2A99AF}" Feature="Main">
<File Source="MyFile_2.exe" CompanionFile="MyFile.exe"></File>
</Component>
<..>
One-Line Summary: In the second component we point to the first component's file so that MyFile_2.exe will install whenever MyFile.exe is installed - regardless of versioning issues.
Then there are a number of further options:
REINSTALLMODE: The MSI property REINSTALLMODE can be used - but it has a number of side-effects:
Setup 1: Version 1.0.0 for a setup:
msiexec.exe /i Setup1.msi /qn
Setup 2: Version 2.0.0 for the major upgrade setup:
msiexec.exe /i Setup2.msi REINSTALLMODE=amus /qn
Several Problems: There are several issues with REINSTALLMODE that makes it an unsafe feature to use (try emus instead? See documentation - a little less brute force maybe). It is a shame that this setting applies to all features in the setup - that makes it very dangerous:
can downgrade shared files system-wide - if there are merge modules included - for example (features in Windows are in place to prevent most of this problem: WFP and WRP in Vista an beyond - non-Microsoft merge modules can still cause problems for non-Microsoft shared files)
can cause inconsistent version estate since an old package can be installed after a newer one and downgrade only some of the shared files
can downgrade or wipe-out settings in non-versioned files and registry settings (note to self: test this again, there are complexities with component settings)
can cause a significant increase in the number of requested reboots due to attempts to needlessly replace in-use files of the same version (the real fix for this is to shut down services properly and to use the restart manager to allow applications to be shut down automatically during deployment - on file locks).
there are several further issues that are quite specific
Hack Binary Version: An ugly, but effective option is to change the version of the actual binary file using Visual Studio to set a higher version number (you open the binary as a resource and set a new version - this is obviously very different from compiling a new version of the binary using visual studio source code compilation). There are several side effects:
you break digital signatures
you can create "version confusion"
there are risks involved writing a new binary from Visual Studio
it is a "hack manual step" - you might need to keep doing this for new versions?
etc...
Move, Rename: If you can de-couple the new file from the old by renaming it or moving it you can work around the problem. If you get a new version again for the future, you might have to do this again. Clunky.
"Load From": Putting the file somewhere shared and load it from that specific location and removing the old copy from your installation folder. Could that work? This means the file could also be delivered by another setup at that location.
Version Lying: In Installshield there is a concept of being able to set a specific version number to a file. I am not sure how to implement that in WiX. There is also an "always overwrite option" that apparently sets a maximum value for the version so the existing file is always overwritten.
Some Links:
Why Windows Installer removes files during a major upgrade if they go backwards in version numbers
"Downgraded" MS dll disappears on upgrade - Windows Installer
Install a file regardless of version number with WiX
How to make better use of MSI files
The opposite side of it: file preservation and file overwrite rules.
I have 1 dll file which I try to load during the installation with UseDLL() in one of my installscripts.
this dll has 2 dlls it depends on. they both located on the same directory of the main dll.
When in build the installation with an older installshield - it find it's dependencies and works fine.
When I try to build it with IS2016, it fails because it doesn't find it's dependencies. (If I put these 2 dlls in SysWOW64 - it finds them and works fine).
What is the problem?
Thanks,
Dudi
It looks like InstallShield 2018 makes this easier through a new Enable/Disable flag called DLL_DIRECTORY_SUPPORTDIR. But in InstallShield 2016 there's a good chance you can add the following InstallScript code to find dependencies in SUPPORTDIR. If your DLLs are in a different directory, substitute that instead.
// Add prototype for SetDllDirectory(); this typically goes near the top of your script
prototype number kernel32.SetDllDirectoryW(wstring);
// Call it; this goes in a function called before your UseDLL call
SetDllDirectoryW(SUPPORTDIR);
Note that doing this removes some protection against DLL planting, so it is safest to do this only if you ensure the DLLs in question are either proactively resistant to such things, or if you vet and secure the directory in question. (I'm uncertain whether InstallShield does this for you.)
I migrated my WIX project from V2 to V4 and then changed the namespace in the .WXS files
I replaced the below namespace
<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
with
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
Once the changes have been made when i run the build installer i am getting the below error:
error CNDL0199 : The Wix element has an incorrect namespace of
'http://schemas.microsoft.com/wix/2003/01/wi'. Please make the Wix element
look like the following: <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
E:\Code\EMR\Wix\src\EMR_Registry_entries.wx
I replaced the new namespace but it is not reflecting. Once i run the build installer it is setting with the old namespace. I tried multiple times but it is always setting the old namespace.
Please help me to resolve the issue.
UPDATE: Question that came up from a second read of your question.
Source Control: "Once I run the build installer it is setting with the old namespace." - are you sure the build process doesn't
auto-magically 1) check the WiX source out of your source control system? Or 2) maybe it is doing some XML manipulation via the automation script?
WiX Version: Are you sure you are compiling with WiX 4? Maybe you are compiling with WiX 2 or WiX 3 unintentionally? Try hard coding the full path to the WiX binary in your build system - if you have one. Please see this (Sean is a WiX developer): Migrate Wix Project to version 4.0. Frankly I am not sure how well WiX handles multiple-version installations on the same box combined with migrated sources (identically named binaries of different versions - WiX 2, 3, 4 - globally applicable via the PATH variable? Not sure).
Visual Studio / Cmd.exe?: Are you compiling with Visual Studio or via the command line? (I am not quite sure reading your question). Maybe try via the command line (towards bottom) if you are using Visual Studio - or vice versa. Make sure you use the correct WiX binaries (in other words WiX 4).
Linked Files?: I don't have any WiX 2 sources to migrate, but I am wondering if you have several source files that are interconnected. Was that even possible in WiX 2? I can't remember. In either case, I would make sure you have updated all WiX source files that are pulled in during the build process. Please read the log carefully. Maybe try to compile them with Candle.exe directly using the command line (cmd.exe instead of Visual Studio) to see if the file compiles OK.
Source Files?: If it still does not work, please put the source file online so we can have a peek. Github.com for example. A quick look at the source (the real McCoy) goes a long way sometimes - and sometimes it doesn't help at all. Maybe give it a go. Redacted sources are just fine - encouraged even. Please pay close attention to sensitive data: How do I avoid distributing sensitive information in my MSI by accident? (and this also goes for published source files - obviously - not just the compiled MSI and its helper files - such as silent installation template batch files).
In summary: That became a lot of babble. Maybe first try to compile the migrated WiX source with the right WiX 4 binaries to
determine if that works or not. Then work backwards to figure out what
happens during the build process.
I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!
I am using heat to harvest the COM dll and tlb files (let's call them MyLib.*, developed in VB.NET) to do the COM registration. Everything was working fine, when I install MyLib.dll and MyLib.tlb into my application's installation folder, i.e., INSTALLDIR. However, since we want to allow different versions of our SW to be installed on the same machine, and if they are using the same version of COM component, only one copy of the dll (I think each version of our SW should have its own tlb, please correct me if I am wrong) should be installed, we now want to install MyLib.dll into another folder, specifically PROGRAM_FILES\Common Files\SHARED_FOLDER_NAME, so now if one version of our SW is uninstalled, the MyLib.dll will not be removed and can still be used by other versions.
But here comes the problem: my COM registration is just simply not working any more after I install this dll into this another folder, and it keeps saying that can't find file specified when I am calling the COM function which indicates registration failure. In the WIX installer project, everything is the same except this folder for MyLib.dll.
Here is the registry structure after installation:
Firstly I have HKCR\CLSID{MYCLSIDs}, each of them represents one of my COM class. in the sub-key named "InprocServer32", I have Assembly, Class, CodeBase, RuntimeVersion, threadingModel. And the CodeBase is either common file folder (not working) or MyApp's installation folder(working), which is the different locations I put the dll. I thought there would be another sub-key TypeLib under {MYCLSIDs}, since Access only sees the TypeLib and I think there should be some link from the TypeLib to the actual dll, however, at both cases this sub-key is missing but in the second case it is still working. Is there a problem of it?
Secondly I have HKLM\Software\Classes\CLSID{MYCLSIDs}, these keys are of course the same structure as described above.
Thirdly, the HKCR{MYPROGIDs}, these are just ProgIDs of my classes
Fourthly, HKCR\Typelib{LibID}, which includes the information from tlb file, and this ID is from the Assembly GUID of COM component project.
Finally, the HKEY_CLASSES_ROOT\Interface{InterfaceID}, there is sub-keys named ProxyStubClsid32 with value {00020424-0000-0000-C000-000000000046}, and the one named TypeLib and the value is my LibID.
As I mentioned, the only difference is the CodeBase, which stores where MyLib.dll is located. In order to verify that, I did two tests: after I install MyLib.dll into the shared folder, the COM calling fails. But if I replace all the CodeBase values for SHARED_FOLDER\MyLib.dll to INSTALLDIR\MyLib.dll, and copy MyLib.dll into INSTALLDIR, it actually works. Vise versa, after I install MyLib.dll into INSTALLDIR(in which case COM is working), I change the CodeBase values from INSTALLDIR\MyLib.dll to SHARED_FOLDER\MyLib.dll, and make a copy to SHARED_FOLDER, this time it fails. So it seems that it is exactly the installation location's problem, which is the opposite to my understanding of COM. And I don't think there is a permission issue for the SHARED_FOLDER(I could be wrong) since it is in a folder that my installer creates.
Please help, thanks!
It turned out that MyLib.dll is using some other libraries, which are still installed in the MyApp installation folder. And so in that case that MyLib.dll is installed in the shared folder, it tries to find those libraries in the same libraries, which of course fails. When I install those libraries in the shared folder too, it is working.
BTW I found fulogvw.exe very helpful when tracking down the assembly loading problem. For example in my case in the failed log it says can't load file xxx.dll in SHARED_FOLDER, the xxx.dll is some library that MyLib.dll is using, and I had no idea that MyLib.dll needs it until I see the log.