I have a C# project in Visual Studio 2010 and I wish to run/debug my application with a specific environment variable in place.
This strikes me as a feature that probably exists somewhere, but I can't find it despite some extensive searching. This question relates to 2008 and below and doesn't contain an answer that helps me. This question relates to the build process, not the act of debugging/running.
I appreciate a work-around would be to start my IDE with the environment variables in place, but I'd rather control this from the IDE. Is this possible?
It's not as clean as setting it from outside the application being debugged, but you can add to the Main something like this (NB I'm a VB programmer):
#if (DEBUG)
Environment.SetEnvironmentVariable("YourVar", "YourVal");
#endif
This is possible in the C++ IDE, not the C# IDE. I'd guess it was omitted intentionally because C# has better ways to configure a program. Environment variables are awkward since they require an installer that tinkers with the user's system environment when the app is deployed. That's brittle, another installer can easily destroy that and they often do.
The C# way is to use an application setting. Project + Properties, Settings tab.
A possible alternative is to use a command line argument. You'll get it in your Main() method, you specify a value in the Project + Properties, Debug tab.
You can still get what you want with a trick that takes using the C++ IDE to start your program:
Add a new project to your solution and select the Visual C++, General, Makefile project template.
Click Finish right away, the wizard asks too many questions.
Right-click the added project, Properties, select the NMake node.
Edit the "Build Command Line" setting, and set it to "echo Done".
Edit the "Output" setting, set it to the full path of your C# executable.
Select the Debugging node, change the Debugger type to Managed Only.
And you'll see the one below that, what you want, edit the "Environment" setting.
Right-click the project again, pick "Set as Startup Project".
For C# debugging with environment variables under Visual Studio 2013, what I do is open up the "Developer Command Prompt for VS2013" in the start menu under Visual Studio. From the command prompt I set the environment vars that I want and then run "devenv.exe" to launch Studio. Next open a solution and start debugging.
Keep in mind that if you want to change your environment vars you will need to stop debugging, quit visual studio and then tweak the vars in that open command prompt, then start again. Remember that an environment moves forward as a process (CMD.EXE) launches the next (DEVENV.EXE) and then the next (YourApp). Changes at the very beginning aren't moved forward, you need to start the chain over.
Related
When I am using python in Visual Studio Code, I have the run button at the top right, however, when I am in a c# file, the run button is not there.
Why is that, and how can I fix it?
Since VS Code is a tool built with C# in mind, having the Run hidden is not a disadvantage but rather to dedicate a complete UI for Running and Debugging your C# code. The Run and Debug UI which you can access from the left menu gives your this capability with comprehensive tools to help you debug.
Activating this tool to run correctly involves two setups, one-time setup and a per-project setup (Don't let this intimidate you, it is just a click of a button)
First Time Setup
1. Install .NET command line tools
Install the .NET Core command line tools (CLI) by following the installation part of the instructions here: https://dotnet.microsoft.com/download
2. Install C# Extension for VS Code
In the extensions tab, enter C# in the search box and press Enter. Select the extension from Microsoft and click on Install. If you have previously installed the C# extension, make sure that you have a recent version.
3. Wait for download of platform-specific files
The first time that C# code is opened in VS Code, the extension will download the platform-specific files needed for debugging and editing. Debugging and editor features will not work until these steps finish.
Once Per Project
1. Get a project
You can start from scratch by creating an empty console project with dotnet new. Begin by opening the terminal in Visual Studio Code (View->Integrated Terminal) or CTRL+` and type these commands:
cd ~
mkdir MyApplication
cd MyApplication
dotnet new console
2. Open the directory in VS Code
Go to File->Open Folder (File->Open on macOS) and open the directory in Visual Studio Code. If this is the first time that the C# extension has been activated, it will now download additional platform-specific dependencies.
3. Add VS Code configuration files to the workspace
VS Code needs to be configured so it understands how to build your project and debug it. For this there are two files which need to be added -- .vscode/tasks.json and .vscode/launch.json.
Tasks.json is used to configure what command line command is executed to build your project, and launch.json configures the type of debugger you want to use, and what program should be run under that debugger.
Launch.json configures VS Code to run the build task from tasks.json so that your program is automatically up-to-date each time you go to debug it.
If you open the folder containing your project, the C# extension can automatically generate these files for you if you have a basic project. When you open a project and the C# extension is installed, you should see the following prompt in VS Code:
Clicking Yes when you see this prompt is all that you really have to do when you open a new dotnet project. If the files are there already you won't be prompted.
Clicking Yes on this prompt should add these resources. Should you need to add those resources manually please check the reference link below.
4. Start debugging
Your project is now all set. Set a breakpoint or two where you want to stop, click the debugger play button (or press F5) and you are off.
Reference Link: https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger.md
try pressing f5, should do the same thing as the run button
I have created a small program in C# WinForms that runs fine when I start it in Visual Studio 2017. But when I build the solution and double click the .exe, nothing happens, no screen appears, even the task manager doesn't see it. No errors. It's like it doesn't do anything! My only guess is that I built it wrong because I used Nuget to install newtonsofts JSON.NET in the solution. Do I need to do anything differently or should just building the solution work?
[solved]
today i learned the difference between the bin and obj folder, thanks to everyone for helping
Based on your comment:
it is in the obj/debug folder of the project
It sounds like you're running the wrong .exe. The obj folder is used for temporary/misc. files from the build process (see What is obj folder generated for?).
Instead, you want to run the exe within bin\Debug, if "Debug" is the configuration you're building for. You can see which configuration at the top of VS.
Like others have also mentioned, make sure that Newtonsoft.Json.dll is being copied to that output directory as well. Programs and their dependencies need to be together, generally speaking. Otherwise, your exe will not know where to find the JSON code it needs to function.
99% of the time, you should pretend the obj directory isn't even there.
If that still isn't pointing you in the right direction, run the app from a command window. Any exception should get printed to it and the window will remain open for you to examine (and this has the benefit of not needing any additional logging or exception handling code to see this error).
For example, I wrote up a bad application that get a NullReferenceException in a method called Test that is called from Main. As you can see, the stacktrace is easily visible, even though my app has crashed (credit to ColinM for bringing this up originally).
I believe that there's a problem with the startup module. Follow the steps below
Open your Solution in visual studio
Double click on properties
Select output type to Windows Application
Make sure to set the startup object as follows
I hope it helps
I think there is only one reason
There is a command line argument predefined in Visual Studio. Your application uses this argument to be executed, without it, it closes itself too quickly and you even can't see your application opened.
Right click on your project in VS -> Properties -> Debug and see if there is a value in command line arguments
exe and their supporting files should be in the bin folder. Do not copy only exe from bin folder and try to run it. It is a good idea to write some exception code to get the detail.
For future reference, yet another reason (that I have experienced) can be
System.Diagnostics.Debug.Assert();
statements. In my case, the program executed normally when started from VS but when I run it by clicking its .exe (created in the Debug Mode) then it hung/freezed. No exceptions, no printed logs. Frustrating. Then I checked the Windows Event Viewer (Our true friend). It explicitly displayed the problem and the culprit was a Debug.Assert() statement.
The lesson learned again: Check
Windows Event Viewer > Windows Logs > Application
especially when your app hangs/freezes/deadlocks or when no app logs are available.
I've created a .NET 4.5 console application (an .exe file) with c# that processes some data in various files. The whole thing runs in less than one second. I have a problem with a testing version of the .exe that I'd like to step through in the Visual Studio 2013 debugger using particular input files (the filenames are passed as command line arguments). I can't do an "Attach to process..." since the process has completed too quickly to attach to it. How do I debug in this case.
Note that I'm from the python world, and the python equivalent of what I'm trying to do is python -m pdb pdb_script.py.
Thanks for any advice!
Right click on your project and go to "properties".
Then select the "debugging" tab on the left-hand side.
There's a box where you can input the desired command line arguments for use when running in debug mode.
EDIT: If you're asking how to start the debugger, then add some breakpoints to your code, then right click on the project in your solution and pick Debug > Start New Instance.
Alternatively you can right click and choose "Set as Startup Project", after which you can start debugging with F5 or the "Start" button at the top of the UI.
Add the following line in your code:
System.Diagnostics.Debugger.Break();
This will allow you to debug your application before it ends.
In Visual Studio, you can add commandline arguments before starting a debugging session by right-clicking your project, selecting properties and then going down to the debug tab.
Then you can start it in Visual Studio with f5
If that's too much trouble (because you are going to change the arguments a lot), you could do something like adding a Console.ReadLine to your program at the beginning that will give you a change to attach a debugger. You could even have an extra command line argument for debugging that will only pause for you to attach the debugger if you pass that argument.
Is there a way to see what the CSC (or VBC) parameters are, when building an application using the Visual Studio?
Visual Studio calls CSC.exe/VBC.exe behind the scenes. I want to know if there is a way to see that call.
I need this info to replicate the equivalent Build script using the command line.
I set the different levels of verbosity for the build, still I do not see any CSC.EXE call in the output window.
I'm really surprised why Microsoft did not put an easy way to see the underlying CSC command.
AJ if I go through your steps I get:
I do not see any reference to CSC
OK here is how I resolved this:
First I went to tools and options and set the verbosity to detail. (After this point still build output was empty).
Then I got Service pack for VS2010.
I also had similar issue for Visual Studio 2012 I had to get "update 4" to see the logs and CSC.EXE ion the output.
I think what you're looking for can be set up in your VS environment options. Under the Tools menu, select "Options," then "Projects and Solutions." Make sure "Show Output window when build starts" is checked.
Then, under "Projects and Solutions," select "Build and Run" and change the level of "MSBuild project build output verbosity." I changed it to "Detailed" as an experiment, but you can fiddle with the levels to get what you want.
Then, when you build/rebuild your solution, the easiest thing to do is to place your cursor in the build output window and search for "csc" (or "vbc" for VB). You should be able to see the entire command line call to the compiler.
EDIT
To answer your comment, change the "Show output from" drop-down option at the top of the output window from "Debug" to "Build" and do a build/rebuild without running the application in debug mode.
Here's what I did:
From VS2010 > new C# Project (from Other Project Types > Extensibility > Shared Add-in) > some basic configuration in the Connect class
After that I set in the project properties > debug > start external program, the path for winword (C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE)
When creating a shared add in, the setup files are in a separate project, in the same solution. so i did a build for the add-in, and installed it.
when i start word (separately or from Start with debug from visual studio) the add-in runs fine, but it can't seem to hit any breakpoints?
If I modify something and do just Build, when i start word again, the changes are there, so it must be the correct dll that word is loading
Question is of course, how do i get breakpoints to work?
First, breaks won't work at all if you run through an installed instance of the addin. You HAVE to start the addin from inside VS to be able to do any debuggins (ok technically not completely true, I +THINK+ you can "attach" to a running instance but I've never debugged that way.
You'll want to make sure you're in DEBUG build configuration. Release mode won't necessarily set things up to allow debugging.
You should be able to REBUILD the entire solution before starting it. Rebuilding the solution will register things with the registry so that word +SHOULD+ find you're add in properly.
Finally, make sure that, during all your testing runs etc, Word hasn't disabled your add in. Check Options/Addins/Com Addins and make sure your in the list and enabled.
If you're addin fails for some reason, word has a habit of disabling it and from then on not loading it unless you reenable.