When i try to run a msi using System.Process.Start("test.msi") in a vb app i get the following error.
The installation package could not be opened. Contact application vendor...
Msi file works fine when double clicked, tried System.Process.Start with text files and exe files and they work fine, problem only with msi
files. Running vista. Also tried xp but no luck
Thanks
If you have a setup.exe with your msi, run that instead. Otherwise, use this code:
Process p = new Process();
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i PathToYour.msi";
p.Start();
(from here: MSI doesn't run from within C#)
The reason for needing to do it this way is that when you do System.Process.Start("file.txt") it will work since it is (sort of) calling notepad.exe %1 which will work for a text file but msiexec %1 will not work for a msi, since msiexec has a required parameter (Option).
You can test this yourself, by trying msiexec file.msi on the command line - it will give you this helpful little message:
To help pinpoint the problem, try running some other .exe from your code, like notepad.exe.
System.Process.Start("notepad.exe")
Had the same problem. The problem lies on declaring the path of the msi. You need to put double quotes around it.
Instead of
p.StartInfo.Arguments = "/i PathToYour.msi"
try
p.StartInfo.Arguments = "/i ""PathToYour.msi"""
Related
I have a Webrowser wich running with the gecko engine in VB.
And I want to clean everything before start, like I can do it with CCleaner and firefox. So I wrote a batch file that delete the defaultprofile folder(../appdata/geckofx/) and then starts my .exe
Everything works fine but my question is if there is another place where xulrunner or geckofx store anything in another folder or is my solution already "completely clean"?
Added my batch code if somebody wants to use it:
rmdir /s /q "C:\Users\Administrator\AppData\Local\Geckofx\"
cd %~dp0
start %1myprogram.exe
Clean everything:
Dim CookieMan As nsICookieManager
CookieMan = Xpcom.GetService(Of nsICookieManager)("#mozilla.org/cookiemanager;1")
CookieMan = Xpcom.QueryInterface(Of nsICookieManager)(CookieMan)
CookieMan.RemoveAll()
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 a program that auto-updates itself when it finds a newer version MSI. I used to create the MSI with a VS2008 Setup project. I migrated the development to VS2013, lost the Setup project, tried IS and got extremely frustrated and finally landed with WIX.
The MSI created with WIX does all I need but fails in the auto-update logic:
Because the program can be running under a limited user account, when it detects a newer MSI, it first Advertises it with the credentials of an Administrator. These credentials are stored encrypted in an XML file.
Then, once the MSI has been advertised, it is launched with the current user. The code (in short)
Process^ advertise = this->advertiseMSI(shortpath,mydomain,myusername,mypassword);
advertise->WaitForExit();
Process^ install = this->installMSI(shortpath);
Where advertiseMSI is:
Process^ process = gcnew Process();
process->StartInfo->UseShellExecute = false;
process->StartInfo->FileName = "C:\\Windows\\System32\\msiexec.exe";
process->StartInfo->Arguments = "/jm " + "\"" + msiPath + "\"";
process->StartInfo->WorkingDirectory = Environment::GetEnvironmentVariable("WINDIR");
process->StartInfo->UserName = userName;
process->StartInfo->Password = this->getSecureString(Password);
process->StartInfo->Domain = userDomain;
process->StartInfo->Verb = "runas";
process->Start();
return process;
and installMSI just launches the Msiexec in a silent install with the current user.
This worked fine with the MSI created with VS2008 but it fails with the WIX MSI.
The log of the msiexec is:
"Error 1730. You must be an Administrator to remove this application..."
If I run the MSI manually, it works when logged as admin but when logged as user it fails and doesn't ask for elevating privileges.
I have set InstallPrivileges="elevated" InstallScope="perMachine" in the Package section and does not make a difference (I have tried every possible combination of those). It seems to me that the MSI is not advertised but the code does not fail. Looks like the MSI is always run with limited privileges.
I have also tried to set AllowAdvertise="yes" in the only one Feature of the product.
One main difference I can see with the MSI produced with VS2008 is that the later had two features, Admin and user.
I don't know if you're still struggling with this problem, but I've come across a similar problem with an installer built with NSIS, so perhaps this will help you or others. I was able to overcome this in my situation by using command shell indirection as follows (C# code):
ProcessStartInfo processInfo = new ProcessStartInfo("cmd", "/C myapp_installer.exe /S /D"); // Options /S /D apply to myapp_installer.exe.
processInfo.UseShellExecute = false;
processInfo.Domain = domain;
processInfo.UserName = username;
processInfo.Password = password; // Obtain securely not hard-coded.
Process process = Process.Start(processInfo);
I can't fully explain why this works, when directly calling the installer fails to pass the required credentials, but I'm pretty certain that it has to do with what is explained by Chris Jackson on the MSDN Blog, which incidentally was referenced in the answer to your related question.
I hope this helps!
I am using WIX 3.8, Windows 8 Pro, Visual Studio 2013, and I am doing a Silent Installation.
When I run with no /quiet arguments, Ir runs OK. But when I put "/quiet", nothin happend.
There is some problems with /qn Arguments... Any other Arguments Runs OK.
string arg = " SetupWIX.msi";
Process p = new Process();
p.StartInfo.FileName = "msiexec.exe";
p.StartInfo.CreateNoWindow = true;
p.StartInfo.Arguments = "/i " + arg +" /quiet /l*v log.txt";
p.Start();
And it give error 3.
MainEngineThread is returning 1603.
Any Ideas?
Tahnks
Based on the log you sent me, your MSI need to be elevated.
Not all MSI's do. Most do. If you are installer in a per-machine context and/or writing to restricted areas ( Program Files, HKLM, Windows an so on ) you'll need elevation. Typically when you double click an MSI the UI sequence runs as standard user and then when it transitions to the Execute sequence it'll prompt for elevation if required. However when you run /quiet it can't do that so it just fails instead. The two ways around this are to elevate the calling process or first 'advertise' the MSI so that the system trusts it. In that case the UI->Exec elevation happens automatically without a UAC request.
I SOLVE IT!! Thanks yopu all for your time
I was MIssing
p.StartInfo.Verb = "runas";
I did not know I need Administrator Privilegies to execute "/quiet".
A problem that has been plaguing me for nearly a week now.
I am trying to get an install of IIS to take place through the command line in VB. I understand that i need to be setting up an Unattended xml script to call, but here is a fundamental bit that is confusing me:
If i run the command : ' start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer; ' it executes perfectly within CMD.exe.
If i add the command to a batch file and run the batch file, it runs perfectly.
If i call the command using : Dim myProcess As Process = Process.Start("cmd.exe", "/k start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;"), then it fails with an error of:
////////////////////////////////////////////////////////////////////////////////////////////////////////////
Operation failed with 0x8007000B ////
////
An attempt was made to run the program in an incorrect format ////
////////////////////////////////////////////////////////////////////////////////////////////////////////
If i call the batch file mentioned earlier, then i get the exact same error.
How can it work perfectly with the two first examples but fail when it is called through VB?
Thanks for any help!
Your VB.NET program is very likely to be running in 32-bit mode and will start the 32-bit version of cmd.exe. The one from c:\windows\syswow64 instead of the one from c:\windows\system32 that you used before. Getting BadImageFormatException starts to become likely.
Project + Properties, Compile tab, set the Target CPU to AnyCPU and untick the "Prefer 32-bit" option. On older versions of VS click the Advanced Compile Options button to get to the setting.