I have a WinForms app deployed to multiple machines in the same office. Up until this Monday, all users in the office used the app without issue and used the OpenFileDialog to select files to import. One machine had lots of updates to other apps and now freezes when our app tries to show the OpenFileDialog. It shows the OpenFolderDialog fine; though I failed to try the SaveFileDialog. Just to repeat, it worked last week, our app was not updated, but it freezes on one machine this week whereas it works on all other machines in the office.
The machine in question has another .NET app installed and I verified the OpenFileDialog opens without issue in the other app.
Any ideas as to why the OpenFileDialog would freeze on one machine? Any ideas on how to fix this? We could try reinstalling without knowing the cause, but I figured it is better to investigate why to prevent it from happening again.
This machine may have connected to a network resource in the past, which is no longer available. OpenFileDialog could be waiting for the network resource to respond, which will take several minutes to timeout.
Related
I have a windows app (written in C#...) that is installed on multiple remote workstations, the installation is being done by a MSI package.
An updated installation with changes to the program is being conducted from time to time, at this point, for each update, for each station we need to go to where the .MSI is located copy it and run it and only than start the app.
I would like that: whenever a user tries to start the app a background process will be initialized that will compare the installed version with the most recent version on the .msi location and if an update in needed will run the installation and than start the app.
The problem is that it can't be done from within the program since the program cannot be running when the installation/upgrade is taking place. Another consideration is that not all the stations operating at the same time so I can't schedule a timely upgrade, and it can't be done on stations boot since sometimes the updates needs to be done while the station is already operating(the station has several functions beside my app).
I have considered several approaches, it seems like a windows service could do the trick but I don't know if it could be "bound" to the initialize of the program and if it could suspend the program to do the necessary checks and updates and only than to restart the app.
I am open to all ideas so please don't feel obligated to my ideas...
at this point, for each update, for each station we need to go to where the .MSI
is located copy it and run it and only than start the app.
Fire the guy pretending to be a system administrator.
Unless you have done something odd in your installer - it should be doable with your standard software distribution package. Heck, I can roll out updates with active directory ONLY and no third party software as long as the MSI allows administrative no ui installs.
You try to fix a non-problem. Software distribution is a solved solution for the last 15 to 20 years. MSI was particularly created to handle this issue because other approaches demonstrated issues.
So, whoever pretends to be the administrator on your company needs to get his act together and be one. Do nothing (except making a good MSI) and let the admin do his job.
Everything else just creates a lot of problems (at least in the cost side). And it is totally not needed.
I'm updating my answer,
This is what we did....
Create the Installer / Package ( you can install for all users here)
Generate Bootstrapper (https://msdn.microsoft.com/en-us/library/ms165429.aspx
You can use this tool create bootstrapper (http://www.softpedia.com/get/Programming/Other-Programming-Files/Bootstrapper-Manifest-Generator.shtml)
Add dependencies and other conditions in bootstrapper
Set the URL for updates
This will solve your problem. I was too quick to answer but this how we did.
Thanks.
Some comments and answers about the assumptions in the question:
"I would like that: whenever a user tries to start the app a background process will be initialized that will compare the installed version with the most recent version on the .msi location and if an update in needed will run the installation and than start the app."
The only time this is likely to be a useful approach is when the MSI is at a company's web server. The web site can host a web api that you send your ProductCode, Version, Upgrade to and it reports whether there is an upgrade, patch etc, and a location to download it from. In a company domain, just use AD, as has been said.
"The problem is that it can't be done from within the program since the program cannot be running when the installation/upgrade is taking place."
Why? Windows Installer will show FilesInUse dialogs for the end user to close down the running app. So this situation is already dealt with, and I'm not sure where you see a problem.
"...and if it could suspend the program to do the necessary checks and updates and only than to restart the app."
This is exactly what Restart Manager is for. Integrate your app with RM and Windows Installer will allow you to close down the app (saving whatever data you need to recover) and then restart you afterwards so you can recover your data and the user sees a minimal interruption. One example:
http://www.codeproject.com/Articles/772868/Restart-Manager-Support-For-Windows-Application
So I think TomTom's point is valid - there is no need to re-invent what AD does, or worry about how to update programs that are running, or how to restart a program after an installer update because all these problems were solved years ago.
I have a strange issue that occurs every day. I have recently been given a fellow developers laptop with Windows7 & IIS6 (they've left) and my previous laptop (WidnowsXP & IIS 5) has been recycled into the system, so I'm stuck with this one and didn't originally set up the system. Developing worked fine on my old computer, but on this one.
I am developing an ASP.NET website and after a while of editing, building, then going to localhost in IE, the page doesn't show. The process w3wp.exe isn't in my list of processes in the task manager. If I call iisreset.exe, this usually fixes it at first (i.e. going to localhost starts w3wp.exe and after a short while my page appears).
After a few runs of this, even this fix doesn't work, but I've found that if I close IE, then run iisreset.exe it fixes it.
Then after a few runs of this, I also have to close Visual Studio & IE, then iisreset.exe. Once I get to this stage, I can't make a single edit in visual studio without having to close it to run the web page. Note, I'm not running in debug mode. I've even tried editing in notepad++ for simple edits and I have to close that too before iisreset works!
Eventually I end up restarting my computer because these incantations stop working. I'm at the end of my tether. Does anyone know what could actually be wrong or where I should start looking for a real fix?
I have a winform Application and there is a code to open Save as Dialog box.
DialogResult result = saveFileDialog1.ShowDialog();
The program very well runs on Windows XP but on Win 7 the application hangs, the debugger does not return from this line of code. The Event Viewer detail reads as follows
The Program Sample.exe stopped interacting with windows and was closed
Has anyone been through this problem?
Update
It seems that the error was caused due to the code running on another thread which I have nowremoved .Although it is not recommended to access UI elements from another thread I am surprised why I didnt get this error while running on XP ??
Are you setting the InitialDirectory property of the dialog?
If you are, try setting it to another location if you are not you could try setting it.
If this is defaulting to a network path, it could be taking the time opening that path?
This could be result of corrupted file system or hard disk. When save dialog is invoked, it will try to get the list of hard drives , logical drives and folders. If any of it is corrupt, it will hang/throw an exception.
Try running same app in different Windows 7 machine
Did you run System File Chccker (SFC) scan on the windows 7 which would scan for corrupt system files on the computer and replace them.
http://support.microsoft.com/kb/929833
I made a program, which works fine on my PC without any errors, it also works fine on some office PCs, but it crashes without any describable error on customer's PC and some others.
Crashes are completely random, sometime it may crash and sometimes not.
Crashes are not related with any actions, sometimes it may crash when they just look at the program and wait for crash.
Customers send me this beautiful screens and want me to solve this.
There you see common error reporting dialog, but not info about Exception.
My program uses Unity Web Player running in WebBrowser control. It's always run in background on the hidden tab which becomes visible when needed.
Any ideas how to handle such errors?
I think you should first ensure that the environment at your place and that of your customers are identical.
Maybe there're dll or other programs installed at your place (Unity web player as you mentioned for example) or anything in your Registry that may differ.
Else there's no point in getting error on one PC and not on another.
Make sure all dll are well deployed
Check your registry,
Ensure that all related programs are well installed
I need a deployment method that do following thing:
Auto-update, like click-once;
Install on all users, like Visual Studio Setup projects.
without admistratives privileges. (except the first times for the requirements)
Can install VB Powerpacks.
The problems is that I'm making a winforms program, that might need to be updated anytime, and that our computers are use by many users (our company run 24hours/days). And we don't want to update my program manually on our 80 computers, for each users!
Click-once could be great if we can do an install for all users (but yes, I already find that it's not possible).
I'M STUCK! Please help.
We use a system where the shortcut to launch our application actually launches an auto-updater. The updater checks the server for any update dlls, and if it finds them, it copies them to the local machine. After that (or if it didn't find any updates), it then launches the application.
This will only work if you have some way to force everyone to log out every now and then. We get around that by having the application watch for a specific file to be updated (the exe itself), and alerting the user every 5 minutes until they relaunch.