Any way to prevent NuGet downloads in lprun from writing to stderr?
We use LINQPad pretty extensively as a component of our devops processes through the command-line runner. Up until recently, I've been using persistent build agent VMs, but I recently switched to transient ones and it's exposed a problem. Since each build is performed on a fresh VM image, LINQPad needs to download NuGet packages specified in the script on each build. Unfortunatly, the message that a package needs to be downloaded gets sent to stderr, so the overall build pipeline thinks that there was a problem with the build:
Is there any way to either suppress the lprun errors about package downloads or send them to stdout instead?
Answers
-
Are you able to check the errorlevel returned by lprun? This will indicate whether there's been an error or not.
-
@JoeAlbahari said:
Are you able to check the errorlevel returned by lprun? This will indicate whether there's been an error or not.Thanks for getting back to me, Joe! Sorry for the delay - this problem is finally back on my radar again. At the moment, our use of lprun is through a build script wrapper (think Bicep or Terraform), so I have limited control over how command line output is treated. That's part of the problem, the stderr output "bubbles up" to the build script, so the build script thinks that part of the process has failed.
If the stderr output can't be changed to stdout or suppressed, is there a way to prepopulate the NuGet cache that LINQPad uses? Does it use the standard NuGet package cache or a custom one? I'm wondering if I parse the LINQPad file (we already do this to substitute database connection strings at runtime), can I pull down packages myself before running lprun so that LINQPad doesn't need to pull them down itself (and subsequently output to stderr)?
-
I'll add a -noinfo switch to LPRun in the next LINQPad 9 build.
-
9.3.1 has now been released - let me know how you get on.
