I have a small application which is a single executable. For context, this is deployed to Thin Client computers and runs automatically at boot. Users do not have the rights to close this application.
However, I need the application to be easy to update. I can't write my software to do any kind of auto-update routine, because these stations often have a write-blocker* which must be disabled beforehand.
The simplest solution as an administrator is to copy the new EXE over the old using the various tools provided with the Thin Client, or Group Policy / scripting where required. The update doesn't have to be instantly effective - the next reboot is fine.
The problem with this is that, of course, the executable is in use and can't be overwritten. What's the best way to allow this to happen? Load the software completely into memory and run from there? Do some kind of routine which copies the exe to a temporary folder and then executes it with a command line switch so it doesn't endlessly loop?
*This may have caused some confusion. These are Windows XP / Windows 7 Embedded machines. For the most part they work like normal computers, except file system writes are transparently redirected to a cache drive. On a reboot, all changes are completely reverted. A normal script to update the machine would go something like:
Disable Write Blocker
Reboot Machine
Copy Files
Reboot Machine
Enable Write Blocker
Reboot Machine
However, my application will autostart after every reboot as there's no mechanism to inform it. As such, when the scripts get run the executable is still in use.
You might be able to use Windows' MoveFileEx with the DelayUntilReboot option.
To do this from C#, see this answer which shows how to set up the call to the Windows API.
Note: I think the call needs administrator privileges.
You could make of use of something called Shadow copying assemblies. Search the net, you'll find lots of examples (also on SO and Codeproject).
Obviously the application can only update if your write protection is disabled. Are you using FBWF or EWF? You might even exclude the application folder from write protection.
Related
We have a Winforms application that is located on a server.
In other words, the people start the application by a shortcut that points to the executable on the intranet. There where never any performance issues with this approach up till now.
The problem is that over a VPN the application loads extreme slow.
It takes 1 minute and 40 seconds just to show the main form.
All code in the main form in the Load and Show events are disabled to test the performance, and it still takes this long time just to load the form.
Also the mapped directory is set a trusted by windows.
The question is what could cause this slow loading over VPN ?
It seems to me that just loading the main form without any code is already slow.
The application uses DevExpress so there are lots off DLL's to load. Can that be the cause of this problem ?
I know this is not a good question for SO but I need some ideas in which direction to look for this problem.
I found this question here but the problem there was due to a bug in their code so it does not helps me
Deploy the application as ClickOnce. When the application is first run it will be slow as the application will download, then install in the Users[user]\AppData folder. From then on as long as the application hasn't been redeployed it'll run from the local copy after checking with the network deployed version.
You can choose to have the application install locally so it has a start menu entry and can be removed with add/remove programs or you can have it only available online which means there's no start menu entry and it should be started from the setup.exe (I would assume this is the option you would want to go for so your users still start it from the VPN network location.
I have a WPF application which will be used on tablets with Windows 10.
In my development environment, the application runs very fast. However, if I run the application on tablet without admin rights, the application responds very slow : all animations are slow, the scrolling is not smooth, and touch problems are visible (cannot move the caret). If the application has admin rights all things are working fine.
I tried to disable the logs, I tried to decrease the FPS, nothing seems to help.
My application is connected to a sqlite database, but even without accessing the database is very slow. There are no other connections that may require admin rights.
What could be the problem?
EDIT: Also in my dev environment the app is running slower without admin rights. I was running the VS2015 with admin rights and for that reason the application worked fine.
WPF has settings under HKEY_CURRENT_USER that can disable hardware acceleration:
https://msdn.microsoft.com/en-us/library/aa970912(v=vs.110).aspx
If the Disable Hardware Acceleration Option or the Use Reference Rasterizer Option are set, a WPF application will run slowly for that user.
Try to trace your app with Process Monitor. Run 2 traces for app running with and without admin rights. Filter your app events only via Tools->Process Tree... -> right click on your process -> Add to Include filter and compare these trace logs (or just post them here). Pay attention on gaps between registry key readings or network access.
That literally could be anything.
Mark Russinovich make a presentation almost every year about finding some interesting cases. Here's one of them.
P.S. I'm sorry to post that as an answer, but I don't have enough points to add comments right now.
To offer an answer for people that might face the same issue, now, after I've searched a lot for something helpful, I can say that this problem it is mainly a problem related to rights.
If you encounter this issue, try to run Visual Studio without admin rights and try to isolate the region where the application begins to act very slow (or the place were it crashes) . In my case, wasn't the database, or the log files, but a file in AppData which was used by an external assembly. I've seen that, every time that dll was called, the application was freezing and using dotTrace, I've managed to find which file it is used. After setting the rights (r/w) on that file, everything was back to normal.
I have a solution with a Web Application, Console Application (and Windows Service, but that's probably for another question).
Publishing and keeping the Web Application up-to-date is easy. I simply right-click Publish to publish initially or update the live version.
Currently to "publish" or update a console application I copy the release exe and files over to the live machine. In this way I can use the task manager to run the exe in the copied location.
This smacks of bad practice to me. The problem with doing a right-click, Publish on the console app is there's no easy way for the task scheduler to launch the exe. Additionally i'm not sure what would happen when it came to updating the application. Would the "An update is available" screen just sit there waiting for a user to click ok??
What is the best way of easily publishing and keeping a console application up to date?
Ideally something I only have to do from Visual Studio (2008). I'll need to be able to set up task scheduler and then forget about it (no need to do anything with task scheduler or click through anything when updating).
Automatic deploy of applications partly sounds like Continuous Integration.
You may not be interested in the TDD parts, so you can just focus on the tools that allow you to grab code from your repository (SVN for example), build it and deploy it automatically.
Personally, and based on personal experience, I would do this for backstage environments only, for production I would stick to copying exes manually (and keeping backups, of course!)
Personally for these server side executables I just copy the exes. If you're updating them a lot and you want to ensure that you don't put them in the wrong folder or miss a file you could write a .bat script to do the copying for you so that you can just double click on it.
To be honest if you're deploying a new program so often that this is a major issue for you then I'd say you have a different problem. You shouldn't be making changes to a production app all that often. There might be something that's currently code driven that ought to be data driven such that you can make modifications that you need to your program by modifying your database, config files, etc. and not the code of the program.
Basically, I have an exe app that is installed with priviledges (as in, the user presses the "Allow" button in Vista/Win7 UAC check), then the application starts and sets itself to auto-run so that the application will automatically restart again once the computer is rebooted (all done while elevated). The autostarting is requested by user, and is not enforced upon them.
This reboot instruction is set in the registry, in the CURRENT_USER section as below:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
The problem is, when the computer reboots, Windows will not let it execute unless the user re-authorizes it as an elevated process again (namely, a taskbar icon pops up in the tasktray saying the starting of my EXE/process was prevented, and the user is given the ability to launch the blocked app using menus on the icon in the tasktray).
I would like to add that I have the manifest file integrated into the EXE, so there is no problem on that end, and it registers its intentions accurately in the XML file.
Why does Windows do this by design? If an exe was authorized once, shouldn't that imply that it be authorized permanently?
But the main question I would like to ask is, how do I get around this? Imagine my users having to do this every single time the application needs to autorun?
Also, I would like to avoid the whole "your app shouldn't be running in elevated mode in the first place" argument/discussion, or the "no app needs elevated priviledges, you need to rewrite it" discussion. I can assure you that my app needs elevated priviledges (unfortunately). More details below if interested, not necessary to interpret or understand the question in this post, but included because I know some people will ask)...
Additional Unnecessary Reading:
...In fact, it requires it in 87% of all launches (depending on what users do), and for the 13% of times were it is not needed (that's, 13% of all launch instances, not 13% of users), I am developing a second exe where only that is launched first, and once an elevated feature is needed/requested, the elevated portion loads, saving 13% of all launches from hassling people with UAC nag, I will only have this ready by 2013. I'm going to all this work to split up functions that don't logically belong in different areas of the application - even with all this work, the problem I mentioned above does not get resolved (but rather, very slightly minimized or deferred).
I'm not sure why this was tagged with any programming language, and since it is really a ServerFault question it doesn't even belong here as far as I can tell.
The normal way to handle this is via Task Scheduler though, using the Run with Highest Privileges option. There are several published descriptions of the process involved, such as the old one at Make Vista launch UAC restricted programs at startup with Task Scheduler.
Why does Windows do this by design? If an exe was authorized once,
shouldn't that imply that it be authorized permanently?
That's a matter of opinion, but here's mine. If I needed Visual Studio to run elevated yesterday because I wanted it to regsvr32 a DLL, that doesn't prove that I want it to run elevated today on some different app.
But the main question I would like to ask is, how do I get around this?
I would use a service. The programming is non-trivial but that's how I would autorun an elevated process.
Either ask the user to turn off UAC or, as you already mentioned, redesign your application so that it elevates at the point elevation is needed, or run a service under system account and let it do the stuff which requires elevation.
I am working on a program. In testing it on Win7(32-bit, don't know if it will be the same in 64-bit) I found a problem.
Now my problem is that some of the functionality does not work(like the right click doesn't show options or the program takes long to react). If however I set up a the compatibility mode it works fine. I mainly see this problem in Microstation, but it does appear in other places as well.
My question is as follows, is there a way to set these settings(like the check boxes) programmatically from C# ?
This might be necessary in cases where we do not do the installation of the program, to insure that it works on every pc it is installed on. Let us assume that during the installation the program has admin rights. (would it be needed to do this??)
this has nothing to do with Internet Explorer. i wanted to add a picture, but i dont have enough rep yet
There is no way to change this while the application is running, you have two choices to handle this issue:
Modify the installer to create shortcuts that have the compatibility mode flag set to whatever you need
You can manually manipulate the registry to force an executable to use compatibility mode, your application will require admin rights todo so + will need to restart afterwards
Here it's explained how todo it manually, you simply have to do it programatically:
http://kb.winzip.com/kb/entry/139/
In general I discourage you from doing either, fix your bugs instead.