I have made a VS2010 project which installs MySQL by calling MySQLInstallerConsole.exe with necessary arguments. This works perfectly however, when I try to run this project's exe as a custom action it executes the exe but MySQL is not installed.
I checked the log file for MySQL exe and it had the following error:
Error 50: Package Name State change request failed.
What does this really mean, any solutions?
There are at least a couple of things that have something to do with this:
I believe the MySQL installer is an MSI file according to this:
http://dev.mysql.com/downloads/installer
You cannot install an MSI from a custom action of a Visual Studio setup because recursive calls to MSI installs are not allowed.
In a Everyone install custom actions run with the SYSTEM account, and installs are not often expecting this if they want to install files in user-profile folders because the SYSTEM account doesn't have any.
You need to bootstrap this somehow, and I think people are often using the WiX Burn bootstrapper for that. You define the ProductCode, name etc of the product and define how to install it.
Related
One of my Open Source projects uses Packages to build the macOS installer. After GUI-based setup of the pckgproject file, the installer build can be easially invoked from the command line through the packagesbuild command.
I'm now setting up a GitHub Actions based build workflow, running on the GitHub-hosted runners, which should ideally create a ready-to-use installer, so I need to invoke packagesbuild during that process. Unfortunately packagesbuild is not available on the macos-10.15 runner used. I don't see any option to install it during the workflow run, as it's not available through e.g. homebrew but maybe I'm overlooking something. Is there any option I'm overlooking beneath rebuilding my installer and switching to pkgbuild?
I have a solution that is primarily developed in Visual Studio 2012. I would like to develop in MonoDevelop without major incompatibilities.
Thus far, I have installed mrward's nuget addin for MonoDevelop and things work if I manually add each package in packages.config through that interface. However, this is highly onerous. This addin doesn't have support for automated package restore as of this writing.
I downloaded nuget.exe from CodePlex ("NuGet command line utility", as it's labeled). I use a simple find/xargs combination to install all required packages:
find . -name packages.config | xargs -I '{}' mono nuget.exe install '{}'
This creates several dozen directories in the directory from which it is run instead of putting things under packages/ as expected, and it also doesn't touch the project files so MonoDevelop still thinks that it should be looking for package references in the directory from which MonoDevelop was started.
I therefore opened MonoDevelop from the working directory that contains all of these package folders, and I still get invalid references. I think this is probably because the project is looking for package_name/ reference, but the folders are name package_name.version/ in the working directory.
Any suggestions for a sane, simple way to interact with this solution? I'm next going to try modifying my shell command so that it automatically drops to project/packages and runs nuget from that directory.
Did you try using the -o command line parameter with NuGet.exe? You can use that to get the packages to install into a particular packages folder.
The NuGet addin for MonoDevelop supports package restore from version 0.6 or above. Right click your project and select Restore Packages. This will download all the packages defined in your packages.config for all projects in the solution. It uses NuGet.exe to do this.
Another way to get this working is to use the custom NuGet MSBuild target so the package restore happens at build time when using xbuild. It would require some manual editing of project files though. Under the covers the custom MSBuild target just uses NuGet.exe with a similar command line to what you have already just with the output directory option specified. So I would try the command line approach since that will be less work.
You would have to get the following files from the NuGet repository on codeplex:
NuGet.exe
NuGet.targets
NuGet.config
Put these in a directory somewhere. Typically these are put in a .nuget directory in the same directory as your solution file. Then you need to edit your project files to include the NuGet.targets file and also define the SolutionDir property. So something like this:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\</SolutionDir>
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" />
You will also need to enable package restore on your machine. You can do this using the NuGet addin for MonoDevelop in the Options dialog. Under Linux this is available from the Edit menu under Preferences. Then look in the NuGet - General options and there is a checkbox for enabling package restore.
There is an example project on GitHub created by Jonathan Channon which uses package restore and works when building with xbuild inside MonoDevelop. There is also an issue on GitHub about using NuGet restore on Linux which might be helpful.
Update: 2014-05-14: NuGet addin for MonoDevelop now supports package restore.
I'm following the instructions from here to build MonoDevelop on Mac OS X: Building MonoDevelop on OS X
I can build MonoDevelop just fine. I'd like to also build the MonoMac add in and use it.
The document says:
"To include addins from extras, manually copy their build directories
into the MonoDevelop.app directory, e.g.
cp -r ../../../extras/MonoDevelop.AspNet.Mvc/build/*
MonoDevelop.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.AspNet.Mvc/"
However, I have no build directory under /extras/MonoDevelop.MonoMac.
I tried to follow this step to build extras:
"To include additional addins from extras in the build, instead of
using the Mac profile, use configure --select to select addins. This
will write the default profile. Next, replace the line in
profiles/default that begins with "main" with the one from
profiles/mac, then run configure again using the default profile."
But it does not give me the option to build the MonoMac extra.
Next, I try to compile the monodevelop.mdw. Again, I can build the main solution (MonoDevelop), but the extras fails with over 1000 errors.
Finally, I tried to take my existing monomac and macdev plugins and copy them into my master monodevelop.app bundle. But this breaks add solution/project dialog whenever I try to select a MonoMac project - it fails to load the Monodevelop.ide DLL.
Any advice on where I am going wrong would be appreciated.
I was not able to make this work following the directions on the MonoDevelop site. Even manually adding the extras/MonoDevelop.MonoMac extra to the profile did not work.
In the end, I build MonoDevelop from source, using the mac profile.
Then I got the latest MonoMac pieces, and build them from source. I used
make update
to install into my installed copy of MonoDevelop.
Then, I manually copied the following packages from my installed MonoDevelop to my newly compiled version from master:
MacPlatform.dll
MonoDevelop.iPhone
MonoDevelop.MacDev
MonoDevelop.MonoMac
Xamarin.Ide
Any everything now works :)
I can't figure it out: do the files which are referenced in the Binary element of .wxs file get copied to the target machine, or are they resources of the install package?
They are definitely the resources of the install package. This means that they don't get installed to your application folder, but Windows Installer is supposed to extract it internally to some temporary location to address the functionality in it. And it is supposed to clean after itself. But this is definitely not visible to the end users of your installation.
At least, this is how I understand it.
I'm creating installer using InstallShield 2010 (basic MSI) that is having two features.
First feature consists of:
main .NET application compiled as x86,
some native x86 third party dlls which are used by main application (x64 versions are unavailable).
Second feature contains single component which is an extension for MS Reporting Services compiled as AnyCPU.
During UI sequence I'm using InstallScript custom action to enumerate all available Reporting Services instances from both x86 and x64 registry trees.
The user is prompted to select on which instance he wants to deploy our extension.
Based on selected instance I'm quering registry for actual location of Reporting Services in file system which is usually something like "C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services" and storing this value in a MSI Property.
Then by using Set Directory action I'm setting destination directory of a component (our extension) to the value of that MSI Property.
Everything is installing perfectly fine unless you've trying to install it for x64 Reporting Services in that case extension files are installed to wrong location. Even thou MSI Property is set to correct path "C:\Program Files\MicroSoft..." (I've checked msi log) it looks like system is automatically redirecting to "Program Files (x86)".
Is there any possible solution to overcome this issue?
If you need to install to the 64-bit ProgramFiles folder, use a 64-bit MSI.
Finally solved this issue myself without creating 64bit MSI by using InstallScript custom actions.
First custom action to install:
Manually copy required files to desired location (InstallScript can access x64 Program Files)
Save this location in registry as a key component for this feature to use during uninstall
Second custom action to uninstall:
Read installed location from registry (do not use System Search to get this value due to it'll be auto translated by WindowsInstaller to "ProgramFiles (x86)")
Delete files
You can change the INSTALLDIR property to ProgramFile64 rather then ProgramFiles, this will help you to install on desired path, since you application is 32-bit so the path will be C:\ProgramFiles(x86)\Your Company Name\Your Product Name along with this have you made your components as 64-bit compatible?