I have this installation file setup.exe that was created with installShield wizard.
as part of the installation the user needs to prompt the installation path,
now i don't have any access to the installshield environment i can only run the setup.exe
file.
I want to activate the installation process via the command line in silent mode,and i need
a way to transfer to the setup.exe (via command line arguments) the installation path.
is there any way for me to do so ?? (msi installtion enables this option)
Thanks,
Liran
This depends mostly upon what kind of installation is behind the setup.exe you are installing. If it's a Basic MSI, you can pass MSI properties within a /v"..." parameter, and chances are good passing /v"/qn INSTALLDIR={path}" will be what you want. However if it's an InstallScript project, you'll need to record a .iss file, and include it to run silently.
See http://kb.flexerasoftware.com/doc/Helpnet/installshield15helplib/IHelpSetup_EXECmdLine.htm for details.
Related
I am trying to create an updater which will replace the files in the folder without needing an installer. As part of this process, I need to be able to delete old files and replace them by new files. I tried it and got an UnAuthorizedException. I am runing the updater as administrator. I tried the following
a. Setting the file and folder attribute to Normal
[Access to the path is denied when trying to delete a certain directory
b. Taking ownership of the folder and files contained in it
[Taking ownership of a file or folder
c. Changing the permissions and giving all users full control over the folder and files [Using a custom action in the installer]
[How to give Read/Write permissions to a Folder during installation using .NET
d. Running the updater from a windows service
There is no difference in the results. I keep getting the access denied error. What do I do so that the updater can delete the files?
It's not clear exactly what you mean by "running as administrator", but being logged in as administrator and running a program does not mean that the program is running with elevated privilege, which is what it really needs. But clearly the updater program is not running elevated.
So the issue might be that this updater program of yours needs an elevation manifest so that when you run it, it will ask for elevation with a UAC prompt.
Having said that, simply replacing files that were installed with a Windows installer MSI is not supported. The files must be replaced with a Windows Installer update such as a patch .msp file or an upgraded MSI file. Windows Installer keeps track of every file installed, and it's version and whether it's been updated or not, as well as a filehash. Replacing a file without using Windows Installer can result in unexpected demands for the original MSI file in order that Windows can restore the files to their original installed state. You might find that going to Programs&Features (or right-clicking the MSI file) and choosing repair will also restore them.
I have a Visual Studio installer that installs a Windows Service hosting a Web Service.
What I am trying to resolve is to give users during installation a choice of where a particular script is located on the box and once they have set the location to then update the location to the app.config file which the application can then use.
At the moment during install I have added a custom folder and added to that the folder the file. This all gets installed. I want to keep this as a default, but to be able to overwrite it with the users new choice.
I have added a user interface and a text box to capture the user's choice, and a installer class, but this is failing when I try it. Where it is failing is when it is try to find my App.Config file. It says that it cannot find it. In my code, I have written:
string path = Assembly.GetExecutingAssembly().Location;
So, to me my app.config has not been installed into this location when the installation is running at that moment in time.
So, can someone please advise how I can override and save the new location.
Thanks
What you're doing won't work for a number of reasons.
Custom actions in VS setup projects run after all the files have been installed, so it's too late to choose a folder where files can be installed. UI is supposed to be at the front where the normal wizard UI forms run, but VS setups don't support custom dialogs.
Installer classes with UI tend to do strange things because they are called from the execute sequence in the MSI, and the apartment threading won't work.
You're not running in an interactive user environment. Your installer class is being called from an msiexec process running with the system context. If you need to load files, name the path explicitly.
If you're going to stick with Visual Studio setups, your best bet is to install the script to a normal default location and have your app offer a way to copy it somewhere. Then the user can copy it somewhere new whenever they want and you're running in a normal user environment.
You can not get the directory full path where the MSI is being installed using,
string path = Assembly.GetExecutingAssembly().Location;
above code will probably return a path C:\Windows\System32 which has the msiexec.exe location which handles the MSI installation. Use the following code within installer class to get the installation path.
string installationPath = Context.Parameters["assemblypath"];
Rest of your questions are not clear.
Folks
Managed to resolve this myself.
I added an afterinstall event to the Installer class. In this event I added this line of code
string assembley = Assembly.GetExecutingAssembly().CodeBase;
UriBuilder uri = new UriBuilder(assembley);
string path = Uri.UnescapeDataString(uri.Path);
string directory = Path.GetDirectoryName(path);
To get the config file - I did this
Configuration config = ConfigurationManager.OpenExeConfiguration(Assembly.GetAssembly(typeof(ProjectInstaller)).Location);
This gives me what I want and it works
I recently took charge of a new system, it is a windows application written in C#, an installer (.MSI) file is created for its distribution. When I install the software it installs properly but it crashes on start. Then if I run the .exe file once for the application, the installed software starts working.
My observation is that .EXE installs some missing bit which is required by .MSI file. Is there a way I can find what files are missing in .MSI file ?
UPDATE on 09-08-2014:
I have found WER4A29.tmp.WERInternalMetadata.xml file which talks about System.Net.WebException
-<ProblemSignatures>
<EventType>CLR20r3</EventType>
<Parameter0>test.exe</Parameter0>
<Parameter1>1.0.3.33</Parameter1>
<Parameter2>53dca4f6</Parameter2>
<Parameter3>System</Parameter3>
<Parameter4>4.0.30319.18408</Parameter4>
<Parameter5>52311185</Parameter5>
<Parameter6>21b0</Parameter6>
<Parameter7>1fb</Parameter7>
<Parameter8>System.Net.WebException</Parameter8>
</ProblemSignatures>
First run an admin install via command line (cmd.exe) to extract the files from your MSI:
msiexec /a File.msi
Then inspect the extracted files to determine if there are configuration EXE files that perform configuration tasks. Determine what configuration files are there, if any. For example INI or XML files. Check for per user / user profile files.
In case you don't have the tool to view the MSI file, get hold of Orca or install a trial version of a commercial packaging tool. You will need this to see what is happening inside the MSI file. If you list the content of the Custom Action table there may be clues there as to what is going on. Also look in the Registry table for per user data to go into the registry. Debugging an MSI properly takes a lot of domain knowledge, but looking through it like this is useful too. Just post follow-up questions. I assume you have the Wix source code too?
To debug the application launch use Process Monitor (procmon.exe) to determine what is going on during the successful launch. The logging is a bit verbose, but with flags you will get to narrow it down.
- For native applications (Win32, or non-.net), I like to use Dependency Walker (depends.exe) too. It can be used for .NET too, but I find it less useful. I am not aware what the best dependency scanner for .NET is at the moment.
If manual debugging fails, several tools used for application repackaging are able to scan the system and determine the state before and after something is done and capture it as a list of differences. Advanced Installer's trial version should be able to do this. With some technical insight you should be able to identify what is needed from the diff image.
The .msi file is the installation set-up it include the installation script and the actual executable .exe file and other required dlls and configuration files.
I think the issue is with how the set-up is created. when you start the application after installation it is not performing the start up tasks like configuration of environment.
And the when you run the .exe it takes care of these configruations by it self.
I suggest that the testing of setup files .msi files and its generation scripts should be revisited.
I want to make an installer tracker.
If a execute file is a installer program, I will start a process to record the setup process. So I get a setup log after installing.
But How can I recognize an installer file. All installer files have ".exe" extenison. Is there a special metadata in the execute file to tell me it's a installer file.
I know word files have "author", "title" metadata. Maybe a installer file has a "install program" metadata. Anyone help me?
No; an installer is just an executable file (or a script, in case of MSI).
However, you can recognize it by what it does - take a snapshot of the system as it was before, perhaps hook the file and registry operations of the executable, and when it finishes, look at what it has changed.
For example, has it created a folder in Program Files? Has it created an uninstaller entry in the registry? Has it created any services? Etc.
When and MSI is installer/removed/repaired an "msiexec.exe" process will be started by the OS. So this could be another resource that you would want to watch.
As for the file/registry system you could use the OS monitoring API that listen to changes and gives you the desired information.
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
As per the title, I create a msi installer and then run it and it claims to have successfully installed and if I look in the control panel to add/remove program it appears there. However, when I look in the directory I specified, there is no change made to it. Nothing is copied into it.
When I run the installer and click the button to create a new directory and choose that new directory to install into, I get no errors. It all runs fine, but after exiting the installer, this new directory is not created.
I follow these steps to create my msi installer:
Open Visual Studio and open the project I wish to create installer for
File-> Add -> New Project -> Setup Wizard
Select "Create a setup for Windows Application"
Select "Primary output from (project)"
Add additional file -> path to txt file
Finish setup wizard
Look at Application Folder for setup
Right click primary output from (project)
Click outputs and verify it is correct
Build the setup project
This outputs the .msi file along with the .exe file. There is no problems/errors running either of these. It just doesn't install/copy the files.
Ok, so it was a privileges issue when double clicking the .msi file.
It would run fine and claim to install successfully but it didn't create folders/copy stuff in etc. It needed admin privileges to install.
So, to give it the privileges I edited the .vdproj file that created the .msi file (edited in notepad). I went to the MsiBootstrapper section and changed "RequiresElevation" = "11:FALSE" to "RequiresElevation" = "11:TRUE".
More information can be found here: http://msdn.microsoft.com/en-us/library/2kt85ked.aspx
I'm still not completely happy with this, it requires double clicking the .exe file which gives the UAC prompt to get the .msi file to run with the required privileges. It seems very easy for a user to just double click the .msi file and believe things to have installed...