I have written this code in my console application:
#if DEBUG
args = new[] {"4478676e34432432434"};
#endif
if (args == null)
{
Console.WriteLine("Please enter IP for single testing for now.");
}
When the tester person wants to test my app and forgets to enter the argument to run the app with I still want him to see that message. But now it does not do that. Does it mean should I put the build also on "Release"? Does this "DEBUG" mean if we are in VS IDE or does it mean if we are in Debug/Release build?
You can give them a release build, instead. This is probably best, for reasons that #JoeEnos pointed out in his comment on your question.
Either way, it might be better to specify the command line arguments in the project properties, instead of in a conditional #if DEBUG. However, Visual Studio adds them to the local project properties, so it won't be checked in with the project, meaning that other developers won't have the command line arguments you used. In my experience, I've found this to be a good thing.
For information in adding command-line arguments for debugging, look at this MSDN entry
To specify command-line arguments for debugging
With a project selected in Solution Explorer, on the Project menu, click Properties.
Click the Debug tab.
In the Command line arguments field, enter the command-line arguments you wish to use.
Does this "DEBUG" mean if we are in VS IDE or does it mean if we are
in Debug/Release build?
It means the application has been built with the Debug configuration. By default the DEBUG symbol is defined only for this configuration (although you can change this in the project's build settings).
If you want the tester to see the message then provide him/her with a Release build. Use the debug version for your own development tests/purposes.
Related
I am wondering if I am meant to see anything in my Debug output when running in release mode?
The below image is a screenshot of my output window when I am running in Release configuration.
Seeing debug stuff makes me think that I am not actually running a release compile, Is there a way that I can be sure that I am definitely running a release mode?
Short answer
These appear to be Trace messages, not Debug messages, so they appear even in release builds.
Long answer
Let's see what's going on by investigating the various contextual meanings of the term "Debug" here.
The "Debug" Build Configuration
First, there's the context of the drop-down with the "Debug" and "Release" options in Visual Studio. Those options are build configurations. To understand the significance of this option, double-click the "Properties" node for your project and change to the "Build" page.
This page (and some others) can have settings specific to a certain build configuration. You can see settings for each configuration with the drop-down on the page (it defaults to whichever build configuration you're currently using).
There's nothing special about the names "Debug" and "Release" - those are just default configurations, with default settings for those scenarios. You can change the settings for a configuration. You can also define your own build configurations, but doing so is out of the scope of this answer. Finally, these settings are also parameterized by a simliar target platform (e.g., "AnyCPU", "x86", etc.), but for this answer I'll assume all builds are using the same platform setting.
The "DEBUG" Conditional Compilation Symbol
C# has conditional compilation - the ability to compile different sections of code depending on symbols that either are defined or undefined at compilation time. For instance, this constant has the value "A" if MY_SYMBOL_NAME is defined, or "B" otherwise.
public const string MyConst =
#if MY_SYMBOL_NAME
"A";
#else
"B";
#endif
The top three settings on the project's "Build" page control these symbols. In particular are the "Define DEBUG constant" and "Define TRACE constant" - which really refer to compilation symbols. By checking these, the selected build setting compiles with the DEBUG and TRACE symbols defined, respectively.
By default, both "Debug" and "Release" configurations define TRACE, but fittingly only "Debug" defines DEBUG.
The Debug Class
Conditional compilation extends specifically to the members of the System.Diagnostics.Debug and the System.Diagnostics.Trace classes: calls to these classes' methods will only be compiled when the appropriate symbol is defined. So this:
Debug.WriteLine("!");
is treated like this:
#if DEBUG
Debug.WriteLine("!");
#endif
These methods write to so-called "trace listeners", which can be configured either in code or in application configuration files.
So if the text you're seeing is written by calls to Trace, then you'll still see it, even in the Release configuration. Of course, this means that this logging will remain in shipped versions unless you explicitly disable the "Define TRACE constant" setting.
Start Debugging vs. Start Without Debugging
So why is Visual Studio showing this stuff, anyway? Because there's one more meaning of "Debug": whether you are starting the app with Visual Studio's debugger attached, or not. Both options for starting are listed in VS' Debug menu bar: "Start Debugging" and "Start Without Debugging". This is orthogonal to what build configuration you are using: you can run a Debug build without a debugger attached, and you can run a Release build with a debugger attached (though this may not be as helpful, because breakpoints may not be hit in some cases).
When you use a debugger, the Output window displays messages written to the default trace listener. This is labeled "Debug" but it includes anything written there - including calls to Trace, which are included (by default) in Release builds.
I have a simple program to look for pre-compiler constants:
#if TEST1
MessageBox.Show("TEST1");
#endif
Now if I build the following through the CLI, things are as expected. The messagebox shows "TEST1".
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild" "C:\tests\TestBuildConstants\TestBuildConstants.sln" /p:OutDir="C:\tests\TestBuildConstants" /p:DefineConstants="TEST1" /t:Rebuild
However, if I go to Project properties -> Debug -> Command line arguments, and enter this: /p:DefineConstants="TEST1" /t:Rebuild, it refuses to pass through the constant once I run the program.
The reason I want to go through the VS GUI like this is because I want to quickly be able to test and switch between various builds as I'm coding.
What have I missed?
The Project properties > Debug > Command line arguments are for the parameters to pass to application after it has been built when it is run by VS. They are not arguments for MSBuild. You need to go to the Project properties > Build page and change "Conditional compilation symbols" to include TEST1.
I'm trying to attach the VS debugger to one of my own applications that is running from its installation directory in Release configuration.
When the app runs, it immediately shows a MessageBox saying that the app was launched with invalid command line arguments. These arguments have been passed to the app by the shell when an associated file (*.MyAppFileExtension) is double clicked.
The installer configures the shell to send these command lines.
Now something has gone wrong and I cannot seem to set a breakpoint after attaching the VS debugger to an instance of my app. It allows setting a breakpoint at the call to MessageBox.Show but by the time I attach, the call has already been executed. No breakpoints are settable after this point.
The error says the breakpoint failed to bind.
The question is, is it possible to debug the release version without going to the trouble of compiling and installing the Debug version?
Also, is it possible for the VS debugger to launch the executable itself so that valid breakpoints may be hit?
EDIT: In case it is relevant, the call to MessageBox.Show is the last line of code. Is that why breakpoints are not settable at the closing braces that follow?
If you can modify the code, the easiest way to handle this would be to add Debugger.Launch(); (or Debugger.Break() to break right away) at the start of your Main function. This will allow you to attach a debugger as soon as the application starts.
Launching a debugging session with given command-line arguments is also possible, and quite simple - just open your project properties, go to the Debug tab, and add whatever command-line arguments you need. You can even select a different executable to launch (handy for DLLs).
If you really need to debug the installed application you would need to first build the debug version and install that in order to be able to attach and use breakpoints. The release version lacks the debugging symbols necessary to hook into the code. If the fact that the app is installed is not relevant to what you want to test, you can set command line parameters in the project's settings and set breakpoints as normal, and then just run the app in debug mode from VS.
you just need to add one line of code before executing other code.
System.Diagnostics.Debugger.Launch();
probably you just need to add on very first line of Main function.
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.
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.