I have this project which requires to run a InstallerClass as part of the installation.
I added it as a Custom Action, and it has been working like that for ages. We did some maintenance to this class, cleaned the solution, rebuild the solution, and now the Custom Actions are not being triggered.
I know they are not being triggered, because I had Debugger.Break() calls working prior to the cleaning, and the fact the registry entries that are meant to be created are not created anymore.
What is going on? What can I do to obtain more info from the MSI installer?
For what is worth, my machine is 64 bit, but the project is mean for and built as 32 bit (x86). I used to build it as Any CPU before, now it doesn't matter what I built it with, no results.
I've been done some more research and found that if Debugger.Break(); is no longer working could be due to a dependency issue, I got no error or warnings on the project though. I ran the MSI on verbose, but I can't make a thing out of it either.
After getting lost on the logs I got nothing useful. I started over again and created a new Installer class with a pop window. that worked. Added a Break() afterwards, it worked too, added the using Process statement I wanted to run and it worked... once.
After that I found that: If I leave the Debugger.Break() it gets skipped, but if I remove it it works...
Yes, this is THAT random... What's the deal?
It would be worth first checking in source control what changes were made to the installer.
In any case, I have seen various weird cases where the installers acted weird. A few suggestions:
Ensure base.Install is last.
Run VS as Administrator.
Recreate the installer project (they can get corrupted).
Try the MSI on another machine - if it works then nothing wrong with MSI and problem is with your machine. It is possible one MSI execution may have left some remnants.
Uninstall the product from your machine and then try MSIZap with the product code. This will cleanup your machine for any remnants that uninstall may have left behind.
Related
I've been googling this all afternoon and I found any number of people ask the question, and all of the place a few people would answer it with the same things, and then there's a dozen comments by the rest of the world and the OP about how those answer don't fix it. So I'm going to include what I've tried here, and if your solution is to do one of the things I've already tried, I'm going to be very sad.
I have a solution in Visual Studio 2019 that has a class library, a wpf application, and a setup project (using the setup project extension). The WPF app also references a bunch of assemblies of course, but one of those is from another project I maintain in a different solution. I copy/paste the compiled dll after I update it from its own project to this one. Nothing tricky, everything works.
The problem is the installer. If I build everything and then build the installer, it produces an MSI as expected. If I right click on the project in Visual Studio and choose "Install", everything is perfect.
The problem is after I make some updates to either of the code projects, I then build both and build the setup project, and again if I right click to install it's perfect. If I run the MSI though, it doesn't always update the target files. If I delete the target files it will create them with the new ones, but it won't overwrite the old ones correctly.
AssemblyVersion and AssemblyFileVersion are both being incremented each time and are being kept in sync with the "Version" property of the setup project. I tested with these extensively, the new installer that isn't working properly 100% has updated dlls in it with correctly updated version numbers.
When I change the "version" of the setup, it asks to change the GUID for the ProductCode. I say yes, it changes the code. I have also tested without doing this and that makes it much worse as we all know.
"RemovePreviousVersions" is set to "true" in the installer project
If I right click the project and choose "Install" it seems to be 100% reliable at upgrading the existing installation.
If I run the MSI directly it seems to be 100% unreliable and never gets it right.
Side note, it does seem to usually but not always get the WPF application upgraded and the other project dll I bring in if I remember to update its version, but the class library (which is referenced by the WPF application) almost never works.
Has anyone got this to work reliably?
For all the people finding this in the future, here's the final word:
The build project can be inconsistent, this is well documented all over the internet as I have above. You're not doing anything wrong - it is just inconsistent.
Stop trying to solve it if it's affecting your project and move on (I've had a dozen projects before this one work just fine). The consensus seems to be to use WiX, but I'm not here to discuss the alternatives. Personally I am going to embark on the WiX learning curve though.
My application works fine when I run it from Visual Studio 2012. The problem is when I try to install it on PC. I'm constantly receiving the error on the image below at the end of the installation. I checked and KinectAudio10.dll is present on that location. The application runs fine and only crashes on part where I need to play a sound. I'm playing the sound with SoundPlayer.Play(); Any ideas what could be a problem? I'm making installation package with InstallShield. Thank you.
Self Registration is not a best practice for reasons that should be obvious to you now. Relying on out of process code introduces the likeliness that the installation will fail and creates registry values that Windows Installer is unaware of and therefore incapable of rolling back or uninstalling cleanly.
For testing purposes, open an elevated command prompt and CD to your SYSWOW64 directory. Use the command RegSvr32.exe FILENAME.DLL to manually register the DLL and then test your code again.
If this solves the problem, reset your test environment back to a clean state and rebuild your installer without using Self Registration.
To this this, find the componentin InstallShield that has that file and look for the Self Reg checkbox. Disable it. Then set the COM Extract at Build option to true and rebuild. Example the build log for evidence of extraction and lack of failure.
Install on the clean VM and test your application.
Change all references in all project Kinect.dll property Copy Local to false. It works for me.
I had the same boring problem.
It worked for me just moving the KinectAudio10.dll from the SysWOW64 to another folder.
I guess that InstallShield when it does not find the ddl it just does nothing.
I don't use any kinect's sound in my app so i don't have any side effects.
I am having great problems running the application in the debugger from Visual Studio 2008.
When I'm using vshost.exe, it says:
And when vshost.exe is turned of, it simply states:
Interesting thing about it is that when i do use vshost, debugger is actually started and breakpoint is hit on the first line of the Main().
I tried:
rebuilding the project(s)
removing .ncb, .suo, .user for the projects
repairing Visual Studio 2008
changing the build architecture for the project
... no help there...
Any experience in (trouble)shooting that?
More info: some projects DO work, and one that I have to work on, does not.
I have some ideas such as:
trying to create NEW project, add thing by thing to it and see at what point it will start to miss behave
work it other way around, delete project by item by item to see when it will (if it will) be working OK again.
EDIT (for google, as I see that there are many similar questions on the web):
Errors:
Error while trying to run project: Unable to start debugging.
and
Error while trying to run project: Unable to start program '....\PlayKontrol.exe'
Try upgrading your Visual Studio to Service pack 1, if you haven't already.
Did you restarted your computer? You never know how windows will react to that :).
Also be sure there aren't any keys stuck, like the ctrl or windows key.
Note that the key does not have to be visually stuck, it can be stuck for visual studio and not for the explorer.
The most common source of sudden problems like this is corruption of one of the data files that vs uses to cache information between builds.
You've tried a clean build, but this won't delete everything. A real clean build is: quit vs, delete bin, obj, debug, release folders, delete all generated files in the root - primarily ncb. Do the same for any locally built libraries that you're project references.
The easiest way to do this is if you have the code in source control, as you can rename away your entire code folder and then force a get of all the source.
You often need to do all of these things in one hit to clear the problem.
Less frequently, a reinstall of vs will sort things out (although this sounds unlikely in your case if it is only one project that breaks)
Also think carefully about anything you might have installed just prior to it failing... And remember that some install effects may not occur until the next reboot so it could be days ago. A particular cause of this are automatic windows updates and trial versions of things like the vs 11 beta.
You might try running the application from outside of VS, but have a line of code that looks like this: Debugger.Launch(); where you want your first breakpoint.
I have a Click Once application (WPF) in C#. Initially when I would hit F5 to debug/launch the application it worked smoothly. Eventually, F5 only would build the solution and not launch the application (therefore I could not step through my code). For a short while I switched from Debug to Release mode and for some reason that allowed the application to launch after using F5 and I could step through my code again. But now that no longer works either. Long story short, I cannot get the application to run in a manner that allows me to step through the code. I can only do a Start without Debugging (Ctrl + F5). Obviously this doesn't do much for me other than tell me if the application works or not.
The thing that worked for me today was to open Task Manager and look for any debug programs that didn't terminate properly.
Task Manager > Processes > kill all programs "*.vshost.exe *32"
You probably have lost your start up project in the solution, or the start up project is messed up, and no correct "item" is defined for the startup.
Right click on one of your projects, and select : define as startup project.
Then retry that should do the trick. If not, check in that projects properties to see if a form or something is defined as the startup object for that project.
Edit : Obviously dont define a class library project as startup project, but choose your UI :).
I had this same issue today and came here looking for help. I tried all the suggestions here and nothing helped.
Seeing as my solution was a simple console application I recreated it from scratch. The new solution didn't exhibit the problems, so I started comparing the two.
I reset the solution and project files so that they were identical (apart from Project GUID, name and root namespace) but the first solution still didn't run.
I then tried deleting the suo files, and the bin and obj folders. Still the first solution wouldn't run.
Finally, I noticed the vshost.exe process was still running for the project. When I killed that and reloaded, it all started working correctly.
I just had this problem today. The solution turned out to be a slight twist on the issue with *.vshost.exe mentioned previously.
I could build the application just fine but msvs refused to launch it. I could manually launch the application and the time stamp on the file indicated that it was in fact a fresh build as well. *.vshost.exe wasn't showing up in the task manager, so I couldn't end the process as suggested.
When all else failed, I tried deleting the .exe's and found that *.vshost.exe would not delete because it was in use. The error message indicated that it was actually the steam client (third party software) that had somehow grabbed my *.vshost.exe file and was "using" it. Not sure how or why. At any rate, I completely shut down steam, then it let me delete *.vshost.exe. After that, building and running from msvc worked normally.
Had the same issue, eventually tried deleting all breakpoints and the debug started working again. Yet to figure out why, but at least it works.
As well as the ghost *.vshost.exe. It could also be that you have the same Solution/Project open in another version of VS. I had the same Solution open in both VS2010 and VS2015 and when running in VS2010 it compiled but failed to start. Closing the VS2015 Solution and it ran as expected.
After years of using VS 2008, I suddenly had the F5 problem not launching the application. There must be a dozen different suggestions out there - I tried a few. Someone suggested a virus. My Microsoft Security Essentials was not automatically updating (a common problem it seems), so I manually updated it. It found a virus, removed it, and the F5 problem went away !
Had this problem and tried to delete everything in bin/debug folder but could not delete vshost.exe file - kept requesting admin permission and then still could not remove it even though running from admin account. Restarted and file was gone and f5 worked again
Here is the error message: The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDialog,
I found another link related to the problem. The link here
Will cleaning the registry work. I tried the tool mentioned there but it needs registration.
Can this be resolved
This cannot be answered without knowing more about your installer and the context that you are installing it. Generally you aren't following MSI best practices and you are getting into a situation where you don't have the proper privs to do the install.
This really doesn't have anything to do with the fact that you have a service although if you are using an InstallUtil custom action consumed by an Visual Studio Deployment Project installer then your problem is probably that VDRPOJ is so broken it schedules deferred custom actions with impersonation instead of system context.
I have resolved my problem. It was a critical one really.
Here is what happened:
The service I wrote crashes soon after starting. While crashing, it probably holds onto few resources and hence when I try to uninstall it, it wont be removed from the list of services, that is, it is never removed from registry.
Now that it's still entered on the registry, I can neither install or uninstall it. The .exe has been removed in last un-installation, therefore there is nothing to uninstall.
The solution was to manually remove the entry from registry. I have changed my code so that it doesn't crash or at least it's handled as an exception.