I have a WIX installer that acts as a content installer for users. It's supposed to install these files in a specific directory. Unfortunately when I run it I get the following error: "The system cannot open the device or specified file." This then gives me error code 2755 after canceling the install (retry does not work).
I've looked through other questions with similar issues, and it does not appear to be an encryption problem on temp, the install folder, or the MSI installer itself - these all appear fine. This also isn't a problem with the C:\Windows\Installer folder being read-only.
I've never had a problem with a WIX installer before. What other things can I try to get this working?
For me the problem solved when the installer run as administrator.
I was seeing all of the following errors when installing my 3.5 GB .msi generated by WiX:
DEBUG: Error 2709: The specified Component name ('cmpF7216C180B7A7119CC61FDB3BD209D5D') not found in Component Table.
DEBUG: Error 2755: Server returned unexpected error 110 attempting to install package D:\...\setup.msi.
The system cannot open the device or specified file
Turning off EmbedCab made them all go away:
<Wix>...
<Product>...
<MediaTemplate EmbedCab="no" />
I unfortunately now have 30 cab files to deal with, but at least the install succeeds.
Related
I have difficulties updating my development machine to use the newest Visual Studio tools to support my development.
I did the following (VS2015 means Visual Studio 2015 Community Edition):
Uninstall my previous version of VS2015 Update 1. I should mention that I have installed various stuff on top of this such as AspNet5.ENU.RC1_Update1_KB3137909.exe and VWDOrVs2015AzurePack.exe (VS tools for Azure).
Restart
Install VS2015 using this file vs_community__55e913f53149d443afc7d14b09172fd9.exe. This ended with minor errors such as
[0EE0:0E48][2016-08-10T11:42:51]i301: Applying execute package: MobileServicesConnectedServices_VS, action: Install, path: C:\ProgramData\Package Cache{A4495E4F-5218-48FB-8AD2-F3076011B9E1}v14.0.23107\packages\MobileServicesConnectedServices\MobileServicesConnectedServices_VisualStudio14.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" NOVSUI="1"' [16DC:16E0][2016-08-10T11:42:58]i000: MUX: ExecuteError: Package (MobileServicesConnectedServices_VS) failed: Error Message Id: 1722 ErrorMessage: There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.
[0EE0:0E48][2016-08-10T11:42:58]e000: Error 0x80070643: Failed to install MSI package.
and
[0EE0:0E48][2016-08-10T11:42:45]i301: Applying execute package: AuthenticationConnectedServices_VS, action: Install, path: C:\ProgramData\Package Cache\{3FEAC561-1CF6-41D6-B0F3-BECDD9C88A1B}v14.0.23107\packages\AuthenticationConnectedServices\AuthenticationConnectedServices_VisualStudio14.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" NOVSUI="1"' [16DC:16E0][2016-08-10T11:42:50]i000: MUX: ExecuteError: Package (AuthenticationConnectedServices_VS) failed: Error Message Id: 1722 ErrorMessage: There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.
[0EE0:0E48][2016-08-10T11:42:51]e000: Error 0x80070643: Failed to install MSI package.
Restart
Now, if I try to install the VS2015 Tools Preview from a file called DotNetCore.1.0.0-VS2015Tools.Preview2.exe I get this error:
Setup has detected that Visual Studio 2015 Update 3 may not be completely installed. Please repair Visual Studio 2015 Update 3, then install this product again.
and when I open the log file I see this:
[1B14:1A6C][2016-08-10T12:58:43]e000: Error 0x81f40001: Bundle condition evaluated to false: WixBundleInstalled OR NOT(((VS2015CommunityUpdateVersion <> VS2015UpdateVersion) AND (VS2015CommunityExists) AND (VS2015UpdateVersionExists)) OR ((VS2015ProfessionalUpdateVersion <> VS2015UpdateVersion) AND (VS2015ProfessionalExists) AND (VS2015UpdateVersionExists)) OR ((VS2015EnterpriseUpdateVersion <> VS2015UpdateVersion) AND (VS2015EnterpriseExists) AND (VS2015UpdateVersionExists)) OR ((VS2015WebExpressUpdateVersion <> VS2015UpdateVersion) AND (VS2015WebExpressExists) AND (VS2015UpdateVersionExists))) OR (SKIP_VSU_CHECK=1) OR (WixBundleAction=2)
I am now trying to install from scratch using a fresh Windows 10 installation to avoid problems related to side-effects from earlier installations.
I'm curious though to find out, what might cause these problems, and find out if I am doing something wrong.
Edit 2016-08-10: I have now verified that the same error occurs on a freshly installed Windows 10.
I found the solution after some more digging. It turns out many people faced this problem as described here:
(Click the Reviews tab):
https://visualstudiogallery.msdn.microsoft.com/c94a02e9-f2e9-4bad-a952-a63a967e3935
After trying this from a command prompt:
DotNetCore.1.0.0-VS2015Tools.Preview2.exe SKIP_VSU_CHECK=1
the installation continues.
Above didn't work for me, nor did several other solutions I found online, but this finally worked:
Go to extensions folder, e.g. C:\Program Files (x86)\Microsoft
Visual Studio 14.0\Common7\IDE\Extensions
There will be a lot of cryptically named folders, e.g. "kehkjkd2.pme"
Open each folder to see if it is a nuget extension folder (if it contains ~40 files named nuget.*.dll)
If it is a nuget extension folder, delete it or move it to a backup folder.
Repeat - there may be multiple folders containing nuget.
After doing the above and rebooting (not sure if the reboot is necessary), the .NET Core 1.0.0 VS 2015 Tooling Preview 2 install worked.
I'm trying to install the 3.10.2 version of the Wix Toolset Installer but when I launch the installer nothing happens. Pulling up the log file reveals the following errors:
[15A4:1580][2016-03-04T07:54:57]e000: Error 0x80070005: Failed to launch clean room process: C:\Users\MALLAR~1\AppData\Local\Temp\1\{BA709DF5-6D54-418B-9760-DD363E3FE5DD}\.cr\wix310.exe
[15A4:1580][2016-03-04T07:54:57]e000: Error 0x80070005: Failed to run untrusted mode.
I am unable to find anything related to this error.
3.10.2 introduced the clean room concept to mitigate dll hijacking attacks. This involves copying itself to a clean folder in the user's temp directory and then doing most of the work from that new process. Aggressive AV products might interfere with this. For more information about clean room see http://wixtoolset.org/development/wips/5184-burn-clean-room/ and https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/.
My SQL Server 2012 suddenly stopped working here is all I got in popup message:
could not load file or assembly 'microsoft.visualstudio.shell.ui.internal' or one of its dependencies. An attempt was made to load a program with incorrect format.
I have Repaired using installation CD but no luck.
I had the same problem and fixed by uninstalling the Visual Studio 2010 Shell and installing back. Simply reinstalling doesn't work.
1. Download the Visual Studio 2010 Shell: https://www.microsoft.com/en-us/download/details.aspx?id=1366
2. Run the exe file and click uninstall(or remove).
3. Run the exe file and click install with default settings.
After these steps the Management Studio will work just fine.
I got this error in VS2013 when reparing in the logfille,
[113C:2588][2018-01-20T16:41:54]i000: MUX: ExecuteError: Package (vs_minshellcore) failed: Error Message Id: 1305 ErrorMessage: Error reading from file C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.UI.Internal\v4.0_12.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Shell.UI.Internal.dll. Verify that the file exists and that you can access it.
and I check the file is exist, and I modify its access authority to complete control to every user account, but this error still occur,
Finally I delete this dll, and find same dll in another Normal Computer with VS , and copy the file paste to the problem computer, and run repair again then pass.
Share my works Microsoft.VisualStudio.Shell.UI.Internal.dll in Here.
But in my case after repair success, vs2013 still got error when opening, so I finally give up and turn to use vs2015, which luckly can work. It is a strange problem.
have this problem also with vs2019 community. I was trying to create the first 2019 project after it is installed. Then I got this. I ran the install exe file, vs_community.exe again in order to repaire it. But I found out that the install program request to restart the pc to finish the last step. Actually I restarted the pc afterwards manually. But I still did it by clicking on the button "restart pc". After the pc is restarted, the problem is gong. I can create project without any error.
I created an installer project for Win XP using VS 2013.
While trying to install it, I got an error:
"DIRCA_CheckFX. Return value 3."
I visited this article in StackOverFlow: DIRCA_CHECKFX Return Value 3 - VS 2013 Deployment Project.
I did the Suggestion that I read there - to replace the "dpca.dll" - and it works great !
But only at machines that I didn't install the bad msi before.
While trying to install the new version of msi on a machine that has the bad version, I got an error that this program is already installed.
But while trying to uninstall the program - I got the error of : "DIRCA_CheckFX. Return value 3."
My question Is - How to Unistall the bad Version Of my installer and prevent this error?
thanks.
The root cause of this is the perhaps silly choice to do a check for the .NET Runtime when uninstalling the product. I suppose it's possible that someone uninstalled the .NET FW and that you are running uninstall custom actions that require it, and maybe that happened to you, but it seems unnecessary to me IMO.
If I were to have this problem, there are two solutions:
If you have that exact same MSI file, same version, ProductCode, identical in every way, then open it with Orca and go to the InstallExecuteSequence table. Go to the DIRCA_CheckFX call and set a condition of False, save the MSI file. Then install that MSI file with a command line msiexec /i [path to new MSI] REINSTALL=ALL REINSTALLMODE=vomus and this will do an update in place of the installed product, including the call to DIRCA_CheckFX that is now suppressed. Uninstall should work.
In the absence of the proper MSI file, troll through the Windows\installer folder looking at the cached MSI files. Hovering the mouse over each should get you to your cached MSI for the broken product. Again, edit with Orca as above to suppress the call on DIRCA_CheckFX.
I have created a Web Server setup in WiX (3.8), It gets installed correctly, but when i Repair it, I get an error 'Fatal error during Installation' and the process is rolled back. below is what i see in logs
MSI (s) (F8:C4) [12:39:26:183]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (F8:F8) [12:39:26:188]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI7B14.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x80070002: Site not found for create application
WriteIIS7ConfigChanges: Error 0x80070002: Failed to configure IIS application.
WriteIIS7ConfigChanges: Error 0x80070002: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:39:26: InstallFinalize. Return value 3.
Am i missing out something. Any help is appreciated, Thanks in Advance :)
If it's a repair and the site name is missing, chances are that it was entered in a UI dialog in the original install. In a repair there is no UI to re-enter the site name and properties aren't automatically saved. It may be trying to configure a site with no name. The best way to deal with this type of thing in general is to use the WiX remember property pattern on the site name so that it is preserved and is available for a repair. I can't tell if that would be a good thing in this particular case because I don't know if writing the config changes again on top of the existing config changes will work or be handled correctly by the code. A verbose log of the original install should tell you what property names are being used for site names etc.
If you think it's unlikely that the IIS config changes will break and that they won't need repair, you could consider adding "Not Installed" to the condition on the CA so that a repair won't call it.