I have a VB.NET ClickOnce application that I am trying to install on my computer. Previously, I was able to install and run these apps without issue. Now when I install the application, I can see the flash of a window opening, and then nothing. (There are also no processes left hanging or anything when viewed with the task manager.)
After some digging around I noticed that there are files in my Temporary Internet Files with names like "FusionBindError" and then my application name and different DLL names.
I have done everything I can find on the net to do, reinstall applications, reinstalled the .NET Framework, deleted my Local Settings folder and relogged in.
Does anyone out there have any other ideas for me to try?
I tried the Mage.exe suggestion, but it failed to help. Same with the other installation location suggestion. The application flashes at the bottom of the screen but does not open. I have tried using FUSLOGVW to check the bindings and nothing shows up in there. (Good or bad, there are no binding entries.)
Have you tried using mage.exe? This is a command-line tool that comes with .NET framework. Start up a VS command prompt, and try mage -cc. This will clear your applicaiton cache and will force a new click-once download. This is the first thing I do when my click-once applications fail and it works 99% of the time.
A couple of suggestions:
FusLogVW isn't working for you because you have to enable assembly binding failure logging inside the registry. This MSDN article describes how to do this.
Another thing that comes to mind is, perhaps the ClickOnce app install, or perhaps the whole ClickOnce store is corrupted. Try deleting the ClickOnce app store then reinstalling the application.
It's possible that new prerequisites were added that you don't have on hand. If the URL you are using points directly to "my.application" or whatever your equivalent is, prerequisites won't be processed.
So try pointing to the setup.exe that is created in the same directory as the .application file.
Other than that, it sounds like you're doing all the right stuff...
Also, it could be useful to run the fuslogvw utility on a machine where the application actually works. Or reflector.
And then see if indeed any of its dependencies being loaded surprise you.
Also, for these types of errors, be sure to check if disabling the antivirus resident protection helps. Sometimes it causes problems accessing assemblies' manifests and such.
I uninstalled my Kensington Mouse software, and that resolved my installation errors.
Who knew that mouse software that I never used could cause so much trouble??
Sometimes if your machine is working for days this problem will show up. Try to restart your machine. The same problem happened to me and it disappeared when I restarted my machine.
Related
I have an Installscript installer. When I run it to update the product and parts of the product are running, then a reboot is required. -- This is ok.
It turned out that in case of a reboot all files are copied properly, but a configured self-registration does not take place -- not during installation, and not after the reboot.
I have checked the setup.ilg file and it tells me no news: files are copied, and self-registration appears to have been done.
When I close programs to prevent the necessity of a reboot or when I install the first time everything is ok.
Can you explain why the self-registration does not happen and what I can to to make it happen? Thank you!
Stein asked me to weigh in on this.
Honestly, I haven't touched InstallScript project types since 2003. But I can take a guess at what is happening. I would imagine that the locked file causes MoveFileEx() to use the PendingFileRename operation pattern and that self registration isn't happening because the DLL isn't where it needs to be yet. Something would have to happen after the reboot to call LoadLibrary/DllRegisterServer() after reboot when the file is now in it's final resting place.
Why isn't this happening automatically? I have no idea. I did a quick google search and did find this article:
http://helpnet.installshield.com/installshield19helplib/Subsystems/installshield19langref/helplibrary/LangrefXCopyFile.htm
Unfortunately my corp firewall is blocking me from accessing it. Based on what Google showed me it sounds like you might have a workaround by using XCopy function to handle this.
Honestly though I only do MSI projects any more and you could also take a move out of that playbook by harvesting the COM meta data and applying the registry data yourself so everything lines up after the reboot.
COM Extract at Build: Maybe try to enable COM Extract at Build to eliminate the need for self-registration? Please see this answer: Failed to run script function from Custom Actions. Essentially the option is hidden in the property page for each component.
Is this perhaps an old-style, legacy installer that is not MSI at all?
https://helpnet.flexerasoftware.com/installshield24helplib/helplibrary/IHelpCompRegDynamic.htm
InstallShield communties:
https://community.flexerasoftware.com
http://forum.installsite.net
I have a custom bootstrapper (C# WPF) and it works well enough. If the installer gets run from the command line after it was installed, it brings up a window allowing the user to select if they want to modify, repair or uninstall. So far so good. Modify mode starts the UI which ends up calling Bootstrapper.Plan(LaunchAction.Modify). The problem is that if I call it from the launcher UI it immediately complains that a prior install requires a reboot.
I have not found any good examples on what this should do. Even the WiX mailing list came up blank.
Any ideas?
It would be helpful with the screenshot for that reboot message - just to get a feel for where it might be coming from and to get a literal string to search for. Did you have a look in the WiX source code yourself btw? (WiX 3.111 branch)
I started writing a lot of stuff about reboots. Not good. Maybe just some questions instead:
Does this happen every time you invoke modify and is it reproducible on more than one computer? Or maybe it is just Windows Update acting up on a problem computer?
I assume you have rebooted the computer where you see the problem and you see the problem again when you re-launch the bundle?
Do you schedule any reboots inside your MSI files during the initial installation?
Either using the ScheduleReboot action or a custom action which schedules a reboot with a call to MsiSetMode (for example)?
There is a long explanation here why such reboot-constructs cause problems, but that may be besides the point. Essentially badly configured reboot-constructs can trigger spontaneous, unexpected reboots without warning when packages are run in silent mode (plus other problems).
Could you try to run the test VBScript found in this answer: WiX behaving badly on XP machine with windows update issues in order to check if the script reports a reboot being necessary?
Other than that I guess you could try to run Burn yourself in debug mode (not sure how much plumbing that would be to get running) or perhaps first try a ProcMon.exe session to see if you can see something obvious. The latter should be quick to do?
There are some registry locations you can hunt down to see if you can figure out what triggered the reboot warning. Get-PendingReboot-Query. And a similar PowerShell script.
So in the end it was user error. :-( O well. I did learn a lot about how to figure out how Windows checks for the need to reboot etc.
The issue was simple in the end. During the modify run it was uninstalling, then reinstalling a number of services. The problem is that when it runs (seeing as you have to set it to repair to get it to work) it copies all the files again and the services were still running at the start of the install. The fix was to uninstall anything that might lock a file before the actual file copy starts and that solved the issue for me.
Thanks for your help guys, all the info helped me look in different directions until I found the issue. Awesome community as always!
How can I solve this error when the application is published:
You probably have just installed it, but you've done it running the setup from a different location.
Uninstall the application and run again the setup. Remember to run the setup from the same location when you update it.
I'm not 100% sure about it, but form my experience it's correct.
I need to update my Windows Phone application tile by downloading and parsing JSON. So I'm using Microsoft HTTP Client Libraries.
And I've always got the exception Use of networking APIs requires the ID_CAP_NETWORKING capability to be defined in the application manifest when I'm trying to debug background task.
But my manifest included ID_CAP_NETWORKING as required (screenshot https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-xaf1/t31.0-8/10750111_821340111262044_6461333323674658178_o.jpg).
I don't know what to do. I tried rebuild or recreate the app, but this didn't help. Also I can't find any documentation or an answer on the internet.
Can you please write, what can I do to solve this problem?
This is demo project http://1drv.ms/1yjHm49 with reproduced problem (project's name is 'Meduza. Windows Phone').
I debug my application on Lumia 720 (if it can help).
I re-downloaded your project and now I get your error. So I thought, I must of done something before launching your project that fixed it.
It took me while, but I can get your project to work by doing this
Unzip project to directory
Open Project
Clean Project
Add Internet (Client and Server) in Package.appxmanifest file (make sure you save it before exiting)
Put the break points in your background task
And it works. So a combination of Clean Build + editing the Package.appxmanifest did the trick for me.
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.