In my WP7 app I am using a periodic task.
Whe I use the code for debugging to launch the Periodic Task it runs as expected i.e.
ScheduledActionService.LaunchForTest(periodicTaskName, TimeSpan.FromSeconds(60));
However when I just add it to the action service it will not execute i.e.
ScheduledActionService.Add(periodicTask);
The code is never executed. Its the same issue as http://forums.create.msdn.com/forums/t/91617.aspx
I have downloaded several sample apps and its the same in all of them. As soon as I comment out the LaunchForTest code then the task is not run. Its the same in the emulator and on the phone. I have checked the Phone > Settings > Background tasks and my task is there and 'on'.
The only thing I do see is the following in the output window when running in debug via the emulator
The thread '<No Name>' (0xf25003e) has exited with code 0 (0x0).
When I am running the ScheduledActionService.LaunchForTest code then I see a similar message, but I also see that assemblies have been loaded etc - and the code is performed.
Any ideas? Its very frustrating. - Thanks!
Make sure to check background service details are added to WPAppManifest.xml file.
Below is the sample
<Tasks>
<DefaultTask Name="_default" NavigationPage="MainPage.xaml" />
<ExtendedTask Name="BackgroundTask">
<BackgroundServiceAgent Specifier="ScheduledTaskAgent" Name="Task_Name" Source="Assembly_Name" Type="Assembly_Name.ScheduledAgent" />
</ExtendedTask>
</Tasks>
A while ago i had same problem, it looks like when you add background agent project to your foreground project, it is missing update the manifest file.
Related
What:
After updating to pretty much all Cypress versions 10.x.x, WebStorm stopped or Cypress stopped opening the correct line number for the below scenarios:
Issue:
Where a test would fail an assertion etc. with link to the line in IDE.
Open In IDE inside specific spec it block .
Inside SCREENSHOT: FAILED_LINE_NUMBER it brings me to that line however that's not the line the test actually failed at.
Similar situation when I click on the link pointed out inside SCREENSHOT: GENERIC_BODY_OPEN_IN_IDE -- clicking the link doesn't bring me to the correct it block.
I am fairly certain this is user error but cannot figure it out.
Setup:
Windows 10
Cypress 10.0.3
WebStorm v221.5921.27
cypress runner > Settings > Device Settings > External Editor = Custom C:\Users\me\AppData\Local\JetBrains\Toolbox\apps\WebStorm\ch-0\221.5921.27\bin\webstorm64.exe
Things I have tried:
Wiping cache inside C:\Users\me\AppData\Local\Cypress\Cache and then running npm i cypress
Reinstalling WebStorm
Images:
FAILED_LINE_NUMBER
GENERIC_BODY_OPEN_IN_IDE
I have a Nativescript core (js) project that I've been working on for nearly two years. I am up to date with version 6.7.8. I have been building fine for both Android and iOS, but recently needed to install Android Studio. I was nervous about doing this, since my existing Android support was via command line installs (via brew on my Mac) and I figured Android Studio might mess up that environment.
I recorded my JAVA_HOME and ANROID_HOME environment variables so that I could reset them if that should occur. I installed Android Studio, and built a sample Android app and tested it and it all worked as expected. I checked the values of my JAVA_HOME and ANDROID_HOME as saw they were not changed. I also noticed, happily, that Android Studio recognized the emulator VMs I had painstakingly set up with the command line previously.
So I was feeling pretty good. But when I tried to build my NativeScript project again, all I got was errors. Oddly, the errors would change between invocations, which is weird. No real explanation was given for the failures. What's weirder is that I then discovered I could no longer build for iOS either!! What did installing Android Studio have to do with THAT?
I found that I could still build a simple Nativescript test app I had lying around. Played around with this for clues, but didn't find any, so I decided to "start over" with my main project by creating a new one with tns create and then migrating the app files in until I found a breaking point.
This went without notable incident until I had pretty much copied over all the files (installing the plugins these required as I went) except for those files in a directory called 'settings' (which holds code for the 'settings' portion of the app). Without this folder, I can build and run the app (except of course, without settings functionality). the mere creation of the folder 'settings' however is enough to make the build fail. Maybe. The thing is, if I practice the definition of insanity by repeating my same steps (try it with, try it without, try it with again) I can get it to work for a bit. I got as far as being able to actually add some of the source files to the folder with success, but then it would subsequently fail and the only sure thing is to roll it back to a point without the 'settings' folder. I even tried renaming the 'settings' folder, but it doesn't seem to be magically related to the name of this directory.
It doesn't seem to matter what's in the files I might add to the folder, and they might be .js files or .xml files.
The error reported is:
Error executing Static Binding Generator: Couldn't find '/Users/sohmert/tbd/wanwan/platforms/android/build-tools/sbg-bindings.txt' bindings input file. Most probably there's an error in the JS Parser execution. You can run JS Parser with verbose logging by executing "node '/Users/sohmert/tbd/wanwan/platforms/android/build-tools/jsparser/js_parser.js' enableErrorLogging".
Detailed log here: /Users/sohmert/tbd/wanwan/platforms/android/build-tools/runSbg.log
the runSbg.log mentioned simply contains this same text, so no help there.
running the js_parser.js with enableErrorLogging as noted doesn't seem to do anything either.
I have done the "delete the node_modules/ hooks/ platforms/" dance and that sometimes seems to help, but not conclusively. The success / non-success seems very random and capricious.
I have run with --log trace at the end of the build command and that doesn't reveal anything either. Here is the relevant section dumped from there:
16:04:21.598 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute exec for :app:runSbg' started
16:04:21.599 [INFO] [org.gradle.process.internal.DefaultExecHandle] Starting process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin/java''. Working directory: /Users/sohmert/tbd/wanwan/platforms/android/build-tools Command: /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin/java -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -jar static-binding-generator.jar
16:04:21.599 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Environment for process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin/java'': {PATH=/usr/local/opt/node#12/bin:~/.npm-global/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin, NVM_RC_VERSION=, JAVA_MAIN_CLASS_14515=org.gradle.wrapper.GradleWrapperMain, APP_ICON_14515=/Users/sohmert/tbd/wanwan/platforms/android/media/gradle.icns, JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home, TERM=xterm-256color, LANG=en_US.UTF-8, ANDROID_HOME=/usr/local/share/android-sdk, LOGNAME=sohmert, TERM_PROGRAM_VERSION=433, PWD=/Users/sohmert/tbd/wanwan/platforms/android, XPC_SERVICE_NAME=0, NVM_CD_FLAGS=-q, SHELL=/bin/zsh, NVM_DIR=/Users/sohmert/.nvm, TERM_PROGRAM=Apple_Terminal, OLDPWD=/Users/sohmert/tbd/wanwan/platforms/android, USER=sohmert, TMPDIR=/var/folders/cw/jr7g3xr96g73y_pgrxprdg3h0000gn/T/, SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.LPNDVV0GE6/Listeners, XPC_FLAGS=0x0, TERM_SESSION_ID=2D8B360C-6A55-4F5E-84F9-4C6AC8A075D6, APP_NAME_14515=Gradle, __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0, SHLVL=1, HOME=/Users/sohmert}
16:04:21.599 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTING
16:04:21.599 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Waiting until process started: command '/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin/java'.
16:04:21.602 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTED
16:04:21.602 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...
16:04:21.602 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin/java''
16:04:23.015 [QUIET] [system.out]
16:04:23.015 [QUIET] [colouredOutputLogger] Error executing Static Binding Generator: Couldn't find '/Users/sohmert/tbd/wanwan/platforms/android/build-tools/sbg-bindings.txt' bindings input file. Most probably there's an error in the JS Parser execution. You can run JS Parser with verbose logging by executing "node '/Users/sohmert/tbd/wanwan/platforms/android/build-tools/jsparser/js_parser.js' enableErrorLogging".
16:04:23.046 [QUIET] [colouredOutputLogger] Detailed log here: /Users/sohmert/tbd/wanwan/platforms/android/build-tools/runSbg.log
16:04:23.046 [QUIET] [colouredOutputLogger]
16:04:23.047 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED
16:04:23.047 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/bin/java'' finished with exit value 1 (state: FAILED)
16:04:23.047 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute exec for :app:runSbg'
16:04:23.047 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute exec for :app:runSbg' completed
I find that I can still build for iOS, though, so that's a relief and an improvement from where I started (haven't tried with all the files put back, though, but I'm guessing it will work).
But what is runSbg doing here and why is is screwed up?
More importantly (to me), how do I fix it or work around it? I was supposed to release this app in the next couple weeks.
I'm having trouble with a Jenkins pipeline.
The thing is, it seems one of the steps is running in parallel with another (not intentionally):
I have something like:
...
step("build"){
bat [Visual Basic 6 compile command - vb6.exe file.vbp /outdir my/directory]
if(fileExists("my/directory/output.dll"){
println "SUCCESS"
}else{
error("error")
}
...
}
Ok, the problem is: it checks if the files exist before it's written by the compile command... If I put a sleep 10 before the condition, it always runs OK (for now), but obviously, I don't want to have a sleep command in my pipeline.
I don't know if I can control better the order os execution or if maybe the fault lies in the vb6.exe that creates a thread to write the output and then the main thread returns success before the output being written... does this make sense? Does anyone know how may I solve this problem?
My solution is to make the VB6 compilation step blocking.
This is what I run when working locally on my machine:
cmd /c VB6.exe /make someproject.vbp
And it is also the approach used by the Jenkins Visual Basic 6 plugin (I am the author). See this.
This question requires an understanding of both the Window's start command's behavior and a custom gradle ExecTask's handling of it.
Question
Why does start, with an application as a parameter, wait for the application to exit, only when being executed within a gradle ExecTask?
Explanation
From the command line, this works as expected (starts the application and returns, without waiting for the application to exit):
cmd /c myBuildEnvironment.cmd && start "some title for start" devenv.exe my.sln
Pretty simple, it calls a windows batch script to setup the environment and then launches my.sln in Visual Studio. Works just fine, not waiting for Visual Studio to be closed. And, this is what my gradle task is meant to achieve.
The same works "somewhat", using the following gradle ExecTask with start:
/**
* I know that the executable + args is replaced by commandLine. They're
* just there for readability.
*/
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
description 'Opens the VS solution, in the appropriate version of Visual Studio.'
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = [vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Gradle happily reports Build Successful, while Visual Studio remains open.
However, I say "somewhat" because start will actually ignore the executable argument and open my.sln with the default application for it, Microsoft Visual Studio Version Selector. So, after some research, I found that start assumes that the first parameter is the window title, then application, and lastly, the application arguments. So, I tried this:
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = ['some title for start', vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Everything works, start used the correct version of Visual Studio's devenv.exe, which varies based on the VC PlatformToolset, but...gradle sits in the background waiting for Visual Studio to close.
Why? How can I achieve all of the desired behavior?
Update
This might be an environmental problem. Apparently, on one dev's machine, the original gradle start task does stay open, as well. So, any invocation of start through gradle waits for it to complete, in a certain environment. The plot thickens...
Gradle is waiting for start to return is my guess, see this post - Run a background job from Gradle. Read also the comment after the answer, this is started from Java so if there is equivalent of & (run in background) for windows, it wouldn't work.
You can also try and wrapping it in a bat file, execute what you want in the bat file in the background then return right away so that gradle would be happy.
Hope this helps.
I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging