Winsxs Access

[rmoore]

Hi Support,
I am evaluating Installshield 2012 and my evaluation support number: 48599C4E2C7131D5485F.
I have packaged my product using Installshield 2012. While installing, I am getting following error,

Error 1310.Error writing to file:
C:\Windows\winsxs\Manifests\x86_Miscrosoft.VC80.CR T_1fc8b3b9a1e18e3b
_8.0.50727.762_x-ww_6b128700.manifest. Verify that you have access to
that directory.

In order to resolve above problem, manually I took ownership of ‘winsxs’ folder with my username. By default this folder is owned by ‘TrustedInstaller’. After taking ownership of this folder, I was able to install the application.

My question is, Using Installshield 2012, is there any setting to have full access to ‘Winsxs’ folder ?


Regards
Ronald

[joshstechnij]

Typically, only trusted components are allowed to write into this folder (i.e., the OS, at least on Vista and newer versions of Windows). Based on the file in the error, this appears to be related to a VC++ runtime component. Normally, the correct method of installing these components is to include the merge modules for the components (in this case the Visual C++ 8.0 CRT (x86) WinSXS MSM merge module from the Redistributables view) or by running the VC++ runtime installer executable from a prerequisite (this avoids issues with dependencies on the CRT being unavailable until after the installation completes when using the merge modules). Both the runtime installer and your installer could also be packaged into a suite installer as an alternate approach.

[rmoore]

Thanks Josh.

I'll check that out. Interim, can you please answer following query.

a. Is it possible in installshield to have setup.exe to always run as
Administrator ? Currently, I have to right click, and select Run as
Administrator.
b. Similar to setup.exe, is it possible to set application executable to always
Run as Administrator?

Regards
Ronald

[joshstechnij]

You can change the setup.exe to require admin privileges by going to the Releases view in your project, select the release you are building, go to the Setup.exe tab, and change the "Required Execution Level" setting as needed.

You can do this with any executable, but doing so requires changing the application manifest either in the development tool used to build the executable or using something like the manifest tool (mt.exe) provided by Microsoft. More information on execution level application manifest settings can be found at http://msdn.microsoft.com/en-us/library/bb756929.aspx.

[rmoore]

Hi Josh,
As per your instruction, I did following,

a. In Setup.exe tab, I have change the "Required Execution Level" to
"Administrator". After compiling the setup, when I double click on it, it
prompts with UAC dialog box. However, if I do right click and select 'Run as
Adminstrator', UAC dialog is not displayed. Is it possible to run setup,
without prompting UAC dialog (without doing right click).

b. I am still getting following error,

Error 1310.Error writing to file:
C:\Windows\winsxs\Manifests\x86_Miscrosoft.VC80.CR
T_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.manifest. Verify that
you have access to that directory.

As per your instruction, I did include Visual C++ 8.0 CRT (x86) WinSXS MSM
merge module from the Redistributables view. Please see the attachment.
On the right side in the attachment, under 'Number of files' section, there
exist x86_Miscrosoft.VC80.CR T_1fc8b3b9a1e18e3b
_8.0.50727.762_x-ww_6b128700.manifest file, which is causing grief.

Can you please help me in resolving this issue.


Regards
Ronald

[rmoore]

Hi Josh,
Referring to previous post Point 1.
If Setup.exe is on Network drive, then it prompts for UAC dialog, but if its on local drive, it doesn't prompt for UAC dialog.

I have created manifest file. With the help of MT.exe. I embedded manifest file in my application. When I double click, it prompts me with UAC dialog. Ideally, I just want to run the application without prompting UAC dialog.

Below is my manifest file.

Executable: OC.exe
Manifest:OC.exe.manifest
Sample application manifest file:



processorArchitecture="X86"
name="OC"
type="win32"/>
OC





level="requireAdministrator"
uiAccess="false"/>






Regards
Ronald

[joshstechnij]

Running an application with administrative privileges on Vista and newer versions of Windows, with UAC settings at their defaults, will result in a UAC prompt when launching the application. This is expected behavior to indicate to a user that the executable requires or is attempting to run with elevated privileges. Without changing the UAC settings on a machine we do not know of any way to run a process with elevated privileges without first having a UAC prompt displayed.

Regarding the runtime error, please create a verbose log of this installation with one of the following command lines and attach the log to this thread:
setup.exe /v"/l*v \"C:\PathToLog\LogFile.log\""

-- or --
msiexec.exe /i "C:\PathToMsi\MsiPackage.msi" /l*v "C:\PathToLog\LogFile.log"

[rmoore]

Hi Josh,
Enclosed please find a log file as required by you.

Regards
Ronald

[joshstechnij]

Looking through the log and the merge module that installs the file referenced by the 1310 error, it appears the component containing this file should not even be installing on Vista or newer machines. The component this file belongs to in the Microsoft VC8 CRT merge module is 'downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E'. The component has the following condition:

(VersionNT < 600) or Version9X

This condition will only evaluate to true on machines running Windows NT versions earlier than 6.0 (Windows 2003 Server, Windows XP, Windows 2000, etc.) or Windows 9x (ME, 98, 95). According to the log, the machine this installation is running on is Windows 7 (64-bit):

Property(S): VersionNT64 = 601

Based on that, the component should not be installing since its condition should disallow installation on Vista, 2008, 7, or 2008 R2. However, for some reason, the Version9X property is defined in this installation:

Property(S): Version9X = 0

A value of 0 is a non-empty value, which would cause the component condition to evaluate to true.

This property should only be defined by Windows Installer (http://msdn.microsoft.com/en-us/library/windows/desktop/aa372490(v=vs.85).aspx) on Windows 95, 98, or ME machines. Since this property is defined here, this indicates one of the following likely issues:
- This installation is improperly defining the Version9X through the Property table. Edit the MSI package directly in InstallShield or Orca to verify Version9X is not present in the Property table. If it is, check to see if it is present in the Property Manager in your Basic MSI project and remove it if it is present.
- The machine(s) this installation is being run on are somehow in a corrupted state, causing Windows Installer to define the Version9X property when it shouldn't. This installation should be tested on a brand-new, clean installation of Windows 7 to verify this is the case. If the install works on a clean install of Windows, the other machines are somehow in a corrupted state and would need have Windows reinstalled.

[rmoore]

Hi Josh,
Spot on, after deleting Version9X property from Property table. It works perfectly.

Thanks

[rmoore]

Hi Josh,
In one of the workstation, I am getting following error at the time of installation. Can you please help me to resolve this error. I am enclosing a image file of the error and logfile.


Regards
Ronald

[joshstechnij]

With 1935 runtime errors, we would typically recommend manually installing the redistributable for the VC libraries. If this still fails then unfortunately the machine is in some state that is preventing these side-by-side assemblies from installing. Unfortunately in past occurrences of this error, we have not determined what the cause is as the error is thrown by Windows Installer code and not our own. You may try looking through the following article to see if any useful troubleshooting tips can be applied:
How to fix some 1935 errors with HRESULT 0x80070005 (access denied) when installing the .NET Framework

[rmoore]

Thanks Josh

[sriram_rj]

i am trying to repackage an exe using install shield. After repackaging it i am getting the error as attached...

I found out that there are two dependent merge modules Microsoft_VC90_DebugCRT_x86.msm and Microsoft_VC90_DebugMFC_x86.msm to resolve this issue.. But these merge modules are not part of installshield application.

Can you please help me in resolving this issue..

[joshstechnij]

The debug versions of the MSVC++ merge modules are available with the version of Microsoft Visual Studio that was used to build an application (in this case, 9.0 is Visual Studio 2008).

Please note that it seems unlikely that a retail application would require a debug version of the VC++ redistributable files (implying that this would be a debug build of the application). You may try including the non-debug (i.e. release) version of the VC9 merge modules instead of the debug versions.

[sriram_rj]

Hi Josh,

Thanks a ton for your reply. From your suggestions I understand that non debug versions are referred to Microsoft_VC90_CRT_x86.msm and Microsoft_VC90_MFC_x86.msm. Please correct me if am wrong in this.. I tried building with these two modules but am getting build error as unable to compress the files.

Can you please throw some light on this?