I'm trying my best to produce a foolproof installation methode for my programm.
I'm having the problem, that, eventhough it should be properly configured by me, my produced setup files won't produce any registry keys.
My Files are configured like this:
And my registry editing is looking like this:
I tried running the setup as an admin, but the keys just aren't created..
Solution:
Go to the properties of your setup project and set the TargetPlatform to x86.
To set up the reg keys the right way you may try it like this:
Related
We have a couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
I am making an installer where I have defined my own installer property. I want to store this property in the registry. As this property is only needed by the installer, I thought that the best location to store it would be:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PRODUCT CODE}.
I use Installshield 2010 to make the installer.
What I want to know is: Is this possible and how can I do this?
Yes, this is possible. The registry values are formatted, so you can use something like this:
[MY_PROPERTY]
The location you chose is not very good. That key is used by Windows and Windows Installer internally. You can try creating your own key under SOFTWARE, for example:
HKEY_LOCAL_MACHINE\SOFTWARE\My Company\My Application
In Expression Blend 4, while compiling I get an error saying
The specified solution configuration “Debug|BNB” is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform=”Any CPU”) or leave those properties blank to use the default solution configuration.
Done building project “myproject.sln” — FAILED.
Build failed.
Background: At build-time the compiler (no matter if started from Expression Blend or Visual Studio) has to know what the target platform of your code, i.e. the system architecture like X86, 64bit etc.
The problem now is, that a system wide setting of an environment variable called "Platform" seems to override any setting of what Expression Blend uses as target platform, too.
I found some workarounds on other websites and will provide the possible solutions here. Trying one of the two suggestions should help:
Delete the conflicting environment variable "Platform" in "Control Panel -- System -- Advanced -- Environment Variables". Restart Blend and give it a try (maybe you have to restart your computer to make this work).
If this does not help: With the registry editor (Start -- Run -- "Regedit.exe") go to key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and selected the key Platform. Delete the value BNB. If you do not find the specified key, try repacing "CurrentControlSet" with "ControlSet001", this worked for in one case, too. Then restart your computer.
Please give a comment which of the solutions worked.
I just removed the Platform from Environment variables and it worked.
With Microsoft Visual Studio the following solution should work without restarting your computer. Run the command line (Windows Key + R, type cmd, hit enter) and type the respective commands for your project:
MSVC 2013:
SET MSBUILD="C:\Program Files Path\MSBuild\12.0\Bin\msbuild.exe"
MSVC 2015:
SET MSBUILD="C:\Program Files Path\MSBuild\14.0\Bin\msbuild.exe"
SET SOLUTION="your solution name.sln"
SET PROJECT="your target project name"
SET MS_PLAT="target platform"
; this could be x64 for 64 bit applications or Win32 for 32 bit applications
%MSBUILD% %SOLUTION% /t:%PROJECT% /p:Platform=%MS_PLAT%
For me, PLATFORM = BWS. Running the above script once fixed the problem permanently for my projects, without modifying or deleting PLATFORM.
If still not work try to specify configuration and platform
for example
msbuild testproject.sln /p:Configuration=Debug /p:Platform="Any CPU"
This works for me.
Is Visual Studio's Setup Wizard project able to only deploy some of the files only if it finds a certain key into the registry (a) ? If not, then maybe launch another installer file when that certain reg key is present (b) ?
(a) I have been trying to deploy a winamp plugin through VS's .msi files. 2 problems:
the path to {winamp}/plugins folder has to be obtained automatically
on failure, user should be presented with a dialog to choose where to install the plugin to
(b) In an attempt to overcome (a) the NSIS installer was used for only packaging the winamp .dll plugin; however, this introduced another issue:
if user does not have winamp installed, the NSIS generated sub-installer must be manually canceled, and this invariably causes the main VS generated installer to fail (while it shoud not, winamp is not an essential part of the good functionning of the whole app I am deploying)
I have failed in 2 ways to conditionally launch the sub-installer on a certain reg key detection (tried to look for the ProgID key of Winamp). First failure was because the ProgID key is not found even on machines that do have winamp installed (manually checked for the key, it was there), and second failure was due to the fat that such conditional launch could not be applied to just the sub-installer, but to the main installer only.
I am thinking of dumping the VS project wizard altogether and just move to NSIS installer wizard.. but I would not want to learn to script it for deploying each component of my solution. Any GUI version for it ? Or should I start learning Orca and use it on the VSPW's output .msi file ? Or what ?
Thanks
If you want to use a MSI the approach is this:
- create a search for the registry entry
- use the search result (it's stored in an installer property) to condition the components of your files
- use the same result to condition the installation folder dialog
This can easily be done in commercial setup tools. But if you want a free solution, Sandeep is right, Wix is very good.
I have created a deployment project using VS 2005. By default, files are installed in AppDataFolder. There are also 2 string values added to the registry during the installation. These registry values represent the path to some dll files found in the install dir.
When the user chooses the default installation directory everything works fine. But if the user choose another directory, instead of having the registry values with the user selected directory, I still get the default values.
How can I change that? Is it possible to do it during the deployment project creation?
Thanks,
Olivier.
Use reg.exe from command line.
You could call that exe from your program and provide the correct parameters.
reg.exe is included since Windows XP.
So instead of using the [AppDataFolder] property, I should have used [TARGETDIR]