>>>>>>>Hi.
>>>>>>>I would like to use conditional compilation to have difference method access modifier for unit testing.
>>>>>>>
>>>>>>>

>>>>>>>#if TEST
>>>>>>>    public virtual void MyMethod()
>>>>>>>#else
>>>>>>>    public void MyMethod()
>>>>>>>#endif
>>>>>>>    {
>>>>>>>        // Do Something;
>>>>>>>    }
>>>>>>>

>>>>>>>
>>>>>>>I have code as above, I added new constant TEST at solution configuration manager. I changed "constant" among debug, release and TEST. VS 2008 IDE works fine for TEST and debug. However, whenever I change it to release, the method under TEST constant will be used.
>>>>>>>
>>>>>>>Anyway to make DEBUG/RELEASE to use public void MyMethod() and onyl TEST will use public virtual void MyMethod() ?
>>>>>>
>>>>>>If I understand correctly what you are trying to do:
>>>>>>
>>>>>>There is a pre-defined DEBUG constant which should be adequate - just make sure the checkbox in the project 'Build' page is checked for the relevant configurations. You should be able to check whether conditional code will be compiled - if it is not being compiled it will be greyed-out in the IDE. If you really want to use 'TEST' then add it to the 'Conditional Compilation symbols in the 'Debug' configuration of the project properties 'Build' page
>>>>>
>>>>>
>>>>>You can also test for debug mode
>>>>>

>>>>>if (System.Diagnostics.Debugger.IsAttached)
>>>>>{
>>>>>     DoSomething()
>>>>>}
>>>>>else
>>>>>{
>>>>>     DoSomethingElse()
>>>>>}
>>>>>

>>>>
>>>>I didn't know that. But now that I do I'm having trouble seeing a use for it.....
>>>
>>>The only thing we really use it for is to set the main form maximized or not. In debug mode it is running on my development machine with a 21" monitor. In production it runs on a computer with a 10" monitor and we don't want them to run anything else at the same time. It is just convenience for us. I am sure there are other uses, but ??
>>
>>But doesn't that make it hard to debug on a production machine if you need to?
>>In general I'm not keen on having code execute differently in a debug environment
>>(this is interetsting: http://blogs.msdn.com/jmstall/archive/2004/10/02/236942.aspx)
>>Regards,
>>Viv
>
>Perhaps it isn't the best idea, but it has been that way for several years with no problem. Not much to debug with that paticular item. I hadn't really used some of the ideas shown in this thread, so will take those as good practice examples and try them out.

Conversely, now that my attention has been drawn to System.Diagnostics.Debugger.IsAttached I'll watch for situations where I might find if useful.....
Best,
Viv