My problem is this: I am getting a TFS build failure that I have tracked back to what appears to be a missing Registry key under SOFTWARE\Microsoft\VisualStudio\9.0Exp.
This machine had the VS SDK 1.1 installed via a command line: msiexec vsski.msi
So, I am guessing that I need to pass some properties to the msiexec to tell it that it should install some component which isn’t getting installed by default – is this correct? If so, can anyone point me to the correct property?
msiexec vssdk.msi WHATPROPERTY=”I want to control the which components are installed”
Or am I off track here?
Okay, I found the answer and I was a little off track.
More background: The error occurred in the VsTemplatePathsTarget of the Microsoft.VsSDK.targets file while calling the custom task VsTemplatePaths. A little reflector (great tool!) told me that it is trying to find the registry key above.
When I tracked it more closely I discovered that the key was not present under HKLM, but was under HKCU, but reflector and some trace messages said it was using HKCU. More precisely, the key in question is present under my account in HKEY_USERs, but not the account the TFS build runs under.
It turns out, my automated install sequence was such that the build account was created after the VS SDK was installed, thus when it configured the registry settings it only did so for existing users and not the default user.
Related
When i try to start one application (for instance application A.exe) error was throwing from already installed msi file (for Ex: B.msi) as "The feature you are trying to use is on a network resource that is unavailable or enter an alternate path to a folder containing the installation package 'B.msi'"
I have read some articles related to this error but all of them explaining if installer have any issues (if file have been damaged, deleted, moved, or quarantined by an anti-virus application) this error will occur but here when I try to launch one application then it is showing above mentioned error with another package name (B.msi) which I already installed.
Please let me know the cause of this issue it would be helpful to trace out this issue.
Note: For older version of our application don't have this issue (For creating installer earlier we have used Wise tool now using WIX tool. Is there any issue with WIX installer?).
Self-Repair Problems: This is generally a self-repair issue. I have written more times about this than I care to count, I'll see if I can send you here: MSI self-repair - the scourge of society.
Explanation: What is actually happening is that your installation goes through an integrity check when launced via an advertised shortcut, and a resource is found to be missing. The MSI will then try to repair itself (self-repair), but it is unable to find the required source files to retrieve the file it needs to reinstall - since the source files are no longer available at the location where you installed from. It is a good idea to install from a permanently available network location using administrative installations - especially for corporations.
Missing Source Files Resolution: In your case - to sort out the missing source files - you can either uninstall and reinstall (uninstall should not need source access in normal cases), and then preserve the installation files at a permanently available location (solving the problem for the future), or you can browse to the installation source when you are prompted to do so for your current installation (and there are some ways to automate setting new source paths). The installation source must be the one used to install the software originally (unless you know how to hack it, which is very involved).
Self-Repair Resolution: To sort out the actual self-repair conflict, you essentially need to find the culprit component causing the repair in the event viewer and then find some way to resolve the situation. All linked or explained in the above answer (repeated here). Proposed "real-world solutions" can be found in section 5 here: What do I do when launching an application triggers repeating, endless Windows Installer self-repair? As a workaround, you might want to try to launch the EXE files in question directly, to verify that the self-repair does not happen (generally this will prevent the self-repair, but it can still happen if there is a COM conflict or some other advanced conflict).
You can see a list of "Primary Cause of Self-Repair" some way down in this answer: How can I determine what causes repeated Windows Installer self-repair? (bad MSI packages with conflicting resources - COM conflicts?, security software quarantining files unexpectedly, cleanup scripts wrecking havoc, etc...). I would recommend you skim this list for ideas.
Uninstall Problems: This "installation source not found" problem can also occur so it prevents uninstall in special cases. Here is an answer which tries to summarize aspects of this problem: Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012" (somewhat too elaborate, but worth skimming I think).
Some Links (for reference and easy retrieval):
Installshield 2013 Installscript MSI: Wrong .msi location during Repair
Wix / MSI : Unable to uninstall
Uninstall without an MSI file
We have a legacy software installation that we're trying to remove from our organisation. We have different versions and are trying to create a universal uninstaller for all versions. We've come across a particular release that doesn't seem to be able to be uninstalled via command line though. And it's proving difficult to create a workaround.
I've found the GUID of the application in the registry via
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
And the command I run is:
msiexec /x {080FDF44-6D15-4D2E-977E-74D5168198E7}
I get an application prompt asking me if I want to uninstall the product, so I click 'Yes'. And then it looks like it's starting but never actually does anything. So I dug round the registry and found another GUID in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Userdata\S-1-5-18\Products\44FDF08051D6E2D479E7475D6118897E
If I run the same command as above with the different GUID, I get the application confirmation box asking for uninstall then after clicking OK, I get an error saying:
The installation package could not be opened. Verify the package exists and you can access it.......
I've been into C:\Windows\Installer into the folder with the above GUID and all that is in there is an icon and an *.mst file. In the root of C:\Windows\Installer, there is an *.msi called the same product in the details but with another version ID of:
8A2C4F93-4B31-4474-B9F2-2E51BF5D71A8
If I run the msiexec against that ID then I get a confirmation box again then another error which says
The action is only valid for products that are currently installed.
If I run the uninstaller, it uninstalls fine from the programs and features and uses the generated *.msi for the uninstalled (e.g. C:\Windows\Installer\241a6.msi and matches the product ID of 8A2C4F93-4B31-4474-B9F2-2E51BF5D71A8). This will change form machine to machine. Any other ideas on how to get this off in a neat and managed way?
You can't dredge the registry for ProductCode guids because they are obfuscated. If you don't really know the ProductCode, then look at ways of enumerating installed products. For example, the direct C++ way is MsiEnumerateProducts, and C# pinvoke equivalents, something like this:
MSI Interop using MSIEnumRelatedProducts and MSIGetProductInfo
Then you will get the actual ProductCode and can get other info with it.
If sometimes it doesn't work when you are absolutely sure of the ProductCode, then it was perhaps installed in a per user context that's different from the one you're running the program with.
Also, for MSI-installed products Windows doesn't use the uninstall string, it just uses the ProductCode directly. Again, registry dredging is not the right thing when there are actual APIs specifically to enumerate installed MSI products.
If an uninstall requires access to the original MSI that it was installed from, then there are at least two reasons:
The MSI has an unconditional ResolveSource action that forces it to ask for the oroginal MSI file.
The cached version of the MSI file has been removed from C:\windows\installer.
When I go to debug our app I get the following error message
Microsoft Visual Studio
Unable to activate Windows Store app 'xxxx'. The activation request
failed with error 'This app's package family has more than one package
installed. This is not supported'. See help for advice on
troubleshooting the issue.
OK Help
When I dig out the event log I found this error.
The app xxx App's package family (xxxx) has more than one package installed. This is not supported, so the app was not activated for the Windows.Launch contract.
In order to find out what other packages are installed I run the following PS script:
Get-AppxPackage -all
Looking at the output from the previous script I only see the one package that is installed from the visual studio location. I uninstalled the app from the start menu and run the script again and there is nothing installed.
The app is signed so I can’t change the package family name.
I have followed the steps in https://stackoverflow.com/a/14340075/127067 and I still can’t run our app from VS or from the installed package.
How do I find the other errant package family name? Dig through the registry?
What are some steps I can follow in order to run the app again?
Hard to guess how you did that. Double-click the Package.appxmanifest file in your project. Select the Packing tab, you'll see the Package family name for your app. It is made up from the package name, a guid, and a hash of your publisher name. The guid is supposed to make it unique, make sure you didn't change it.
Installed Store apps are recorded in the HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\Repository\Families registry key. Compare the entries with yours, a match will be a problem. Do try to get it uninstalled as normal before you start hacking the keys.
I also faced the same problem while I am developing a Windows App and trying to debug the same on my development machine.
So from the error message itself, it's clear that there is already an app installed on your app and installer cannot continue further because of that.
And above post, you get an idea what is happening inside our system and installer.
First time fixed the same problem with registry cleaning and clearing the registry entry for that particular app. You need to more mindful while doing the same.
But the second time, I face the problem again.
The actual question is why this is happening, at least on my machine.
When we try to create an app package (Project->Store->Create App Packages), we may change the package Version. This is the place where we are somehow creating that error.
Let's say I have already app installed on my machine from debugger with Version 1.0.0.1 and the second time we creating the app with version 1.0.0.2. Now, after creating an app we launch Windows App Certification Kit tool for verification of our app and it will fail (in my case). And if I want to debug the Windows app, it will show above error.
To solve this problem, what I did was, created the app package with the same version which is already installed on my machine and then tried to launch the debugger and that worked.
So this is my solution for this error. There may be some other way to solve this problem other than this and above mentioned solution.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I have a problem which I guessed would be really simple to solve... but duh.
I'm deploying a .NET application with VS2010. I have a C# Windows Forms project and a Deployment Project. I need the installer to run with admin privileges because the app is installed for all users and an entry to the registry is made.
When starting the setup.exe I'm not prompted for privilege elevation. The installer will just start and suggest to install to Program Files (x86) which is good. After clicking next the installer runs and finished with a success message. Which is basically a lie because it did not successfully install. Instead it puts the apps exe directly to C:\.
How can I make the installer ask for admin privileges. Or do I have to rely on my customer to right click the setup and select "Run as Admin" which is very error prone?
Clarifications about my setup:
In the File System view of the setup project I added (among other things) "Primary Output from project01 (Active)" and "Build Outputs from project01 (Active) to "Application Folder". I also added a shortcut to "Primary Output" into "User's Programs Menu\CompanyName\ProgramName".
In the Registry View I added an entry to HKEY_CLASSES_ROOT because I need to register an url handler.
I also modified the setup's settings: I set InstallAllUsers to True because it is supposed to do so.
When I build and start the setup.exe by double clicking (or by selecting Install from the project's context menu) I always get the same result: The installer runs without asking for admin privileges, ask for an install location (which I leave at the default C:\Program Files(x86)\Company\ProgramName) and then procedes after clicking Next. As a result, the exe is put directly in C:\ and the shortcut created of course points into Nirvana.
If I run the setup.exe manually as Administrator things work fine. But this cannot seriously be the way to go.
So how can I tell the setup to always run as Admin?
I think this is a perfectly valid question, is a real problem, and has an actual explanation.
I recently ran across this problem. In my case, the cause is that the AlwaysInstallElevated policy was set on the computer through GPO. The policy was set to 1 in the per-machine policy and 0 in the per-user policy. These policies can be manually set to reproduce the effect it has on MSI installers
Using msexec /log install.log /i Deploy.msi, I had a setup log and there were strings in it like this:
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property TARGETDIR
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETURLMSG
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETMSG
It seems that Visual Studio does not set the SecureCustomProperties in the MSI correctly and post processing of some sort is needed. I think that moving to WiX may be a better long term solution instead.
A blog post on MSDN is what I found that helped me find the root cause to this problem.
I've come across the same issue as you, and have found a good enough solution for it. So it might work for you too. The solution is documented here:
VS2010 Setup Project - Run As Administrator
I will re-iterate the solution briefly here. Basically, you need to manually edit the setup project file (.vdproj) and the following property to TRUE:
"MsiBootstrapper"
{
...
"RequiresElevation" = "11:TRUE"
}
When starting the setup.exe I'm not prompted for privilege elevation.
This is the normal behavior. The boostrapper doesn't need elevation.
Which is basically a lie because it did not successfully install.
Instead it puts the apps exe directly to C:.
So it did install your application, but in the wrong location. This is not related to elevation. In the File System editor in your setup project where did you add your application files? Did you add them in "Application Folder"?
How can I make the installer ask for admin privileges.
A MSI package installed for all users automatically prompts for elevation when clicking Install button. If it doesn't elevate automatically and installs in a per-machine location (like C:), the installation fails and nothing is copied on the target machine.