Question

 class Program : CriticalFinalizerObject
    {
        static void Main(string[] args)
        {

            Program p = new Program();
            TextWriterTraceListener listener = new TextWriterTraceListener(@"C:\trace.txt");
            Trace.Listeners.Clear(); // Remove default trace listener
            Trace.Listeners.Add(listener);
            Trace.WriteLine("First Trace"); // Generate some trace messages
            Trace.WriteLine("Perhaps last Trace.");

        }

        ~Program()
        {
            Trace.Close();
        }
    }

I get file size =0

the finilizer should have executed because I derive from CriticalFinalizerObject

I don’t want to use Trace.Close() not in the Finalizer.

edit

after @eric Lippert reply : Ive re-edited the code trying to match it to :constrained execution region ( but still no success)

  [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
    class Program : CriticalFinalizerObject
    {

        static void Main(string[] args)
        {
            RuntimeHelpers.PrepareConstrainedRegions();
            try
            {
            }
            catch (Exception e)
            {
            }
            finally
            {
                Program p = new Program();
                TextWriterTraceListener listener = new TextWriterTraceListener(@"C:\trace1.txt");
                Trace.Listeners.Clear();
                Trace.Listeners.Add(listener);
                Trace.WriteLine("First Trace");
                Trace.WriteLine("Perhaps last Trace.");
            }
        }

        ~Program()
        {
            Trace.Flush();
        }
    }

Answer 1

As the documentation clearly states:

In classes derived from the CriticalFinalizerObject class, the common language runtime (CLR) guarantees that all critical finalization code will be given the opportunity to execute, provided the finalizer follows the rules for a CER, even in situations where the CLR forcibly unloads an application domain or aborts a thread. If a finalizer violates the rules for a CER, it might not successfully execute

Does your finalizer follow all the rules for a constrained execution region?

UPDATE:

You’ve updated your code in an attempt to make it follow the rules of constrained execution regions, but I see no evidence whatsoever that you’ve done so correctly. The rules are quite clear; a finalizer in a constrained execution region absolutely must not do any of these things:

• allocate memory
• box a value type
• acquire a lock
• call an arbitrary virtual method
• call any method which lacks a reliability contract

Does your finalizer do any of those five things? If it does then there is no requirement that the CLR honours your desire for the finalizer to always run.

Moreover: forget about constrained execution regions for a moment because your program as it stands now is not even threadsafe. You’ve written a nasty race condition into the program.

What stops the jitter from garbage-collecting p before the trace starts? Nothing! The jitter knows that p will never be used again, and is perfectly within its rights to collect it immediately after its allocation. The flush could be happening at any time on the finalizer thread, including before the trace writes happen, or in the middle of any of them.