I am trying to have Eclipse perform a concrete action on shutdown (halt an external system that would need to be switched off manually otherwise). I understand there is an extension allowing to activate a plugin on startup ( org.eclipse.ui.IStartup ), but haven't found one to do so when closing Eclipse. Does such an extension even exist? If it doesn't, is there a way to have a script executed or to run some code when closing Eclipse?
Thank you.
The simplest answer is to add some code to the stop() method of your plugin. On a normal shutdown, then this method will be called at some point during the shutdown process.
One caveat, though. On abnormal shutdowns, the stop methods of bundles are not called. This will happen, for example, when someone presses CTRL-C from on the command line, or Force Quits from the task manager. I don't think there will be any easy way around this part, though.
For normal shutdowns, adding code to stop should be sufficient.
Related
I am creating a managed bootstrapper application with WiX Burn. I need to handle some ExePackage elements which may require a forced restart. This question has some tantalizing clues about how to handle the restart, but I'm having trouble getting it working.
I have <ExitCode Value="3010" Behavior="forceReboot" /> in the ExePackage elements, and I can see that triggering in the logs. I am listening to the Shutdown event that is raised by the BootstrapperApplication and setting e.Result = Result.Restart, though I haven't figured out how to capture the condition for when this should occur when the force reboot is detected in the Apply phase. I am testing if (Command.Resume == ResumeType.Reboot) in the Run method of my BootstrapperApplication going straight to the progress bar portion of my custom UI, but I'm not sure how to resume the Apply phase where it left off. Do I need to call Engine.Detect() or Engine.Apply in this case? Is there some special action I need to take to persist and restore the state to survive the reboot, or does the Burn engine handle all of that internally?
If anyone could point me to a working example of a WiX Burn managed bootstrapper application that handles reboots, I would appreciate it.
Check out the implementation of WixStandardBA, even though it's not managed. Basically it does the following:
At startup, check the WixBundleForcedRestartPackage variable and store it in m_sczAfterForcedRestartPackage.
Call Detect like normal.
Call Plan like normal.
In OnPlanPackageBegin, skip packages until the package that caused the restart.
Call Apply like normal.
Burn takes care of persisting the variables across the restart.
I've hit a bit of a roadblock, and I'm hoping someone can help!
I've written a metro application that serves as a unit test runner, and I now need to be able to call this application headlessly so that it can be used for validation in the build process. The way the metro app works is it runs a bunch of unit tests, generates an XML file that contains the test results, and displays the results to the user.
Ideally, I would have a simple script that would run the metro app, execute the tests, exit the app, and then have the ability to read the results in the generated XML file. Is this possible, and if so, what's the best way to do it?
Here are some more specific questions:
How can one start a metro app headlessly, and in the metro app is there a way to detect this so that it does not wait for user input?
Is it possible to access files within the package of a metro app from an outside process?
EDIT - A workaround would be to create a custom Visual Studio test runner and then find a way to run the tests automatically with each build. I know this can be done within the IDE, but I'm not sure if there's a way to do this with a script.
I imagine you've long since moved past this problem, but for the sake of anyone else looking to do this, I got it to work without too much hassle. To execute a Metro app in an automated/headless fashion, I wrote a simple desktop command-line utility that takes the name of a metro app and makes use of the IApplicationActivationManager interface to launch it. I can then call that utility from a script.
The second argument to that inteface's ActivateApplication method is a string that gets passed in to the activated app, kind of like command-line arguments. It shows up as the Arguments property of the LaunchActivatedEventArgs that is received by the app's OnLaunched handler. The default implementation of OnLaunched in the Visual Studio template projects passes this value to the MainPage when it first navigates to it, where it comes through into the OnNavigatedTo handler as the Parameter property of the NavigationEventArgs. You could catch it in whichever place is more convenient.
My launcher utility passes a hard-coded flag through there, as well as forwarding its own command-line arguments. That allows the top-level script to pass arbitrary data down into the Metro app. The app can use that data to realize that it's running headless and run its tests. It can spit out whatever kind of result data you like into one of its folders (like its LocalFolder), which a desktop app can then read from %LOCALAPPDATA%\Packages\APPNAME\LocalState. I setup my launcher utility to wait for the result files to appear after launching the app, and then use them to determine its own exit code. The launcher utility can't kill the app afterward, but the app can kill itself when it's done via CoreApplication.Exit.
That setup worked great for a while, but a problem that I'm running into now is that the app isn't always launched to the foreground, and the runtime will suspend/terminate the app after it hasn't been the foreground app for some amount of time (currently ~10-15 seconds). So any tests that take too long won't work with this approach, barring some workaround that I haven't discovered yet (which I was searching for when I came across this question).
I doubt you'll be able to do it.
It's the same sort of problem as trying to run a WPF app headlessly, but harder since you'd also have to deal with the Metro sandbox security model.
P.S. Happy to be proven wrong!
No, sorry. You hit a wall with your first requirement of a script that runs the Metro application in "headless" mode in the first place. Your second requirement would be your next wall. One application cannot see, let alone monitor, another application/thread/process. Then your third requirement is also impossible. Files inside an application are isolated. It sounds to me like you found a good candidate for a desktop app. Having said that, don't mistakenly think that you can't have a companion Metro application that is your dashboard. It's just the execution core can't be hosted inside the WinRT sandbox.
I envisage I'll run into problems as i haven't done this before.
I'm thinking that I can either define a date at the start of the method or initialise a class.
Then at the end of the method, call the commit method, which will write the time taken about with some sort of code to determine where the measurement was made.
Since you're crashing before the app finishes launching, so no code is going to fix this. If TestFlightApp isn't working, any other code-based solutions are likely to have the same problem.
As #dasblinkenlight noted, NSLog timestamps, so that's a really easy first step. Then you need to get the logs.
If possible, have your user install and run the iPhone Configuration Utility. Have her connect her device and select it from the Devices list. Then select Console and "Save Console As..." She can then mail it to you.
I'm working with JNI and trying to unload (destroy) the VM using DestoryJavaVM function (I first call DetachCurrentThread method). It seems like the it has now influence on the VM and it is still up after the call. I read in old Sun posts that DestoryJavaVM had problems in the past (JDK1.1-1.3 in 2001) but I'm using JRE 6 and it probably should work now, right?
I need to Load\Unload a VM in the same living process since each loading requires another classes to load. Any ideas how it can be done?
Additional info:
At the unloading phase I can successfully detachCurrentThread and destroyVM (both return JNI_OK). I even FreeLibray (jvm.dll) successfuly (return 1).
When I try to Load the JVM again I can LoadLibrary(), then find the CreateVM function in the DLL and the call to CreateVM fails (return -1). What I'm doing wrong here?
Thanks,
Guy
Although it wouldn't answer your question on DestroyJavaVM.
OSGi comes to my mind you could put all classes in a bundle activate it run code and deactivate it, later you use another bundle. See Apache Felix.
Another option less elegant would be to exit the vm and restart it with another classpath.
You might check for errant threads. The Invocation API: Unloading the VM mentions, "The VM waits until the current thread is the only non-daemon user thread before it actually unloads." This is required by the Java Language Specification, 12.8.
DestroyJavaVM() doesn't support VM unloading.
DestroyJavaVM
Unloads a Java VM and reclaims its resources.
Any thread, whether attached or not, can invoke this function. If the current thread is attached, the VM waits until the current thread is the only non-daemon user-level Java thread. If the current thread is not attached, the VM attaches the current thread and then waits until the current thread is the only non-daemon user-level thread.
[...]
Unloading of the VM is not supported.
The documentation can seem a bit conflicting at first. What you can do is destroy your VM without problems, but since it doesn't unload properly you can never reload it again in the same process.
For any newbies visiting this question, refer Calling JNI_CreateJavaVM function twice
Short answer: You CANNOT create more than one JVM in a single process (this is by design).
We have an unattended app w/o a user interface that is is periodically run.
It is a VB.NET app. Instead of it being developed as a service, or a formless Windows application, it was developed with a form and all the code was placed in the form_load logic, with an "END" statement as the last line of code to terminate the program.
Other than producing a program that uses unneeded Windows form resources, is there a compelling reason to send this code back for rework to be changed to put the start up logic in a MAIN sub of a BAS file?
If the program is to enter and exit the mix (as opposed to running continuously) is there any point in making it a service?
If the app is developed with a Form do I have to worry about a dialog box being presented that no one will respond to even if there are no MessageBox commands in the app?
I recall there used to be something in VB6 where you could check an app as running unattended, presumably to avoid dialogs.
I don't know whether there are conditions where this will not run.
However, if the code was delivered by someone you will work with going forward, I would look at this as an opportunity to help them understand best practices (which this is not), and to help them understand that you expect best-practice code to be delivered.
First of all, you don't need it to be run in a Form.
Forms are there for Presentation, so it should not be done there.
If you don't want to mess with converting the application a Service (not difficult, but not very easy neither), you shoud create a Console Application, and then, schedule it with Windows Task Scheduler.
This way, you create a Console Application, with a Main function, that does exactly what you need.
Anyway, the programmer could show windows, so there should not be any messagebox. Any communication should be done via Logging to: local files, windows events, database.
If you want more information on any of them, ask me.
If you don't want it to be a service, nothing says that it has to be a windows service. Scheduling it to run via the Task Scheduler or something similar is a valid option.
However, it does sound like the developer should have choose a "Console App" project, instead of a "Windows Forms" project to create this app.
Send it back. The application is bulkier and slower than it needs to be, although that won't be much of an issue. It is somewhat more likely to run out of resources. But the main reason: converting it to a console app is very easy.
If you don't prefer for the Console window to popup, simply do the following.
Create a new class "Program.vb", add a public shared Main() method, and move the "OnLoad" logic from the form to this method.
Next delete the form, and change the project start up object (Available in the project properties window) to use the Program.Main instead of the Form.
This will have the same effect, without the windows forms resources being used. You can then remove the references to System.Windows.Form and System.Drawing.