Usually a mobile dev would not have to do this because the smart-minimise feature handles it.
But I need to do it myself because my mobile app is kicked off by a bootstrapper app.
The start menu icon kicks off the bottstrapper which downloads a target version from a web service, kicks it off and then closes. If the app gets minimised for whatever reason, the user would normally activate it again using the start menu icon. However, this kicks off the bootstrapper and results in a second copy of the client.
This question comes up everywhere on the net for desktop apps (and is in fact on this site). The usually cited solution is to use a combination of Process.GetProcessesByName combined with API calls to re-activate the process once found. Another solution is to create a controller class that inherits from some VisualBasic dll that I forget the name of. None of the solutions I have come across today are supported by the comapct framework.
So the actual question is a combination of:
Is there a compact framework alternative to Process.GetProcessesByName?
If not, what API call do I have to do instead?
I'm not sure if you found this yet or not, but MSDN has an article on creating a process manager application that has the info that I think you need.
The article reccomends using toolhelp.dll and has a pretty detailed looking walk-through for getting a list of running processes. It's for Visual Studio 2003, so you should probably be good with whatever version of VS.NET you're running.
Related
I'm new in programming with .Net and C# and, as said in the title, I have a WPF app which is accessible in a system tray icon and I want to run it a windows service.
Typically, I want an output like it was described in an answer provided in a discussion here.
If you want it in the system tray I think what you'll have to do is make it a Windows service. I've only written 1 Windows Service and that was years ago, but I believe that's what you'll have to do. If I'm correct about writing a Windows service, then what I would suggest you do is create a new Visual Studio solution and add two projects to it. One would be a DLL which would run as a Windows service. The second project would be a WPF project that will be your UI the user interacts with. Then you'll have to use some messaging system to communicate between the two. For the action messages that would mimic what Outlook does, I've used some WPF toast messages to accomplish that. If you Bing/Google "WPF toast popup" you'll get lots of results.
I have many searched in Internet and find some helpful answers like:
URL1
You can't, not directly, because the windows service will necessarily start when the machine does, not when a user logs in. The service will also be running in a different context, likely as a different user. What you can do is to write a separate system tray based "controller" that interacts with the service.
URL2
It needs some effort to achieve. Well, just two hints: 1) use static property System.Environment.UserInteractive to detect in which mode your application is running, see http://msdn.microsoft.com/en-us/library/system.environment.userinteractive.aspx; 2) get rid of app.xaml, because it will force starting WPF Application in all cases; instead, create and run and instance of System.Windows.Application (or better, a specially derived class) explicitly and only for interactive mode, see http://msdn.microsoft.com/en-us/library/system.windows.application.aspx.
And, I could not apply their instructions.
Thanks advance!
My application is installed on ATM-like machines arouns the world.
It is a WPF application which needs to be automatically updated behind the scenes and without user interaction at all.
Right now we're using Click-Once silent install API and it works perfectly. Our current functionality keeps checking constantly behind the scenes if there is a new version and if such exists, it updates the application, waits for the machine to be Idle (untouched by any users for 5 minutes) and only then it restarts the app. After the restart, a new version is loaded.
Is there a way i can achieve all this using MSI's ? Here's a summary of what i need:
Remote and silent updates for all machines - i already know i can achieve this using LogMeIn and MSIEXEC (so no need to answer this bullet)
Update the application while it is running, without restarting it.
Restarting the application and running the new version only when the application is Idle for 5 minutes.
Any suggestions? If not MSI then any other installer perhaps?
I Can't use clickonce because i want to set my application as the Shell (instead of cmd.exe) in Windows Embedded 8.
It's an interesting high availability story and I can' think of a way to solve it and while MSI will work, it's not really an installer problem per say.
I'd create two installers: ContentManager and Application
The CM once finished should hardly ever change. It's job is to check for available updates and the idle status of the application. When an update is available and the application is idle it can perform a new silent side by side install of application in the background. Note I said install not upgrade. Now you have 2 versions of application installed. When the old application is still reporting idle it could be shutdown and the new version launched.
This would be highly available and MSI wouldn't need to know anything about the scenario. It's simply performing an install.
If you don't need it quite this highly available, then the other thing to consider is that Windows Installer supports "Restart Manager". Your WPF application can also. Your application could check for updates and start an upgrade. The restart manager interaction would then stop and restart your application during the upgrade.
The nice thing about the HA solution is your old version is still there. The content manager could back out the change simply by running the old version of the application.
#Christopher Painter, Thanks for your response. A few thoughts:
The High-Availability solution is good at its base but it would require us to implement too much stuff on our own. A few things you haven't mentioned for such scenarios: 1. what happens if a download fails, what happens if the unzip fails, i would need to uninstall the previous version once install is complete, i would need to implement some security measures on my own (hashing for the 'version xml' or something like that...) how about shared resource locking? i would need to handle it on my own as well... Click once handles all this stuff nicely. Oh and one more thing i'd like to avoid is maintaining two applications instead of one as you suggested. I can't count on the 'Manager' so much that i wouldn't support updating it remotely. I can, however, use a 'push' methodology to activate the MSI using LogMeIn - It lets me upload and send a command to all machines (AMTs). The Restart Manager solution would work for me. Only thing i still haven't figured out is if i can make it hault until the application is Idle, and for how long (it must have some sort of a timeout). I've also researched MSI Custom Actions which can wait on a shared mutex ('idle'). What do you think?
Despite my thorough googling, I am still confused on this matter.
Let me explain my situation. I created a c# project which gives the user the ability to back up the database manually (via a button click). Now the user must be able to schedule a time at which the database back up will run automatically. To achieve this, I am planning on creating a service which is started via the windows scheduler when the set back up time is reached.
I will need the deploy the service along with the main project (In my head, the service will be a different project. Maybe I am wrong here.).
My question is how do I deploy the service when the user installs the main project?
PS: I am using c# express and sql 2008 R2 express.
What are you using to install the main application. Chances are you the said packaging tool will also have hooks for allowing you to install the service. For example, if you are using Wix to create a msi package to install the main application, then you can configure Wix to also install the service.
This google search will point you to relevant articles for the same.
If instead you are not using any installer tool, say you simply give the user a zip containing all executables, then you will need to manually install the service. This article is perfect to create a self installable service. You could use Process.Start to execute the installutil exe to acutally install/uninstall the service.
Edit1:
Building on Rup's comment to your question, you already have the code required to backup the database. All you need, is to be able to schedule this. Once the user enters a schedule in your UI, you can create the corresponding task in the Task Scheduler. Have that task execute your main application, passing in the argument -backup "dbName" or what ever info is needed for the before mentioned backup code to run.
You may use the following template [which is meant for a console app, but will work just fine for your gui app as well. All you will need to check is if any switches have been passed in, then do not start the gui, instead simple execute the backup function code.] ... There are also a lot of existing questions on StackOverflow on which commandline parsing tool to use ...
The approach I would take is create the project for the UI, create a project for the service. The service would be a windows service that would always be running and would be responsible for creating the scheduled task. (Rather than having a scheduled task start the service.) How you go about creating the scheduled task is fairly open, you could shell out AT, or you could do some COM interop with the TaskScheduler type libs. I hope this helps.
I want to write a small tool, that does the following:
When you right click on a file with a certain file-extension the Windows Explorer context menu shows an additional entry.
When you click this entry a certain EXE is launched with this file as one of its parameters.
I would like to use C#/.NET 2.0 for this. If it's not possible I could also do it with C++/Win32.
My questions are:
Is it possible with C# .NET 2.0?
What are the necessary functions for integrating into the Windows Explorer context menu?
How can I make this permanent? (I don't want to relaunch this tool after every boot)
What do I have to take special care of? (different OS, security permissions, etc.)
You will need to access the registry and add a key under root\\File\\shell or root\Folder\\shell, depending on which items you want the menu item visible on.
Try this article at CodeProject, it's quite useful.
Edit: There's another article here which may be of help.
It is, incidentally, not supported to use .NET for shell extensions, due to the current inability to host multiple runtime versions in the same process (.NET 4 will lift this restriction).
Consider the case where you have two shell extensions; one for .NET 3.5, one for .NET 1. Which runtime will get loaded into your process? Well, it's more or less random--it depends which shell extension gets loaded first. Sometimes it might be the 2.0 runtime, sometimes it might be the 1.1 runtime.
This is also an issue if a .NET program creates common file dialogs; your shell extension may or may not load, and may or may not run with the correct runtime version.
As such, if you go down the Shell extension route you should use native C++/COM/Win32.
I have a WPF application that occasionally crashes, and say "not responding". Is there a way to detect if the program is not responding? And if so, restart the WPF application?
This will be a temporary fix until the bugs are fixed.
You could use the Application Recovery & Restart Manager API, which was introduced in Windows Vista. This is an unmanaged (C) API, however there are managed wrappers available in the Windows API Code Pack.
This is a good feature to add to your application anyway, as it provides the user with a nicer experience if (when!) you application crashes. You can even write a callback that persists information about what the user was doing, and then restore that state when the application restarts.
The most basic use of the API would be to just add the following line somewhere in application startup:
ApplicationRestartRecoveryManager.RegisterForApplicationRestart( new RestartSettings( "restart", RestartRestrictions.None ) );
Because this is a temporary fix while you debug the app, one possibility is to cheat and use a bootstrapper/startup app whose sole job is to monitor the problematic app. Start the problematic application via the System.Diagnostics.Process class's Start method, then occasionally monitor the returned Process' Responding property. If not responding, do what you need to do.
It's important that this only be done as a stopgap while you fix the real problem, of course. There are lots of little issues with doing something like this long-term.