none
how to use #if debug while debugging. RRS feed

  • General discussion

  • Hello All Experts,

    I have a class library project which contains a single class.

    public class Class1:IPlugin
        {
           #if DEBUG
            public void DoSomething(){

                Console.WriteLine("Mode=Debug"); 

            }
        
           #else
        Console.WriteLine("Mode=Release"); 
          #endif

        }

    i want to debug the above code without attaching to any process.

    while trying the above code it's saying class library project cannot be run.

    Wednesday, May 31, 2017 10:42 AM

All replies

  • I thought you would give us an explanation how to do it. 

    Because you made from this a discussion.

    But is a question, than don't change the type from question to discussion.


    Success
    Cor

    Wednesday, May 31, 2017 10:53 AM
  • Hello Cor,

    I have come across this thought because somewhere i have seen people using 

    #IF DEBUG 

    but that application was a windows service.

    so i thought if we could do it in class library project.

    Wednesday, May 31, 2017 11:50 AM
  • You cannot directly run a class library, regardless of any debugging.

    You can only run executables; for example you run an executable that, in turn, makes use of your class library. (This executable can also be a test project).

    '#if debug' is a compiler directive. It means that different code will get compiled when you build your application in debug mode as opposed to release (or any other) mode.

    This is indicated by the "solution configuration" dropdown that you should see in the toolbar in Visual Studio (or indicated by a setting within your build process).

    If you build your class library in 'debug' mode, and then deploy it somewhere, then when it is used by whatever executable makes use of it the code within the '#if debug / #endif' directives will get executed.

    Wednesday, May 31, 2017 12:51 PM
  • The best suggestion I can give is for you to write unit tests.  Your unit tests can be debugged outside the context of the service you are running.

    You have to choose the configuration when you build your project -- so this happens at compile-time, not run-time.

    If you have selected to build a a Debug configuration, then DEBUG will be true during the build and it will compile the code in the #if block.  If your configuration is a Release configuration, then DEBUG will be false and it will not compile the code in the #if block (it will compile the code in the #else block, though).  At run-time the code is essentially "hard-coded" to be one or the other depending on what you built.

    You have to debug a process and there's not much way around that.  A service is a process, so it makes sense that you could build a Debug configuration of your service and attach to the process to debug it.

    For the purposes of seeing what your code does without running it as a service then refactor your application and prepare two hosts for your core code.  One host will be the service, and the other will be a plain executable.  It's much more natural to debug a stand-alone executable because it's easier to start and stop.

    If you have a typical bug, then it's likely unnecessary for you to debug the "service" aspect of your service, just the core features, so they can likely be refactored into a common module that can be called by a traditional exe.  The flip-side of that argument is that it's possible that your service runs with restricted permissions or session 0 isolation or something that is causing you a service-specific kind of problem.  Debugging those issues is still possible by attaching to the service host.

    Wednesday, May 31, 2017 1:05 PM
  • Test your methods using unit tests.

    I strongly recommend against using #if in your code. The only time you should use this is if the code won't compile under certain situations (e.g. cross platform code). In all other cases use the ConditionalAttribute instead. Serves basically the same purpose and doesn't require that you wrap all calls to the aforementioned code in a #if. As an example, given your code above you'd have to do this in every place you call it.

    //Call the method
    
    #if DEBUG
    myClass1.DoSomething();
    #endif
    
    //This won't work outside DEBUG builds
    myClass1.DoSomething();

    Using the attribute you don't have to do that anymore.

    public class MyClass1
    {
       [Conditional("DEBUG")]
       public void DoSomething () 
       { }
    }
    
    //Call it, if it not conditionally included then it gets skipped
    myClass1.DoSomething();

    The downside to this attribute is that the method in question cannot return a value since the call will be skipped when the given value is defined.

    Michael Taylor
    http://www.michaeltaylorp3.net

    Wednesday, May 31, 2017 1:41 PM
    Moderator