Gradle ExecTask and Windows start - visual-studio

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.

Related

OpenDDS - Solution builds fine, examples run, but IDL exes crash

I have successfully built OpenDDS 3.13.2 from source. Here is my environment:
Windows 10
Visual Studio 2017 (re-targeted Solution to SDK 10.0.17763.0)
Tried all Configuration/Platform combinations
I successfully used the configure script from the VS command prompt, built everything by opening the generated solution in the same command prompt, and finally ran the Messenger example (publisher and subscriber), and even configured it to use RTPS successfully.
However, when I try to create my own IDL and use the tao_idl, it crashes. Here's my test (using the proper environment from setenv.cmd):
> tao_idl (no args)
IDL: No input files
Second test:
> tao_idl Test.idl (crashes)
I get no error message, and am unable to locate logs or any indication of what went wrong. The same thing happens when I used opendds_idl.
What is the best approach to debug this, and/or are there pre-built binaries available for the IDL compiler(s) (both TAO and OpenDDS)?
After about a day of troubleshooting, I have determined a solution. Despite being able to call tao_idl and opendds_idl yourself, you should basically never do it. There are a good amount of command-line arguments needed to get both to work, and if they're not present, each exe will crash without the proper reasoning why.
I will add my steps below to create a new basic two-exe pub/sub project using OpenDDS:
Create your own IDL file.
Starting with the DCPS Messenger example, modify the .mpc file, replacing Messenger.idl with your IDL file name.
Create a new file called <your project>.mwc, and add the following contents:
workspace {
// the -relative and -include cmdlines make it so this workspace
// does not have to be in the $DDS_ROOT directory tree.
// tell MPC to substitute our DDS_ROOT environment variables for relative paths
cmdline += -relative DDS_ROOT=$DDS_ROOT
// tell the projects where to find the DDS base projects (*.mpb)
cmdline += -include $DDS_ROOT/MPC/config
}
Open a new VS command-line terminal and run $DDS_ROOT/setenv.cmd, or open a regular terminal if you have those environment variables set via Windows settings.
Navigate to your project directory and call: mwc.pl -type vs2017, replacing "vs2017" as needed for your build tool/IDE.
Open up the generated solution, and retarget it as necessary for your Windows SDK version.
Build the <your project>_IDL project first. If you notice in the output window, it is invoking the tao_idl and opendds_idl commands automatically. You can view the .vcxproj files to see the full command-line arguments that were the original problem.
Modify the publisher.cpp, subscriber.cpp, and DataReaderListenerImpl.cpp files to match your new IDL. Run the example as usual and ta-da!
For completeness, the full commands for both tao_idl and opendds_idl are as follows:
> opendds_idl -Sa -St "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>TypeSupport.idl"

Jenkins Pipeline: build steps not running concurrently?

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.

RegAsm.exe unable to register Dll through installshield 2016

We have installshield 2016 and inside this we are running installer script. That script is call through custom action.
So we are written following commnad to register "mydll.dll" as below mentioned command,
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe /codebase mydll.dll
The above command works perfectly fine when run manually through command prompt with administrative access.But fails through installer created using installshield script custom action.
To run command we use LaunchApplicationAndWait() and LaunchApplication() functions as
strcmd = "path to cmd.exe" + "cmd.exe"
strcmdopt = "path to regasm.exe" + "regasm.exe " + /codebase + path and name of dll
ret = LaunchApplication(strcmd, strcmdopt, windir, sw_normal, infinite, LAAW_OPTION_WAIT | LAAW_OPTION_SHELLEXECUTE)
similarly
ret = LaunchApplicationAndWait(strcmd ,strcmdopt,LAAW_OPTION_WAIT | LAAW_OPTION_HIDDEN)
My Question is why both command not work when run through installshield custom action scripts
Is the dll distributed with the installation? if so, is the file present in the installdir (or wherever) when the script is called? Maybe add some msg box for debug purposes to see if this condition is met.
Im using deferred custom action to register .dll via regasm and it works just fine.
You shouldn't be calling Regasm during the install. You should put the DLL as a key file in it's own component and set the COM Interop = True attribute. This will cause InstallShield to perform a regasm /regfile during the build and take the output and dynamically author it into the Registry table. During the install, MSI will simply copy the file and apply the registry entries and your done.
Note: Per MSDN doco custom functions are not called during regasm /regfile so if you are doing any wierd self registration inside your class you'll need to author that into the installer.

How can I use WebStorm to debug my node application across multiple processes?

My node application makes a call to child_process.exec, at which point I can't 'step into' each line of code any more, and none of the breakpoints in the node app being started by .exec seem to work.
How can I used WebStorm to debug this application as though calls to child_process.exec were like any other function call?
'exec' starts a new process so you need to pass '--debug=port' command line argument to it. Your code will look like child_process.exec('node --debug=8787 ' + __dirname + '/childProcess.js');
After that you can create a NodeJS Remote Debug configuration in Run | 'Edit Configurations' dialog and press 'Debug' button to connect to the child process.

Custom debug command in Visual Studio using a Makefile project

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

Resources