This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Vista only issue after upgrade to 2010...
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 21, 2009
01:15 PM
Vista only issue after upgrade to 2010...
I am receiving three (3) errors on a Vista system...
1. During Installation:
2. After installation:
So it all boils down to a few specific questions:
[LIST=1]
Has anyone had any issues converting from an older version of InstallShield to 2010 and recieved similar errors?
After researching (for the past few hours) I keep reading about how there are different versions of CTL3D32.DLL for Windows 95 and NT (NT needing a different version). Is this true for Vista too, does Vista need it's own version?
The installation (using this installshield version, 2010) works fine on Windows XP but throws the above errors whenever someone installs on Vista. The last version of InstallShield that was used was able to create a Vista installer but since converting we are unable to get past this error. I keep reading about how there are different versions that are OS specific so I am at a loss here on this. Also I am unsure if this issue is caused by the DLL versions...
The only change I have made since the conversion is to add a string to the 'product version' area under the 'General' section.
Any help is greatly appreciated! And please realize that I have inherited (was hired to replace someone) and am fairly new to this process/position so please bear with me... Thank you...
1. During Installation:
The following error occurred on the file 'C:\...\CTL3D32.DLL'.
2. After installation:
The Following files did not self-register or unregister:
1. C:\Windows\system32\Oleaut32.dllAccess is denied.
2. C:\Program Files\Common Files\Microsoft Shared\Dao\DAO350.DLLError accessing the OLE registry.
So it all boils down to a few specific questions:
[LIST=1]
The installation (using this installshield version, 2010) works fine on Windows XP but throws the above errors whenever someone installs on Vista. The last version of InstallShield that was used was able to create a Vista installer but since converting we are unable to get past this error. I keep reading about how there are different versions that are OS specific so I am at a loss here on this. Also I am unsure if this issue is caused by the DLL versions...
The only change I have made since the conversion is to add a string to the 'product version' area under the 'General' section.
Any help is greatly appreciated! And please realize that I have inherited (was hired to replace someone) and am fairly new to this process/position so please bear with me... Thank you...
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 29, 2009
09:24 AM
So if anyway for prosperity I figured I would share me find with the world:
After some more digging I found that there are certain files that in Vista are completely locked (meaning that they are cannot be overwritten). The product I work on included these DLLs because it used to support older versions of Windows. In the case of 3D control "CTL3D32.DLL" you CANNOT overwrite this file even in administrator mode. There are perhaps ways of getting around this but this is unnecessary since these DLLs have not changed since 98se (the versions shown in the properties menu remain the same).
I came upon a very good explanation Here.
So now I'm stuck at how to NOT install these files for a Vista (or Windows 7) box but allow them to be registered for older windows. Is there an easy solution that I may have overlooked?
After some more digging I found that there are certain files that in Vista are completely locked (meaning that they are cannot be overwritten). The product I work on included these DLLs because it used to support older versions of Windows. In the case of 3D control "CTL3D32.DLL" you CANNOT overwrite this file even in administrator mode. There are perhaps ways of getting around this but this is unnecessary since these DLLs have not changed since 98se (the versions shown in the properties menu remain the same).
I came upon a very good explanation Here.
So now I'm stuck at how to NOT install these files for a Vista (or Windows 7) box but allow them to be registered for older windows. Is there an easy solution that I may have overlooked?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 25, 2010
08:37 AM
Though at this point there is no reason for me to do this but:
I moved the XP only DLLs to their own component and used the options on the features to only install on certain OSs...
Thought the issue was more the "Why suddenly is this happening on 2010 and not IS6?"
I moved the XP only DLLs to their own component and used the options on the features to only install on certain OSs...
Thought the issue was more the "Why suddenly is this happening on 2010 and not IS6?"
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 26, 2010
03:41 PM
You're probably only seeing this issue with newer versions of InstallShield because all built setup.exe's contain an application manifest, which turns off a number of application compatibility shims in the OS (the manifest indicates to the OS that the EXE being launched is more or less compatible with the OS). Since the setup.exe's built with IS Pro 6 didn't contain an application manifest, Windows would have turned on a number of app compat shims that would have made it look like the registration of these files succeeded, when in fact, the registration was silently blocked and a success status was returned by the OS.
Moving these files to components that only install on older operating systems would be the best practice for resolving this issue.
Moving these files to components that only install on older operating systems would be the best practice for resolving this issue.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 26, 2010
03:47 PM
Then how would we update system components that need updating? Wait for Microsoft to patch it? I'm just wondering because of the DLLs and OCX's we need are version specific.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 26, 2010
03:57 PM
The file replacement mechanisms are documented in the following MSDN article:
Supported Resource Replacement Mechanisms
Basically, only operating system mechanisms are privileged enough to update protected resources. This functionality was added to prevent applications from overwriting system files with incompatible versions of these files.
Supported Resource Replacement Mechanisms
Basically, only operating system mechanisms are privileged enough to update protected resources. This functionality was added to prevent applications from overwriting system files with incompatible versions of these files.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 26, 2010
04:01 PM
Thank you, I appreciate the response. Now I can tell my boss that this wasn't something I did!
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)