How to add msxml6.msi as nested package into my vs 2005 setup (Based.msi) using Orca? I already used this instructions http://support.microsoft.com/kb/306439 , but msxml6.msi installation never started.
Nested installations are deprecated. You should either use a prerequisite, or a custom action.
Here is a small prerequisite tutorial for Visual Studio 2005: http://www.codeproject.com/KB/dotnet/Prerequisites_in_Setup.aspx
You can try using the bootstrapper manifest generator to configure your prerequisite.
If you want to use a custom action, you can either try launching msiexec.exe with the appropriate command line or write custom code which launches the MSI.
This custom action should be executed after InstallFinalize in InstallExecuteSequence table. It should also use the msidbCustomActionTypeAsync and msidbCustomActionTypeContinue flags.
Related
I have a redistributable msi my program needs to be able to run. So far I've created a launch condition. The condition it uses is under "Search Target Machine". This needs a component ID.
This page suggests I can only determine the component ID via MSI Spy, a tool that as far as I can tell is no longer available: https://msdn.microsoft.com/en-us/library/1s08hzfe(v=vs.80).aspx
I must use a Visual Studio Setup Project, and I must distribute the 64 bit end user runtime of slimdx from http://slimdx.org/download.php.
How can I successfully get a component ID, or alternately how can I bundle an msi as a prerequisite?
MSI Spy seems an odd choice! The "standard" tool for looking in MSI files is Orca, supplied in the Windows SDK/Kit, install from Orca.msi. There are others if you search.
Look in that MSI and go to the Component table, look for a component id that is always installed (if that can be determined) and use that guid.
Ths might help with the custom prereqs:
Adding Custom prerequsites to visual studio setup project
and support for custom prerequisites in setup projects has never bneen particularly good, even when the Bootstrap Manifest Generator was around.
This might be useful if you can figure out how to alter the manifest file to add your custom prerequisite, which is what the BMG tool did.
How to install redistributable with visual studio setup?
We are migrating our applications from 32 bit to 64 bit. And also .net framework 3.5 to 4.0.+Visual Studio 2008 to Visual Studio 2010
Aspart of migration we created all msi's in 64 bit with visul studio 2010. we had a problem while installing them.
we are getting System.BadImage error for the msi's which are having some customaction condigured in depolyment project. Due to this error installation rolled backed.
Root Casue Identified:
For doing customaction we have projects with installer classes While installing those using msi we caught that error.
When ever we get that error.We just tried installing that .exe manually using 64 bit visual studio commandLine with installUtil.exe command. it successfully installed.
But when we are using 32 bit visual studio commandLine with installUtil.exe, we end up with the same error.
So problem is when ever we are using msi its picking the 32 bit installUtil.exe eventough the msi is 64 bit which is causing the problem.
Tried Solutions:
1.Tried debugging the installer class using Debugger.Launch(). But before hitting the point we end up with error.
2.Try to edit the Database table of msi with orca editor to pick the correct version of installUtil.exe. But failed with other error.
Question:
1.How can we modify our solutions to pick the 64 bit installUtil.exe?(if we can do this)
Rule #1: Don't reinvent the wheel. Avoid CA's wherever possible.(See PhilDW's answer)
Rule #2: When you really must use a managed custom action don't use InstallUtil. Use Windows Installer XML (WiX) Deployment Tools Foundation (DTF) instead.
Rule #3: Write custom actions that follow MSI's transactional model (Install, Rollback, Commit) whenever possible.
Rule #4: Write data driven, declarative (custom tables) custom actions whenever possible.
Rule #5: Honor the security model of MSI ( custom actions that change data must be deferred in the system context )
Rule #6: Test the !#Q%Q! out of your CA's. Make sure that install, uninstall, reinstall, cancel (rollback ) and upgrade (and upgrade rollback), repair and silent installs all work as expected. Hint: Rule #1 exists because you get this for free when you don't write custom actions.
Reference:
Deployment Tools Foundation (DTF) Managed Custom Actions
This might be the issue:
http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
You don't need installer classes. Visual Studio setups to generate MSI files are not in newer versions of VS, so you should use a tool that uses the standard methods of installing services, ServiceInstall and ServiceControl being the underlying tables in the MSI file.
I'm trying to figure out how to get a single-file generator installed on VS2010. Previously I got it sort-of working on VS2013 after many hours of head-banging; in both cases the primary difficulty is setting up the registry entries. Apparently VSIX files don't allow registry settings:
You can use the VSIX format to package project and item templates,
Visual Studio Integration Packages, Managed Extensibility Framework
(MEF) components, toolbox controls, assemblies, and custom types. The
VSIX format uses strictly file-based deployment and does not support
writing to the Global Assembly Cache (GAC), or to the system registry.
VSIX is the preferred deployment method for the extension types that
it supports.
My VS2013 solution involves the CodeGeneratorRegistrationAttribute and ComVisible(true) on the assembly, but after install, the extension doesn't work until the user runs devenv.exe /setup in Administrator mode. In VS2010, CodeGeneratorRegistrationAttribute does not exist in any of the SDK DLLs and simply adding the source code of CodeGeneratorRegistrationAttribute.cs to the project (as the Single File Generator sample does) doesn't seem to work (and I don't understand why the sample seems to expect it to work; .NET doesn't use structural typing, after all, so how could this attribute possibly have any effect?)
If a VSIX cannot add registry settings directly, I think a reasonable substitute is to include some code that automatically runs on VS startup. That code could find out the path of the registry hive of the running VS version and add the necessary registry settings at that time. So I have three questions:
How can I cause a method written by me, inside my extension, to run when VS starts?
How can I get the path of the current VS registry hive?
Is there any other way to add the registry information?
Eventually I gave up on making a VSIX to hold my single-file generator. I made a CodeProject article about what I did instead.
But back when I was still trying to make a VSIX file, this blog post came in handy.
What is wrong with MSI-deployment? You can do anything from there. WiX has option to install VSIX packages pretty simply, just use the embedded element <VSIXPackage>. It also offers you to create new registry keys + you get registry key unistall for free. Note that you can elevate privileges, if needed.
does your vsix have a class that extends Package?
Add code in your Package's Initialize method that runs when your package is initialized.
To get to VS based registry stuff, see Microsoft.VisualStudio.Shell.VSRegistry
I am useing InstallShield Limited Edition for Visual Studio 2010 to create an installer, and I am trying to add an executable custom action.
My custom action in an exe that is installed to the install dir.
The custom action needs to use another file that is located in the install dir as well.
How do I get the path to the install dir to my exe? I tried to pess [INSTALLDIR] as an argument but it translates to "C:\Program" instead of the correct dir ("C:\Progam Files\MyCompany\MyProduct"). I tried [TARGETDIR] but it translate to E:\ (wrong as well).
Any Ideas?
Found the problem.
using [INSTALLDIR] is currect. the problem is with powershell. reading C:\Program Files...
as C:\Program.
the Issue is discussed here:
http://www.leeholmes.com/blog/2006/05/05/running-powershell-scripts-from-cmd-exe/
EXE custom actions are very limited. If I was using InstallShield LE, I'd create a C# WiX/DTF Custom Action and consume it in a WiX Merge Module and then consume that merge module in your InstallShield LE project. This gives you very powerful solution.
I have come to see an Installer class item in Visual studio. Why they have maintain an seperate item for Installer. Do they create any custom installers ?
The Installer class can be used to configure items such as performance counters and message queues as part of the installation of your code. They can be included with any assembly and the most basic way to install components related to an assembly is to use InstallUtil yourassembly.dll which would contain your code and custom installers. It is good practice to provide an uninstall option for anything added in this manner.
See here fore more information http://msdn.microsoft.com/en-us/library/z3xc61bs(VS.80).aspx
I also use them to override behavior in the base installer class, such that I can run validations based on input in the MSI wizard, create files and folders, etc.
For Windows Services, I think they are required.
One thing I use an installer class is for NGEN (native images) which speed up startup. The installer class calls NGEN.exe to put it in the native images.
http://dotnetperls.com/Content/NGEN-Installer-Class.aspx