Check if an executable or DLL is build in Release or Debug mode

Recently I ran into problem when I tried to pass std::string and std:wstring types between DLLs. Simply hardcoded const std::string passed from one DLL to another gets completely wrong transmitted. It looks like something with encoding is wrong but it turns out somehow I had compiled those two DLLs with deferent configurations. One was Debug another was Release build. Since I had over 50 executables and libraries, static and dynamic, interlinking with each other I had to find out quickly which ones were build wrong configuration.

.NET offers very nice helper class FileVersionInfo with FileVersionInfo.IsDebug property.

The FileVersionInfo properties are based on version resource information built into the file. Version resources are often built into binary files such as .exe or .dll files; text files do not have version resource information. Version resources are typically specified in a Win32 resource file, or in assembly attributes. The IsDebug property reflects the VS_FF_DEBUG flag value in the file's VS_FIXEDFILEINFO block, which is built from the VERSIONINFO resource in a Win32 resource file.

I’ve wrote very simple C# console application that accepts directory path as input parameter. It iterates trough all .exe, .dll and .lib files and writes out to .txt file if it was build with Debug or Release configuration.

Here very short and simple code listing:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConfigChecker
    class Program
        static void Main(string[] args)
            string inputPath = string.Empty;
            if (args.Length == 1 && Directory.Exists(args[0])) 
                inputPath = args[0];    
                Console.WriteLine("Input path does not exist. Check input arguments.");

            string[] searchExtensions = { ".dll", ".exe", ".lib" };
            var files = Directory
                        .GetFiles(inputPath, "*.*", SearchOption.TopDirectoryOnly)
                        .Where(file=> searchExtensions.Any(ext => file.ToLower().Contains(ext)))

            uint releaseCount = 0;
            uint debugCount = 0;
            StreamWriter sw = new StreamWriter("output.txt", false);
            foreach (var file in files)
                FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(file);


                if (fileVersionInfo.IsDebug)
            sw.WriteLine("Debug: " + debugCount.ToString());
            sw.WriteLine("Release: " + releaseCount.ToString());

            Console.WriteLine("Output successfully written to: " + new FileInfo("output.txt").FullName);

Here is output when we call it with “C:\Windows\System32” parameter for example:

C:\Windows\System32\XAudio2_7.dll		Release
C:\Windows\System32\XAudioD2_7.dll		Debug
C:\Windows\System32\xcopy.exe		Release
C:\Windows\System32\xinput1_1.dll		Release
C:\Windows\System32\xinput1_2.dll		Release
C:\Windows\System32\xinput1_3.dll		Release
C:\Windows\System32\XInput9_1_0.dll		Release
C:\Windows\System32\xlive.dll		Release

VS 11 Suggestion: Breakpoint groups, enable / disable breakpoints on group level

In my opinion this peace of the puzzle is still missing in Visual Studio. I submitted this idea to Visual Studio User Voice web site.



Here is the original text:

Give user ability to mark defined breakpoint as part of the group or set.

Let’s say you are working on specific bug and you spent hours of debugging and setting breakpoints but still didn’t solve the bug. You still need those break points but you are waiting for something else to continue working on this so you move on to something else.

Now you work on different bug, new breakpoints are needed but your debugger keeps hitting the old ones.

Do you disable or delete old breakpoints, maybe. You can always export them to XML and import later, but that’s not so convenient. What if you are working on several bugs?

This is something similar what happens with tabs in older VS’s. You step into code , go to definition , go to definition and so on, tabs keep piling up and as Scott Hanselman says “you declare tab bankruptcy” and just close them all. This was very nicely solved by VS 11 and I would like to have something similar for breakpoints.

It would be very nice just to mark your breakpoints as part of the set or group. That way user could name the group “DAL timeout bug” and enable or disable breakpoints on group level when needed.

I could easily move from debugging one issue to another without losing time on searching place in code to set or enable again breakpoint.

Nice to have would be to link breakpoint set to specific TFS work item. Whenever I open work item, I could again restore my breakpoints.

Here is the link to my suggestion. Vote for it.

About me

Bizic Bojan is Co-Founder of Amida IT-Services GmbH and Software Architect with focus on .NET, C++, Python and Cloud Native solutions. 



The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.