Save Visual Studio’s Configuration for a Rainy Day

Visual Studio is one of the best IDEs for C++ development. It has a good mix of  powerful tools  and ease of use.

One downside of VS is how easy it is to mess up the windows layout, and other environment settings.   Another downside is that it tends to happen  at the most inconvenient  times.

Saving the IDE layout when everything is  looking and working the way I like. Lets me do a quick reset to my preferred setup without having to google around for ways to restore a  MIA tab.

The procedure is easy and works the same for recent VS versions:

Select Tools –> Import And Export Settings

image

Select the Export radio button:

image

In the next window,  you can select which settings you want to export. I usually export the general settings only, but  shop around and see if  there is anything else you’d want to save.

image

(You can expand the General Settings to subcategories.  I found its easier  to save the whole tree, but you can  fine tune your  selection if it suits you)

The next windows ask you for a save location and file name. I suggest you select a location  that will survive a hard disk disaster, for example, a backed up network directory.  You can also  check the file into a source control repository as it is a plain  XML  file.

image

That’s it!   the next time Visual Studio change things under your feet  you can show it who’s the boss by importing the file  you just saved:

Select Tools –> Import Export Settings:

image

The next windows let you save your current (possibly messed up)  settings  before you override them.  Take the opportunity to do so.  it will take less than a second to delete this file if everything goes well.

image

In the next window browse for your file (or select it from the Recent Files list if its there )

image

The next screen asks you to confirm the import,  the list should contain  the settings you exported earlier :

image

Once the import is done,  your IDE should return to its old self.

Conclusion

It’s not  rocket science  but it does save time. Like anyone who used source control for any length of time know,  sometimes it’s much easier to revert to an older version  than trying to clean up a mess one menu option at a time.

Stop Logging Debug Values, Use Visual Studio’s Trace Points instead!

nearly every company I’ve worked for had a “let’s clean our logs project”.  The trigger for this activity was often  frustrated log uses such as tech supporters , customer service staff and other developers (usually the new ones)   overwhelmed  by the clutter and junk included in the logs.
Some of the log trash  is generated during development,  is not uncommon to see something like

[26/04/2016:14:23:48]  INFO: In nameVerify method (remove after Q4-2014  release)

Or even worse
[26/04/2016:14:23:48]  WARNING:  secstr = DvVP1$XFJ2T
where secstr stands from secret or security ,  and warnign logging was used because it stands out in the logs.

Often these log entries are created during the infant days of the software components.  While some of  them  are an  indication the should  me more unit test  cases,   Other are used sed to extract and examine  internal data  dynamically created by the component on each run.

For this late use, you can use trace points.
trace points are a kind of breakpoints only the debugger can be instructed no to halt the program. The expression is evaluated and the  result  can be printed to the output windows:

consider this simple TraceMe class:

#include  <vector>
#include  <string>

class TraceMe
{
	public: 
	TraceMe() 
	{
		val = 5;
	}
	TraceMe(std::string str) 
	{
		secStruct.secStringVec.push_back(str);
		val = 10;
	}
private:
	int  val;
	struct  InternalStruct
	{
		std::vector<std::string>  secStringVec;
	};
	InternalStruct  secStruct;
};

int main(int argc, char* argv[])
{
	TraceMe  trace;
	return 0;
}

 

Suppose we need to examine the content of the val member after it has been   initialized.  The first step is writing an expression that would evaluate to its contend.  This can be done without typing in a single character :

I placed a breakpoint (the plain vanilla type)  at line 28.  After I debug the program and the breakpoint is hit ,  I right click on the trace variable and select Quick Watch:

image

After expanding the structure,  Select the variable, the content of the expression edit box is what the QuickWatch  tool is using to evaluate val :

image

You can remove the breakpoint, we won’t need it anymore. Go to the next line (line 29)  and create another breakpoint :

image

right click on it and select, when hit:

image

In the dialog make sure  Print Message  and Continue execution checkboxes are both  is ticked.

now we can use the expression we extracted earlier: paste it into the edit box and enclose it with curly braces :   {(trace).valthe cause tell the debugger to evaluate the the expression and output the result.

Write  some text that will the value some context for example C++ Island -Debug the value of val is  {(trace).val}.

image

Now run the program and search the output window for you message:

image

This method works the same way  even when the value you are interested in is buried deep inside other data structure(s). Getting  the secString from the the vector inside internal structure is just as easy:

image

The expression turns out to be

((((trace).secStruct).secStringVec)._Myfirst)[0]

Conclusion

When printing a variable value during development, consider trace points However  if the variable values  serves as  an indication the program is running as it should (a virtual green LED)  , it might be a hint that an  an assertion or  a test case is a better  tool for the job.

How to Compare Visual Studio’s Debug and Release Configurations

Comparing Debug and Release configurations (or any other two configurations) is not easily done with visual studio.  However, there is a way to do it reasonably easily, since all the configurations setting  applied to a C++ project are translated to command line switches passed  on to the compiler or linker tools.
This method  allows easy comparison of the command line switches  of two configurations.

1. Open the Project properties and navigate to the Command Line entry:
Project –> Properties –> C/C++ –> Command Line
Select one of the configurations you  want to compare
Merge Release Property Pages

2.  Open an empty  text document in  a text editor supporting regular expressions. I’ve used Notepad++,  but you can also use Visual Studio itself by opening a new text file.
Paste the content of the All Option field  to the file. Append the  content of the Additional Options Field.

you should be getting something similar to this (word wrap view) :
OptionsRelease

3. The next steps will ensure there is  one option per line.  Most of the switches  have no spaces except  the /D switch.  I’ll remove it with a simple regex :
Search and Replace the regular expression
/D\s  with  /D   :
Replace

4.  Now  we can have one option per line  by searching and replacing \s  with \n   (spaces to newlines).
Replace

5.  Save the output to a file (e.g.  OptionsReleaseSplit.txt)
E__Examples_OptionsReleaseSplit.txt - Notepad

6.  Repeat the process to the other configuration you want to compare.

7.  Now comparing the two configurations is as easy as comparing the two files in a  Diff  tool :
compareReleaseDebug

A similar method can be applied to the linker’s options:
Merge Property Pages

That’s it,  the simple system saved me some guesswork when a project compiled in debug but will not compile (or link)  when using release configuration.
Do you have other ways of   comparing debug/release?    leave a note in the comment section.