my C# application built using Visual Studio 2010 had a deployment project which was being used to build an .MSI installer. Since we know we'll need to upgrade VS pretty soon and we know that later editions won't support the .vdproj, I've started to rebuild the installer using InstallShield.
Both the old and the new installers install the application in Program Files, but when I run the resulting executables the version created using InstallShield seems to start with a different current directory setting.
If I run the installed executable using our old installer (vdproj) and get it to output the current directory it returns:
C:\Program Files\MY_APPLICATION
...which makes sense since this is the folder in which the application is installed. But if I run the installed executable created by the InstallShield installer, the result of Directory.GetCurrentDirectory() is always:
C:\Documents and Settings\USERNAME
Now, I know I can just set the current directory on start-up, but I was wondering whether there was just some kind of setting in InstallShield I could use instead.
Many thanks in advance.
Related
I have pre-requisite software installer, xyz.msi which should be installed via main installer, pqr.msi. I use Visual Studio 2015 installer project to create pqr.msi installer.
I also need to check certain condition like whether xyz.msi is already installed on target machine or not.
I understand that I can add xyz.msi as assembly in pqr installer and set below property to conditionally copy the xyz.msi:
Condition
But, how to invoke the pre-requsite installer to get installed/launched first before main installer silently. Would this cause nested installation and fails? Any other better way?
The condition on the copy that you're referring to is literally just a condition on installing the file to the target system, a plain copy to (say) the Application Folder. It won't install the MSI any more than it will run some exe file you install.
You also cannot install the MSI from a custom action (that would be nested installation failure) so you need a way to install it before your own MSI. There are two choices that I know of:
The bootstrap manifest generator can be used to build a setup.exe that will install your the prerequisite MSI then your MSI. Start here:
https://msdn.microsoft.com/en-us/library/ms165429.aspx
Use WiX to generate a bundle where you mark the prerequistite MSI as a prerequisite for yours. You'd use MsiPackage to install your MSI.
http://wixtoolset.org/documentation/manual/v3/bundle/bundle_author_chain.html
http://wixtoolset.org/documentation/manual/v3/bundle/
Note that you're not building the MSIs with WiX, just the bootstrapper bundle.
If that prerequisite MSI is from a 3rd party then they may have alternative ways to install, such as merge modules you add to your own MSI build.
I have wrote a program HelloApp with Matlab and packaged it as .NET Assembly using deploytool as described here. As a result I have got helloapp.dll library, which I included into my Visual Studio 2015 as a reference, so I can run Matlab methods directly from C#. To run the code without Matlab installed, the end user needs Matlab Runtime (MCR) installed at least.
Now I want to create an installer for my C# program. I have came across Visual Studio 2015 Installer Projects which provides some tools to create program setup wizard. The problem is, I don't know how to include download and setup of MCR package as a step in installation process to ensure the user has all the required prerequisites in order for program to run.
Well this is not really an answer, but comment area in question was too short ...
I don't know much about VS2015 Installer as I personnally use innosetup. Anyway to check if runtime is installed on target machine you can look if following key exists in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\MathWorks\MATLAB Runtime\9.0
See my posts here and here for further details.
NB1: Note that installer for Matlab runtime is very large (about 1 GB). I would not package it with application to deploy, but just warn the user to install it separately.
NB2: I think Mathworks is packaging C:\Program Files\MATLAB\R2015b\toolbox\compiler\deploy\win64\InstallAgent.zip (~66MB) rather than MCRInstall.exe (~1GB) when deploying standalone installer with deploytool for downloading the runtime during install but I don't know how it works.
I am using Visual Studio 2013/ISLE to create a C# program with a .msi install image. When I run install from VS the program is installed in the expected location, e.g. c:/Program Files (x86)/...
I'm sure that this is something simple but I can't figure it out. A pointers would be greatly appreciated.
When you run a 32-bit installer in x 64-bit system Windows will always redirect your installer writing to c:\Program Files to c:\program files (x86). If you want to install to the non-x86 folder you will need to provide a 64-bit installer for your application.
This blog post explains why Windows does this.
It looks like InstallShield LE will allow you to write to the correct folder when your project is set to AnyCPU, but for more advanced scenario's you'll need to use the Pro version or the free Wix installer.
I assume the question is why the installation MSI fails when you run it outside of Visual Studio, but works when VS launches it?
If yes, you should first check if your ISLE project is creating an MSI or an EXE bootstrapper (that also contains the MSI). If an EXE is created this is what you should launch manually, not the MSI. In theory, a bootstrapper can act like an initialization support for the MSI and specify default values for certain properties, like an installation folder, etc...
I say in theory because I am not very familiar with ISLE, I work with other setup authoring tools, thus cannot say for sure if this stands for ISE projects too.
I'm developing an app that execute another app and I received this error:
the program can't start because MSVCR100.dll is missing from your
computer
with my C# app, can I fix this problem copying this .dll into windows/system32 folder?
Or exists another method to do this?
This links below point to the proper downloads for the MSVCRT100 installer. This is likely what you want your customers to run before installing your app. This will properly install the MSVCRT DLLs in the proper directory such that all applications can use it.
Microsoft Visual C++ 2010 Redistributable Package (x86) (probably what you need for 32-bit and 64-bit os)
Microsoft Visual C++ 2010 Redistributable Package (x64) (Only if your app itself is 64-bit)
If you actually want to install the MSVCRT100 DLLs through a merge module within your own MSI - you can link your MSI to the MSMs that are located in the x86 version your "c:\program files\common files\merge modules" directory" (Assuming you have Visual Studio 2010 installed).
C:\Program Files (x86)\Common Files\Merge Modules>dir *CRT*.msm
Volume in drive C has no label.
Volume Serial Number is 60A4-1718
Directory of C:\Program Files (x86)\Common Files\Merge Modules
04/22/2011 01:18 PM 584,192 Microsoft_VC100_CRT_x64.msm
04/22/2011 01:41 PM 571,904 Microsoft_VC100_CRT_x86.msm <-- This is likely the MSM you want if your app is 32-bit.
04/22/2011 01:14 PM 847,360 Microsoft_VC100_DebugCRT_x64.msm
04/22/2011 01:39 PM 801,792 Microsoft_VC100_DebugCRT_x86.msm
Two other alternatives:
Instead of copying MSVCRT100.dll into a system directory, copy it into the directory of the EXE app you are trying to launch that depends on this DLL. This isn't recommended, but won't run the risk of breaking other apps.
Another alternative. If you actually have the source code to the EXE that you are trying to launch, you can completely bypass all of this "install msvcrt100.dll" noise by just statically linking to it. In visual studio, it's the option in the project's propery dialog under C/C++ (under the Code Generation tab). Change "runtime library" from "Multi-threaded Dll" to just "Multi-threaded". This adds the /MT compiler switch.
Whatever program you're trying to start has to be properly installed first. Msvcr100.dll is one of the DLLs that need to be deployed for programs written in C or C++ with VS2010. It is simple with a Setup and Deployment project or by building the program with the /MT option. Contact the program owner for support.
what is missing is the Visual C++ runtime.
are you starting a C++ application from your C# code? if so, make sure the proper runtime is available on the client machines.
You should be able to fix this by copying it and registering it (with command line: regsvr32 "DLLNAME") or you can ship it with your executable and it should work
WARNING: Please consult the following article before including the file with your software... http://msdn.microsoft.com/en-us/library/ms235299.aspx
I take no responsibility for your actions
I "published" my C# solution in Visual Studio 2008 to C:\Deploy. When I run the setup.exe program, it installs my program to C:\Documents and Settings\Kevin\Start Menu\Programs\MyProgram
Is there any way, within Visual Studio, to set a custom install path? For instance, what if I wanted my program to install to C:\Program Files\MyProgram?
Publishing uses ClickOnce for deployment. ClickOnce has the advantage that it's easy to install and update, and doesn't require the user to have administrator privileges to install your application.
If you'd like a more traditional next-next-next-next-finish installer, which also allows the user to specify the target folder (and for you to set/force a default one), add a "Setup Project" to your solution by clicking File >> Add >> New Project..., in the tree select Other Project Types >> Setup and Deployment and double click Setup Project. When you build the setup project, it create an MSI file (Microsoft Installer setup file) and a bootstrapper EXE file (in case the user doesn't have Microsoft Installer or the required .NET Framework, which it then installs automatically).
ClickOnce ("published") applications are installed per user in the user application cache location. There is no way you can change this location ;-)
You have to use your own setup packaging tool in order to choose or let the user choose the location. Or you can just distribute your application as a zipped executable, if no installation routine has to be called, liked registering file types or adding keys to the registry.