Visual Studio has a relatively new way of doing Linux builds, using the local WSL system. This platform toolset is called WSL_1_0
What in a remote build was called "Remote Pre-Build Event" is now called "Wsl Pre-Build Event" (in the UI..still Remote whatever in msbuild, apparently) and it works basically the same, but with execution occurring in WSL on the local machine rather than on a linux machine.
Aaaand...any script output seems to be swallowed (vs. running on a remote machine where it was displayed in the build window):
1>Target RemotePreBuildEvent:
1> Invoking 'echo "me : stuff error 567 HELLO"', working directory: '/mnt/s/buildroot/CoreTech/ThirdPartyTools/Encryption/Rijndael/Project/Linux'
1>Target ClCompile:
1> Starting remote build
If I replace this with a script, it is executed..but the output is swallowed.
I've tried redirecting to stderr both within the script and within the command and it seems to change nothing. I've also adjusted Tools->Options->Project and Solutions->Build and Run output verbosity as high as I'm willing to (Normal) with no changes.
Anyone have any ideas on solving this?
I've also adjusted Tools->Options->Project and Solutions->Build and
Run output verbosity as high as I'm willing to (Normal) with no
changes.
Normally it's recommended to change the Verbosity to Detailed and higher to see more details. And this is the only option I know in latest VS2019 16.3.7 can control the behavior of output log.
So you can change it to Detailed to check if there's more info to be displayed in output window.(For some reason,my configuration fails for the wsl.exe, so I can't test it myself whether this option can work)
And if the echo info is still not shown, I guess this scenario is not be supported for now since it's quite a new feature. Just post your feedback in DC as the Give Us Feedback in this document suggests. The team there would look and consider about supporting that. May it makes some help :)
Related
I have run this custom action with Installshield Limited Edition for Visual Studio in the past and it has worked. But now when I try this with Installshield 2016, this custom action gives me a 1722 error and rolls back the installation. The log file doesn't give any more detail than "failed with error 1..." and the 1722 error.
My custom action setup via the Wizard -
Working Dir: InstallDir
FileName & Command Line: "[SystemFolder]cmd.exe" /c "[INSTALLDIR]somefilename.exe" "'%r' '%keyname=keyname' '%keydll=some.dll' '%appexe=[INSTALLDIR]differentfilename.exe'"
What this is supposed to do is run somefilename.exe from the command line, with parameters "%r", "%keyname", "%keydll" & "%appexe".
When I run it on the command line directly so -
"C:\Program Files (x86)"\somefilename.exe "%r" "%keyname=keyname" "%keydll=some.dll" "%appexe=C:\Program Files (x86)\differentfilename.exe" - it runs fine.
I think I am missing some quotes someplace and I have tried various combinations with no luck.
Any ideas what I am doing wrong?
Thanks in advance!
Thanks for the suggestions #PhilDW.
I could possibly take out the cmd jacket and just run the exe and try.
I finally got it working though, by changing some quotes etc. Here's what the final FileName & Command Line argument looks like:
"[SystemFolder]cmd.exe" /c start "" /d"C:\Program Files (x86)\foldername\" "somefile.exe" "%r" "%keyname=something" "%keydll=something.dll" "%appexe=C:\Program Files (x86)\otherfilename.exe"
Hope this helps someone.
A few suggestions:
You should post the verbose MSI log section relating to this because it should show the complete resolved command line, assuming that you have created a full verbose log and not a partial log.
It's not clear why you need to run this program with a cmd jacket. If it's a plain Windows program just run the executable as a custom action.
When you run from the interactive user explorer shell you get some infrastructure (such as working directory) that you do not get with a custom action started by an msiexec.exe process. This matters because you have not specified an explicit full path to some.dll, so it's not obvious it can find the file.
It might be useful to say something about where this custom action runs and its type. For example if it's turned into an immediate custom action (all VS custom actions are deferred) then it will fail because no files have yet been installed. Likewise, if it's deferred but somehow before the InstallFiles standard action it will fail.
All custom actions run by Visual Studio generated projects are deferred and run with the system account in a per-system "Everyone" install. If your custom action requires elevation then it must also be deferred and the MSI must show a UAC elevation dialog, because otherwise it may well run but fail with access errors. It may have become a non-elevated per user install.
I currently have a problem with a shell step in a workflow script hanging. The step appears to complete but the workflow doesn't move on, the Jenkins java process also begins to consume large amounts of CPU.
Jenkins is running on an OS X box and the sh step is a call to xbuild to build a Xamarin app.
def shell = "xbuild /p:Configuration=${buildConfig} /t:Build ${_solution.getPath()}"
sh("${shell} >> ${_logFile.getPath()}")
The contents of the log file suggest that xbuild completed succesfully but the workflow never moves on from the sh step.
Could anyone suggest a strategy to find out what is causing it to hang?
This turned out to be caused by a tight loop I had that was executing after the sh step completed.
My recommendation to anyone else experiencing a problem like this would be to make good use of logging to the console output so you can see exactly where the build is stuck.
Some environment details:
LINQPad v4.47.02(AnyCPU)
OS Name Microsoft Windows Server 2012 Standard
Version 6.2.9200 Build 9200
System Type x64-based PC
I am trying to figure out how I might diagnose an issue I am encountering when launching a script via the lprun.exe command line utility. When I run the script from the IDE interactively it runs and completes without any exceptions.
When the same script is run under the same user from the command line using: lprun.exe
I get this output.
c:\SQLTasks\Linqpad\Demographics\Demo_GenerateDemographicsSubset.linq(880,20) :
error CS0029: Cannot implicitly convert type 'string' to 'char?'
Due to how LINQPad compiles the script I cant easily locate the area in my script that might be causing this and I'd really like to know if possible what mechanisms might allow it to work interactively and fail from the command line.
Please refer to the discussion on the LINQPad forum: http://forum.linqpad.net/discussion/437/lprun-exe-runtime-error-doesn-t-hapen-when-script-is-run-from-linqpad-ide#latest
Edit: this was due to a bug in how LINQPad reads configuration settings in command-line mode. The bug was fixed as of v4.48.
I'm following this tutorial set to set up Moai for Android porting. When I run
./make-host.sh –p com.gamefromscratch.moai
in Cygwin to build the Android host it returns an error of
build.sh: line 17: ndk-build: command not found
I'm 98% certain everything has installed correctly and I've been following the instructions exactly as written. When I look in the shell script line 17 is
use_fmod="false"
I've never had to use shell scripts or set up anything like this before and my scouring of the internet has failed to yield a result.
As a side note, Moai runs perfectly and I haven't had any problems with getting that to work.
I've solved the issue! When I went to look for the environment variable in Windows (Computer -> right click -> properties -> Advanced System Settings -> Environment Variables), I found that the variable path was there but was listed as ‘%PATH;c:\android-ndk’. As an experiment I changed it to just c:\android-ndk and rebooted the computer. I then ran the line to have the host run and it ran through the process without a hitch. The only difference is that instead of untitled-host my file is called host-source and instead of settings-local.sh my file is called d.settings-local.sh. Outside of those minor file name changes everything else is the same.
I am new to Hudson with PSEXEC, i am using hudson in my computer, i want to run batch file on remote computer from hudson build.
I used PSEXEC to run batch file on remote computer,when i executed from command promt it working successfully.But same i did from Hudson build its hanging..it's not doing anything.so please give any suggestions is there any other way we can handle this.
I want to do this quikly...urgent
Anyones help is appreciable
thanks in advance.
Could it be that psexec is waiting for a user entry? In this case hudson will hang.
Does Hudson runs with your user credentials? if not lunch a command Prompt with the credentials Hudson is running with and see what happens if you call psexec. If hudson runs on the local system account, you can't start a command prompt with it. Than try to run Hudson with your credentials and see what happens.
BTW, did you check Hudsons log files (just in case that there might be something)?
I had the same problem where PSEXEC simply hung.
The solution i found (after trawling for AGES) was to add the parameter -accepteula to the PSEXEC called. Hudson stopped hanging after that.
Very frustrating.
maybe it is too late, but I thought I will post it for others who have the same problem.
Psexec has problem running from any CI server, doesn't matter what CI server you have, is it Hudson, Teamcity, ...).
Psexec hangs when run from the build server.
It doesn't hang for all commands, but with some commands , psexec will hang.
The problem resides with how psexec will read the output of the remote running command.
The ultimate solution is to use other tools than psexec.
You can check this blog of this solution.
But if you need a simpler solution, and you don't care about the output of the command, I came up with a simple solution that suppress the output of the psexec.
You can write a small c# program that will run the psexec command, suppressing its output.
I blogged about that here
I thought I would respond to this since I was having the same hanging problem with TeamCity and psExec. Since I believe it is actually an issue with Java executing psexec, it should apply in the case of Hudson as well.
While I ran into the accepteula issue was early on, you only need to agree once and it sets a registry setting. As user327759 indicates the -accepteula switch in the script would cover your basis the first time and for ever after.
If this doesn't fix your problem, which it didn't in my case, you need to add the "-i" command switch. ex: psexec -i \ServerName "C:\folder\file.bat"
For context regarding this solution, I have included my backstory:
I was able to execute this PsExec command just fine via a MsBuild task, via a .Net wrapper and via straight command prompt usage, but TeamCity would just hang on the execution. It seems that Java is expecting some response on standard in, when it invokes the psexec exe. On the remote server I would see the psexecsvc process fire up and register in the services console appropriately, but then it would stop. After reading many posts such as this one, and struggling for far longer than I would care to admit, I eventually tried -i option, despite not needing this in any other execution scenario outside of TeamCity. The psexec documentation indicates that -i will "Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session." It is still unclear to me why this makes all the difference for TeamCity.