How to get a new process to know the location of dotnet in Linux?

Question

Our test and development team has been working to implement and test a new version of our software using .NET 6 that we will be releasing early next year. For test's part, we have had to upgrade all of our C# automated testing to be cross-platform compatible. One set of tests requires starting a new process and executing a console application we have as a supporting library. Below is the following code I am using:

#if (WINDOWS)
                string strCmdText = "/C \" SAT.FCCHandling -l" + password + " -i" + ip + " -xDeleteFCC\"";
#endif
#if (LINUX)
                string strCmdText = "-c \" .//SAT.FCCHandling -l" + password + " -i" + ip + " -xDeleteFCC\"";
#endif[![enter image description here](https://i.stack.imgur.com/6SYCA.png)](https://i.stack.imgur.com/6SYCA.png)
                using (var proc = Process.Start(new ProcessStartInfo
                {
#if (WINDOWS)
                    FileName = "cmd.exe",
#endif
#if (LINUX)
                    FileName = "/bin/bash",
#endif
                    UseShellExecute = false,
                    RedirectStandardOutput = true,
                    CreateNoWindow = true,
                    Arguments = strCmdText,
                    WindowStyle = ProcessWindowStyle.Hidden
                }))
                {
                    proc.WaitForExit();

                    if (proc.ExitCode != 0)
                    { Assert.Fail("There was an issue Inserting an invalid FCC."); }
                }

I have been using VSCode in Linux to debug problems that arise. When the code above is executed in Linux (specifically in Ubuntu 20.04), in the developer console it's indicating that the location for .NET is not found:

We also use TShark for packet capture in some testing. The methodology of code is used in launching TShark as a new process. I bring this up not because TShark is written in C# with .NET 6, but merely to point out that this approach for launching an application does work.

The problem, as I perceive it, is this child process being launched has no knowledge of environment variables. If I launch the application directly from the terminal in the binary directory, the application runs just fine.

I have done some digging and research online before posing this question. I haven't found anything that is exactly similar to my problem. I have tried a couple avenues based upon what I have read online, but these don't seem to be the right solution:

• Assigning all variables to the StartInfo of the new process.
• Assigning specifically EnvironmentVariables["TEST_ENV"] = "From parent"; to the Process.StartInfo. I saw something online that seemed to indicate that passing environment variables down to the child process was a necessity as the variables are instances.
• Using the StartInfo.Verb = “runas” to elevate the privileges of the process.

I know that the solution is probably an obvious one that I'm just not seeing. I am not a Linux expert by any stretch of the imagination and have been having to learn as I go through this release. Any guidance is much appreciated and I'm happy to provide further information if necessary. Thank you.

Answer 1

I spent some time during the holidays researching, debugging, and testing. I was able to find a solution to my problem. Several things:

• In order to know exactly what was happening to my process on launch, I attached two threads to the standard output and standard error of the process I start.
• This lead me to discover that the file location was unknown to bash when calling it.
• With this resolved, I discovered that I needed to execute 'chmod +x ' before executing the console application.

It's worthy of note that by trying to debug my problem from a .NET 6 console app (launching another console app) was injecting a different kind of problem into my existing problem. Using my existing NUnit testing that calls the console app was what lead me to the discovery noted above.

Lesson learned: If trying to call a .exe in Linux from your .NET 6 application by starting a process, be sure to make the file executable before you try calling it with bash or another shell.