0

I have a library that will be built and published as a nuget package in release mode.

However for debugging purposes it is useful to capture stacktraces at various points.

Capturing a stack trace is relatively expensive, and I don't want to do it in release. However neither do I want to force everyone to replace my nuget package with the debug version when they want to debug their code.

Is there a way to check if the executable that a dll is running in was compiled with debug or release? In other words even though my nuget package was compiled with release, I want to run different code depending on whether or not the executable that my library is used by was built in release or debug?

Yair Halberstadt
  • 5,733
  • 28
  • 60
  • 2
    Have you considered making it an option on the library for your callers? Perhaps they'd like to have extra information available in a release build for whatever reason. If they want to tie the extra info to debug builds, they can. Perhaps they don't even want the extra info in debug builds. As a random example, [log4net uses a config setting](https://stackoverflow.com/a/756241/791010). – James Thorpe Jun 25 '19 at 10:57
  • I can't think of any good place in my library to create that option, other than setting a global static, which i find quite ugly. Either way, I think the default should match the debug or release mode of the executable, even if that is overridable. – Yair Halberstadt Jun 25 '19 at 10:59
  • 1
    Taking my previous example further, log4net [can also use a global static](https://stackoverflow.com/a/35274650/791010). It's fine. – James Thorpe Jun 25 '19 at 11:00
  • I think I will do that, but it would as I said be useful to set the default based on whether or not we're in debug. – Yair Halberstadt Jun 25 '19 at 11:05
  • 2
    You can hunt for the assembly's `AssemblyConfiguration` attribute and see if it's `Debug`, or the `DebuggableAttribute` and inspect the flags, but this can only serve as an approximation/default in case the user has done nothing interesting while compiling, since "compiled in debug mode" has no formal definition -- unlike, say, checking if we are actively debugging (`Debugger.IsAttached`). Having an explicit setting to tune is a good idea regardless, since I'd want to know if a library decides to behave really differently based on how I happen to run my application. Debugging is hard enough. – Jeroen Mostert Jun 25 '19 at 12:05
  • Debugger.IsAttached is a good idea – Yair Halberstadt Jun 25 '19 at 12:07
  • _"Debugger.IsAttached is a good idea"_ I'm not so sure - the last thing I'd want a library to do is to start behaving differently when I'm trying to debug something... – James Thorpe Jun 25 '19 at 12:09
  • Well the behaviour shouldn't change. It's just logging really. But point taken. – Yair Halberstadt Jun 25 '19 at 12:23

1 Answers1

1

The lines below appear to be in conflict with each other:

Is there a way to check if the executable that a dll is running in was compiled with debug or release? In other words even though my nuget package was compiled with release, I want to run different code

Usually it is possible to do something similar to what you are after by using pre-processor directives. This would allow your program to execute different paths according to for instance, the name of the configuration used to build the project:

#if debug
    //Log
#endif

However, you seem to be after something different. It seems that you want to change behaviour but keeping the same build (release in both cases).

To cater for this, it might be easier to have a flag, say verbose which is false by default and when enabled, it logs the extra information. This would allow you to keep the same build mechanism but be able to log more information accordingly.

Edit: As per your comments, what I mean is something like this:

In your code that calls the nuget, you would have something like so:

#if DEBUG
    var x = new NugetInstance(verbose:true...);
#else 
    var x = new NugetInstance(verbose:false...);
#endif
npinti
  • 51,780
  • 5
  • 72
  • 96
  • I'm saying that I want different behavior depending upon the debug or release configuration of the executable that's being run, not based on the debug or release configuration of the nuget package that is being used. e.g If MyApp is built in debug, and uses MyPackage which was built in release, I want MyPackage to store the stack trace information. – Yair Halberstadt Jun 25 '19 at 11:04
  • @YairHalberstadt: In that case why not adopt a mix f the 2 approaches mentioned so far? You include the verbose flag in the Nuget but then you would initialise the instances of your Nuget through the use of pre-processor tags. – npinti Jun 25 '19 at 11:18
  • That's what i plan to do, but the preprocessor tags are only dependent on whether or not the package is built in debug, not whether it's running in debug. Still, I can live with it. – Yair Halberstadt Jun 25 '19 at 11:21
  • @YairHalberstadt: I am not sure we are on the same page, I have updated my answer, – npinti Jun 25 '19 at 11:25
  • Thanks. That's understood, but it would be nice to be able to have that work by default. – Yair Halberstadt Jun 25 '19 at 11:39