I have two MSIs created using MS Visual Studio 2010.
Both MSIs created using same codebase, however, different Product Code and Upgrade Code.
Problem is once I uninstall the first application and try to open the second application from the shortcut exist in the start menu, it start the re-installation process.
Furthermore, If I check the actual installation folder of the second application in Program Files, all binaries exist and if I click on the Main Application EXE from there, it opens the second application without any issue.
Concern here is how to avoid re-installation process of the second application when I click on the shortcut exist in the start menu after un-installing the first application? Whats the relationship?
It's almost certainly not a re-installation process - it's a repair. There should be some MSIInstaller Application Event Log entries that say what appears to be missing. Perhaps there are some common files between the two separate MSI setups? If so, it seems that they are not shared properly. When you uninstalled that first product it removed something that is in use by the second product, so when you used a shortcut is repaired it. It doesn't need to be a file overlap - it could be a registry entry.
Related
I created a Visual Studio MSI Project that runs an custom EXE (which is good). In this exe, there is some code to add additional registry changes to add entries into Internet Options (mainly Local Intranet and Trusted Sites under Security). When the exe is run by itself (and in the debugger), it executes as expected (and puts the correct registry entries in their correct location). However, when the MSI executes the exe file, this part gets ignored even though it runs (I've added Console.Writelines everywhere).
I've been beating my head over this for 2 days and if anyone has had experience with this, a correct direction would be great.
I am using Visual Studio 2013.
Shelling out to an EXE from an MSI is not considered "good". As I recall, one of the many limitation of Visual Studio Deployment Projects (.VDPROJ) is that custom actions are scheduled with impersonation. If the MSI is being invoked from a standard user context UAC elevation won't help because the standard user context is impersonated.
If you want a reliable, best practices based installer, you should use the Registry table. Of course the problem there is another one of the annoying limitations of VDPROJ is that every registry value is a key file of it's own component and you quickly get into self repair hell.
I'd really suggest starting over with another toolset. I can think of several good ones.
I didn't realize that there is a "Registry On Target Machine" option inside of the MSI builder for Visual Studio. All I had to do is right click the project > view> Registry.
There I just had to map out the values in the right places.
Thank you for everyone who answered.
I am using the Visual Studio 2010 setup to create an installer for my application. From the File system Editor i have selected one of the two primary output files that have been created in my solution. I have right clicked and created a shortcut for my executable. I have dragged and droped the shortcut into the User's Program Menu. I build the installer and everything completes successfully. I run the installer and everything runs successfully. Now i proceed to double click on the shortcut and the installer re-runs and fails!!!. I have checked the shortcut and it is different from the one i have manually created to compare. The Target is greyed out. Any help would be greatly appreciated!!!
When launching an application through an advertised shortcut, Windows Installer verifies if the application resources are intact. If one or more resources are missing, Windows Installer reinstalls them automatically using the cached MSI. This is why the second installation is performed.
Shortcuts created in Visual Studio are advertised, so a repair is triggered if some of your installed files are missing.
To determine what triggers the repair you can try this:
after receiving a “preparing to install” message open Event Viewer (you can search it in the Start menu or launch “eventvwr.msc”)
go to “Windows Logs” -> “Application”
look for “MsiInstaller” information messages which have this form:
Event Type: Warning
Event Source: MsiInstaller
Event ID: 1001
Description: Detection of product '{1F7D16F0-836D-4CE4-9123-D30B2F24A17B}', feature 'FeatureId' failed during request for component '{068153F4-B9E0-4745-9A47-833764D9D60C}'
The GUIDs will be different on your machine, but they can help you identify which component is causing the problem. The first GUID is your package ProductCode and the second one is for the problematic component. Try creating an installation log and see why the component is not installed correctly.
This ended up being an issue with the registry hive. The Visual Studio 2010 Registry editor would allow me to specify values in 'HKEY_USERS(64)\S-1-5-20\Fileopen. This however was the reason for the error above. That is, you can't have values in this part of the registry when it is being generated using setup and deployment from Visual Studio 2010. I moved the values to exist under local_Machine and the short cut work like a charm.
I have the following situation:
Installed my application using ordinary .msi
Run the application from the start menu
Right click on the icon in the task bar and pin it.
Now, I can use the pinned item/short cut to start my application but after I update my app using another .msi file, clicking on the pinned item shows this error:
'Problem with shortcut' - The parameter is incorrect.
I have checked the short cut and as far as I can see it points to the same directory/file as the previous version. (the new version has the same files/location).
I assume that there is some versioning/Program Files magic happening that causes this issue but haven't found any good information on the net.
Some more information:
The application is written in C# .NET 3.5 SP1
The msi is created using a Setup Project in Visual Studio 2008 SP1
I use a custom build tool to integrate the msi build and set the ProductCode and PackageCode to a new GUID for every version.
The update seems to work fine otherwise. The old version is uninstalled, the new one installed correctly.
Anyone got a clue?
My guess is the default Application ID is changing. If you intend to update this app with msi's regularly once it's "in the wild" then set your own Application ID. If this is a one time thing, then just unpin and repin it and carry on as normal.
Setting the Application ID is easy if you're using the Windows API Code Pack. Are you?
Kate
See this article about ProductCode and PackageCode: http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
It explains how ProductCode and PackageCode interact at install time and how to configure your setup project to properly apply the .msi as an update.
I have a Visual Studio project consisting of a service and an installer for it. During the development I have installed and uninstalled the msi-package at least fifty times but last time I tried to uninstall it I got an error message saying "the installed product does not match the installation source" and if I click "Ok" on that message i get the following: "The path xxxxxx.msi cannot be found." So, first it doesn't match and then cannot be found. Or something. The msi-package do exist on the path given in error message (I have replaced the real path and package name by xxxxx).
What I mean by installing the service is double clicking the msi-package that the "Build Solution" function creates and by uninstalling I mean Control Panel -> Add or Remove Programs.
I use Windows XP and Visual Studio 2003 in this particular project.
I have installed and uninstalled this and other visual studio developed services hundreds or thousands of times but have never had this problem before.
What should I do?
I've seen this happen before. Essentially the installer (.msi) windows wants to use is not available where it believes it should be stored. Why this happens I'm not entirely sure but to fix it you have a couple of options.
Put your MSI in the place where windows is looking for it
Forcefully remove your product entry from the MSI catalog using MsiZap. This option is a bit riskier since it's deleting all references to your service vs actually uninstalling it. However the risk is low if it's a service you've developed and it's just your dev machine.
Another utility I've used to get rid of a Windows service is sc.exe. You can do something like: sc.exe delete "Service name". Restarting the machine also helps sometimes.
I had a problem just like this one, where a service in Visual Studio somehow became corrupted and could be neither fully uninstalled nor installed. I managed to fully uninstall it using an online tool at https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed.
Firstly I'm completely aware of this message and why it happens normally. It's not that I'm just trying to run a dll (like this question).
I have a project that compiles to a dll but has a startup program specified in the project properties. Most of the time I'm able to right-click on the project and select Debug > Start new instance, and it will run the program and let me debug my dll. However, occasionally I get this message (A project with output type of class library cannot be started directly) as if I haven't got a startup program. The first few times I thought it was just me accidentally clicking on the wrong project but I'm certain this isn't the case given that it's happened so many times and I've been careful to watch it.
When this message appears I'm able to try it again and it always works on the second or third attempt.
A colleague using the same Solution never has this problem :-/
Anyone else had this problem or know how to solve it?
I'm using Visual Studio 2005 Pro Version 8.0.50727.762 (SP.050727-7600)
Edit: Also happens with Visual Studio 2010
Another colleague suggested it's because after clicking Debug > Start new instance, while I'm waiting for it to start up, I click on a different project. I don't do it for any reason, just randomly selecting things as I wait for the project to start up. Maybe Visual Studio looks at the selected project sometime after I clicked the menu, gets confused, and shows the error message?
Anyone able to confirm this matches their experience?
Typically problems in VS are caused by:
Add-ins: Run VS without and see if the problems is solved
Corrupted files in your solution: Delete / rename all files created by Visual Studio which are not part of your project, i.e. all .suo, .ncb files and a like.
I had this problem with projects that were created as "Windows Control Library" that somehow forget their status. Unloading and reloading the project usually did the trick.
If it was created as a "Class Library" then to make it a "Windows Control Library" I manually add the following to the .csproj file. It was the only difference I could see between a class library and windows control library project.
BTW - starting a Windows Control Library starts the User Control Test Container - allows you to test any user control in the library. Very cool.
<Service Include="{94E38DFF-614B-4cbd-B67C-F211BB35CE8B}" />
add that inside of an <itemgroup> element.
If you plan to use/create/add extra dll's or just have more than one project in your solution, you may get this kind of problem, especially if you forgot a simple rule:
1. In your "Solution Explorer" window. Right click and chose "Set StartUp Projects..."
2. Under "Start Up Project" select and change "Single startup project" to your working entity.
no just make a start up project
Going to resurrect this thread, I have just been experiencing similar issues, when right clicking a project and start new instance..
So instead of right clicking the project and selecting start new instance, I right clicked and clicked set as startup project.
Low and behold a class library project was set to bold, certainly not the one I was right clicking.
I tried selecting a different executable project and setting that as the startup project. Same class library was highlighted as the start up project.
Realised that the current open file was from that project, possibly all the open files were from that project...
closed all open files and tried again.... Problem solved, behaviour as expected for both set as start up project and start new instance options...
Definitely a bug, hope this helps others..
Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework Version 4.0.30319 SP1Rel
This sounds like a transient Visual Studio problem. Reinstallation or upgrade may solve your problem.
I've seen this as well, and it seems like a bug in VS. It happens after you right-click/build a class library (that requires rebuilding), and then right-click/debug > start new instance.
edit- It's still very intermittent, I can't seem reproduce it reliably
I've found that I've had the Startup Project on the Solution set to Current selection, then at some point, I've unloaded a project, and the solution has reverted to Single startup project on a project that happens to be a class library.