In a C program in Linux, I can use the first argument to get the command that was used to run a process. Is there a way to do something similar for C#?
For example, if I use dotnet run/dotnet to run the program or double-click a published executable, is it possible to retrieve that programmatically (dotnet run, dotnet <…>.dll, or <executable path>)?
I can get the DLL/EXE that is running with System.Reflection.Assembly.GetExecutingAssembly().Location, but that doesn't help much when the user is running the project directly with dotnet run instead of dotnet <…>.dll.
You can use the Environment.CommandLine property to get the command line for the current program. Note that in the case of dotnet run myassembly.exe, the dotnet run part is dropped. E.g. if the command line is dotnet run myassbembly.exe foo bar, the Environment.CommandLine property will contain myassembly.exe foo bar.
Related
When using the VSCode extension Code Runner for my C# .NET 6 console app, after hitting the run button, the following command runs in the terminal:
❯ dotnet run "/home/USER/code/c#/MyApp/Program.cs"
Hello, World!
~/code/c#/MyApp ❯
I am wondering how to remove the file path after 'dotnet run'. Given that I am already in the console application directory, I would like for the extension to only execute the 'dotnet run' command, which would achieve the same result. I can demonstrate this by running the command myself without including the file path to the 'Program.cs' file at the end:
❯ dotnet run
Hello, World!
~/code/c#/MyApp ❯
This is purely an aesthetic matter, but it has been bugging me a lot and I've spent more than two hours now trying to figure out a solution for this.
Go to settings in vs code
In the search bar, type "user se"
You will see Edit in settings.json, click on it
Add "code-runner.showExecutionMessage": false,
Enjoy
Go to Vs code setting
Uncheck Show Execution Message option
I am running an inherited project written in C# inside Visual Studio Code. In order for this application to run, it needs to take command line input (-t, -h, etc). How do I test this from inside Visual Studio?
Currently (I've been learning dotnet, C#, VS, etc as I go) I have a hello world program I can run from vsc's terminal. For a reason I haven't been able to pinpoint, probably how I installed it, dotnet run isn't recognized - I have to feed it an explicit path to dotnet.exe: C:\Program Files\dotnet\dotnet.exe run
How can I do this when the program requires command line input? My shot in the dark of C:\Program Files\dotnet\dotnet.exe run -t predictably didn't work, but I'm not sure what else to try.
Thanks!
If you are using dotnet.exe run to start your application you need add the -- switch statement to instruct dotnet.exe to pass the arguments to your application. For example
Microsoft Documentation
dotnet.exe run -- -arg1 -arg2 (etc) notice the -- after the dotnet arguments and before your program specific arguments.
GitHub Issue
Run with Terminal
When you run your code using terminal you must add ' -- ' to tell dotnet you are running your code with an argument/s
C:>dotnet run -- <your arguments here>
Run with Debugger
Locate your .vscode folder inside your project if not create one.
Open the launch.json file
You will see a json object and add your arguments inside the "args" key.
launch.json
"configurations": [
{
"name": ".NET Core Launch (console)",
"args": [], // PUT YOUR ARGUMENTS HERE
...
}
]
I tried to add a comment to Nico's answer but I lack sufficient reputation points. I was confused by the dash character in front of each arg: "-arg1 -arg2 (etc)". For clarity I would like to point out that .NET Core 2.1 seems to not need this. In the case of my console app, it takes a date for the first arg, an integer for the second, then an operator (+ or -) for the third arg. If I entered the following:
C:\>dotnet run -- -7/13/2018 -30 -+
I found that the leading dash in front of each arg was passed into the program along with the intended arg and I ended up trying to date parse "-7/13/2018"
I got the expected result when I entered it like this:
C:\>dotnet run -- 7/13/2018 30 +
Since OP is specifically asking about how to do this in Visual Studio Code, they are likely using VSCode's run feature (not the dotnet CLI as other answers assume), to run their application. In this case, the proper way to supply command line arguments is via the .vscode\launch.json file.
Add an args array attribute to your configuration and populate it with the arguments you would like to pass.
"configurations": [
{
// ... ,
"args": ["-arg1", "-arg2"]
}
Right click on your project
Click Properties
Click Debug in the Properties window
Under "start options:"
Add a "Command Line Argument:" = run -t
Add a "Working Directory:" try the bin\debug directory
I am running an inherited project written in C# inside Visual Studio Code. In order for this application to run, it needs to take command line input (-t, -h, etc). How do I test this from inside Visual Studio?
Currently (I've been learning dotnet, C#, VS, etc as I go) I have a hello world program I can run from vsc's terminal. For a reason I haven't been able to pinpoint, probably how I installed it, dotnet run isn't recognized - I have to feed it an explicit path to dotnet.exe: C:\Program Files\dotnet\dotnet.exe run
How can I do this when the program requires command line input? My shot in the dark of C:\Program Files\dotnet\dotnet.exe run -t predictably didn't work, but I'm not sure what else to try.
Thanks!
If you are using dotnet.exe run to start your application you need add the -- switch statement to instruct dotnet.exe to pass the arguments to your application. For example
Microsoft Documentation
dotnet.exe run -- -arg1 -arg2 (etc) notice the -- after the dotnet arguments and before your program specific arguments.
GitHub Issue
Run with Terminal
When you run your code using terminal you must add ' -- ' to tell dotnet you are running your code with an argument/s
C:>dotnet run -- <your arguments here>
Run with Debugger
Locate your .vscode folder inside your project if not create one.
Open the launch.json file
You will see a json object and add your arguments inside the "args" key.
launch.json
"configurations": [
{
"name": ".NET Core Launch (console)",
"args": [], // PUT YOUR ARGUMENTS HERE
...
}
]
I tried to add a comment to Nico's answer but I lack sufficient reputation points. I was confused by the dash character in front of each arg: "-arg1 -arg2 (etc)". For clarity I would like to point out that .NET Core 2.1 seems to not need this. In the case of my console app, it takes a date for the first arg, an integer for the second, then an operator (+ or -) for the third arg. If I entered the following:
C:\>dotnet run -- -7/13/2018 -30 -+
I found that the leading dash in front of each arg was passed into the program along with the intended arg and I ended up trying to date parse "-7/13/2018"
I got the expected result when I entered it like this:
C:\>dotnet run -- 7/13/2018 30 +
Since OP is specifically asking about how to do this in Visual Studio Code, they are likely using VSCode's run feature (not the dotnet CLI as other answers assume), to run their application. In this case, the proper way to supply command line arguments is via the .vscode\launch.json file.
Add an args array attribute to your configuration and populate it with the arguments you would like to pass.
"configurations": [
{
// ... ,
"args": ["-arg1", "-arg2"]
}
Right click on your project
Click Properties
Click Debug in the Properties window
Under "start options:"
Add a "Command Line Argument:" = run -t
Add a "Working Directory:" try the bin\debug directory
I'm trying to run the latest Asp.Net 5 samples (currently 1.0.0-rc1-update1) from powershell on Windows 10. I have the active and default DNX set as the CLR x86. I have run the dnu restore command against each of the 3 projects and this has completed without error.
If I run the command dnx run for the console sample this works fine. However, when I then run the command dnx web from within either of the web project's folders I get the error message;
'Microsoft.AspNet.Server.Kestrel' does not contain a static 'Main' method suitable for an entry point
The samples are pretty basic and so I assume it must be part of my dnx configuration. But why is this happening and how do I fix it?
The cause of the issue is a strange one actually but it looks like the dnu restore command is case-sensitive. I assume this has something to do with it having to run on Linux too but I'm not sure.
In powershell my current path was all lowercase but my folder structure wasn't. Whilst in webhello , if I ran the command cd ..\WebHello and then ran dnu restore, the restore worked fine and the dnx web command also then ran fine.
Interestingly, if I ran cd ..\webhello, the dnx web command still works fine.
Relative to same problem of Run Mono Application on Startup with Upstart, here this something that I don't understand:
In "startup applications", (1) I added a new program (Terminal) with the command:
gnome-terminal
Ok, the terminal opens on Ubuntu startup. (2) Then I changed the command to:
gnome-terminal -e nano /home/user/Documents/test.txt
Ok, the terminal opens with nano editor. (3) Then I changed the command to:
gnome-terminal -e /usr/bin/mono /usr/lib/IndsysAndon/IndsysAndon.exe
And the terminal opens and closes after 1 second, without run de application.
But, when I pastes the command of (3) in a terminal opened in (1), the application runs. Why this happens? Is needed a time to load all dependencies in startup? Thanks
gnome-terminal expects the command to execute, along with any arguments, as a single string passed via the -e option.
If you write
gnome-terminal -e foo bar
then the command to run will be foo and the bar will be considered an argument to gnome-terminal itself. (Remember that options can appear in any order.)
If you want to pass arguments to the command, you will need to make sure they are passed as a single string to gnome-terminal. You can do that by quoting:
gnome-terminal -e "foo bar"
Unfortunately gnome-terminal doesn't use a more user-friendly way, where any subsequent arguments after the command would automatically be considered arguments to the program and not to gnome-terminal.