I am building a .net 4.5 (c#) app and packaging it with Squirrel for Windows.
As expected, the releasify command creates one Setup.exe file and one Setup.msi. The Setup.exe installs the app as expected on the two windows 10 computers I had access to.
On the windows 7 I used to build the app though, when I try to open Setup.exe, the window where I double clicked the icone goes in "please wait mode" (with the blue progress circle instead of the usual mouse pointer) forever. If I check the processes open at that point, I see three Setup.exe that I cannot kill with the kill process button or via Taskkill command. And all I can do at that point to kill them is pretty much rebooting.
As to the Setup.msi, it seems to do nothing I can see (tells me something like "checking requirements", and once it has, it just closes with no visible effect).
Any idea about what's going on or how I could find out?
Apparently years later this keeps hitting people so I'm posting the answer I had first put in the comments:
Deactivating my antivirus solved the issue >< I wish Avast had told me "hey I'm blocking this" and saved me a few hours
Related
Let me layout the scenario.
We have a 3rd party application (say, app.exe installed to C:\App). It actually cannot run directly, it needs a configuration file passed to it as an argument: "C:\App\app.exe config.ini". Everyone already has shortcuts that contain the necessary arguments.
This application supports plugins, of which we have developed a few. In order to distribute said plugins, they need to be copied to each users C:\App\Plugin\ folder, so when a change is made I have to travel around to everyone's desk and make sure the update gets applied.
This was cumbersome, so I developed an application that will scan a network folder and compare it to it's internal db of files. If there are any changes, it copies the files over to the proper destination folder.
This wasn't seamless though, as the user would have to make sure app.exe was closed - run my updater, and then rerun app.exe. So I renamed the original app.exe to app_launcher.exe, and my updater to app.exe. I modified my updater application to support arguments and pass them through to app_launcher.exe when the update was done. Once app_launcher.exe has started the updater program closes.
I should note - the above actually works.
The problem comes from users who have the app shortcut pinned to the taskbar. Once the real app finally starts it gets it's own new icon on the taskbar instead of being grouped with the original shortcut. This actually makes sense as they are technically two different applications. The users however, don't like this.
I have done some research on this, and found some 3rd party programs that can allow you to group multiple programs (Bins/Fences). I DO NOT WANT THIS.
More research revealed something called the AppUserModelID, which intrigued me. After some playing around, I got my updater to set it's own AppUserModelID. The original app.exe didn't set it's AppUserModelID (found that out via ProcessHacker), but I was able to get the updater to start it with the same ID it was using via the CreateProcess method found in kernel32.dll.
This did NOT work. The updater started under it's own pinned icon, and the original app started a new icon. I tweaked the updater to stay open until the original app was closed to see if that made a difference. This time it started under it's own pinned icon, the original app started it's own, and then the updater window switched to be grouped with the original app under the new icon. So AppUserModelID did group them together, but not how I wanted.
I am using C# for the updater application, and cannot make changes to (or have changes made to) the original app.
How can I get these applications to group under the pinned shortcut? Is it even possible?
I think I may have found a solution, though it's a bit of a hack.
The problem comes from having the final application not matching the shortcut being run.
So rather than replacing the EXE and running the real one when done, I made sure the updater application would always run before the real exe.
The only caveat is that it also runs for EVERY exe on the system (via HKCR\exefile). The first parameter is now the path to the true executable, which if it matches the application it runs the updater. Once the updater finishes or if it is any other app, it runs it.
Not an ideal solution (as it could be detected as malware), but it should work for us.
I have an application I've written for Windows 7/8 which relies heavily on the new taskbar features - jumplists, taskbar overlays, thumbnail previews, etc. Users are instructed to pin the application to get the most out of it.
Every now and then I release an update for this application and during the upgrade process, when the old EXE is removed and the new one installed, the pinned application will lose its icon -- it becomes the default generic file icon.
From what I can tell, it's a simple icon caching problem, and rebooting the machine or restarting explorer will bring the icon back.
I can have my installer ask the user to reboot the machine after each upgrade, but ideally I'd like to find a way to avoid the icon being lost in the first place. The most brutal approach which would definitely work would be to terminate explorer.exe, but that's not ideal either.
I'm using InstallShield LE for the installer, so a lot of the "hard work" is done for me, but this also limit my options. I know I can execute scripts/programs at certain points during the install though.
How can I avoid the icon being lost, or otherwise programatically force windows 7 to refresh the pinned taskbar icons?
Decided to reboot after each update.
Question:
I need a DragAndDrop solution to download a file on drop in a folder of Windows Explorer for C# & .NET 4.0. It should not be necessary to have the file on the computer. The file will be big enough that the drag-time won't be enough to get the download done. I have found various questions, even accepted answers, but nothing that works. The very closest thing to something working is this demo project:
http://blogs.msdn.com/b/delay/archive/2009/11/16/creating-something-from-nothing-and-knowing-it-developer-friendly-virtual-file-implementation-for-net-refined.aspx
How to implement this code to download a file as part of the action of putting it to the drop place in Windows Explorer?
Web browsers solve this problem every day. Simplifying their model a little, do this:
Make a little program that performs your download given appropriate command line parameters. This little program should pop up a window with a progress bar and a cancel button.
Spawn this second program whenever the user "drops" something. This program will create the target file immediately and start filling it with data. It will maintain appropriate locks on the file until it is done downloading, at which point the "downloader" will exit.
If you're going to keep the "downloader" threads in the originating program, you will need some kind of download manager so that the user can get appropriate feedback on their downloads.
Okay, as Yahia said in the comments it's not possible without a proper shell extension for the different versions of Windows and .NET. You might have luck with the link I posted, but for me it crashes the Explorer and the developer thinks it works fine.
My honest opinion is with only .NET you can only do it with a FileSystemWatcher via copying special .temp-files, watching where they land, doing your task and replacing the .temp files when your task is done. Sad Windows.
For two weeks, each day since I installed Windows 7, I have been struggling to get something to work. Something which worked perfectly ok in XP. It's driving me mad, poisoning my life, ruining my days. Why such a simple task works SO CHAOTICALLY!?
I think I discovered a bug in Windows 7, specifically in the way the ShowWindow function works in the standard theme (Aero).
To demonstrate this, I uploaded 2 C# WinForms applications and their source code.
http://www.axonnsd.org/W/P007/BugsDemo.rar
HideableApplication represents an application which you can hide in the SysTray when you close it. Double clicking the SysTray icon reveals it and right clicking will reveal the "Exit" option.
HideableApplicationRevealer attempts to show HideableApplication's window.
The reason I need to accomplish this task is because I minimize my Total Commander and FireFox to the Tray and I want to bring them back via a HotKey. Total Commander offers such a functionality but it is broken.
On Windows XP I managed to accomplish both these tasks without any problems, using the code I attached.
On Windows 7, the behavior is erratic at best, and non-functional at worst.
When HideableApplication runs inside Visual Studio everything works:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => SUCCESS
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => SUCCESS
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio IS STARTED, it works if I use admin rights or run it manually:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => FAIL
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio HAS BEEN SHUT DOWN: it only works if I run it manually (double click exe):
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => PROBLEMS: Window blinks on the TaskBar instead of being shown!
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
If it matters, I reproduced this behavior both with the Taskbar in its standard position AND also with it set to AutoHide, in the left of the screen.
Apparently, I need admin rights to show a window, but even like this, it doesn't work right when I use the Scheduled Task workaround (create Scheduled Task with admin rights and invoke the Scheduled Task via system32/schtasks.exe /run /tn "task name"). What happens is that AFTER VISUAL STUDIO IS SHUT DOWN, the window blinks on the TaskBar instead of being shown (and has no focus). It does appear, but it has no keyboard focus, which should NOT happen because I also used the SetForegroundWindow API.
This is exactly what happens when I try to run reveal Total Commander as well: read below, same behavior: blinks on taskbar instead of being shown.
And don't even get me started on the difference in behaviors between when running it from Visual Studio and when running it from its usual C:\MyProjects folder.
My TotalCommanderRevealer and FireFoxRevealer exhibit even stranger behaviors: when starting Visual Studio, the Total Commander app stops working properly. Even if I load NO PROJECT, instead of showing TC to me, it just blinks it on the TaskBar. However if I open the TCRevealer project, it starts working again! If I shut down Visual Studio, it STOPS working UNTIL I RESTART WINDOWS.
The FireFoxRevealer instead of revealing FireFox, does something very strange: it shows a small label in the top-left corner of the screen, usually with something related to the opened tab. I suspect this has to do with the Window Style and the way the ShowWindow function works in Windows 7. However, sometimes it works, showing the actual window. But most of the time it doesn't. And when it stops working, I never get it to work again until certain unknown circumstances occur and it works again. Regardless, this worked pefectly under Windows XP and does not work at all now.
If you wish to reproduce the FireFox issue, use the code I attached: instead of searching for "Hideable Application" text in FindWindow API, search for "MozillaWindowClass", install FireFox 7 or 8 and install the FireFox "Minimize To Tray Revived" addon.
I should also mention that I'm aware of the "ForegroundLockTimeout" registry setting and I have set it to 0 everywhere it appears in the Registry. On Windows XP it is set by default to 0 but in Windows 7 the default value was 200000, which I have changed. Maybe somehow it lingers somewhere??? And Visual Studio, while running, sets it to 200000 when I shut it down, until I restart the computer? I looked in the Registry and it doesn't change, it's still 0. But who knows?
At the office, when I leave for the night I very rarely log off or reboot. I simply lock my workstation and go home, leaving all my development tools exactly how I left them.
If Windows-Update rolls through and reboots my machine in the middle of the night I'm only slightly peeved because when I log back in the next morning, any MS Office application, or Visual Studio instance I had running will have already automatically restarted, opening whatever file(s)/projects/solutions I may have been working on.
My question is: How can I make my Windows Forms applications (C#) do this? Is there some way for my application to "register" that it wants to be restarted if the system automatically reboots?
I think the RegisterApplicationRestart Win32 API function might be what you're after, it's part of the Restart Manager API.
If you have Windows Vista or Windows 7, you can use the Managed Restart and Recovery API. The links on that page also point to some useful blog entries
http://channel9.msdn.com/posts/DanielMoth/Windows-Vista-Restart-amp-Recovery-APIs-from-managed-code/
A simple way is to add an entry to the following registry key :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Just create a value containing the path of your app (optionally including command line arguments). The app will be run at the next startup, then the value will be deleted.
Step 1: Figure out a way to differentiate a windows-triggered restart from a standard one. One solution would be to try preprocessing messages. They're probably different for a windows-triggered restart...or at least they are in Vista in some cases :/
Step 2: If you detect it's a windows-triggered restart, add a scheduled, one-time task.