Delete mda.cs and related dead code (#22535)

1 files changed, 0 insertions, 164 deletions

diff --git a/src/vm/mdaBoilerplate.exe.mda.config b/src/vm/mdaBoilerplate.exe.mda.config
index 1cbd20037e..c75d7aa329 100644
--- a/src/vm/mdaBoilerplate.exe.mda.config
+++ b/src/vm/mdaBoilerplate.exe.mda.config
@@ -192,67 +192,6 @@ ACTIVATION\REPORTING SCENARIOS:
         -->
 	   <dangerousThreadingAPI enable="false" />
 
-	   <!-- 
-            DateTimeInvalidLocalFormat (amoore)                                               
- 
-            ACTIVATION: 
-            Activated by default under a managed debugger.
-            
-            DESCRIPTION: 
-            Indicates when a DateTime instance that represents a UTC time is formatted with a format that should
-            only be used with local instances.
-            
-            BEHAVIORAL IMPACT: 
-            None.
-               
-            SCENARIOS: 
-            
-                SYMPTOM: 
-                An application is manually serializing a UTC DateTime instance using a local format:
-                    
-                    DateTime myDateTime = DateTime.UtcNow;
-                    Serialize(myDateTime.ToString("yyyy-MM-dd'T'HH:mm:ss.fffffffzzz"));
-                            
-                CAUSE: 
-                The 'z' format for DateTime.ToString outputs the local time zone offset, e.g "+10:00" for Sydney time. 
-                As such, it will only output a meaningful result if the value of the DateTime is local. If the value 
-                is UTC, DateTime.ToString will still output the local time zone offset.
-                
-                CORRECTION:
-                UTC DateTime instances should be formatted in a way that indicates that they are UTC. The recommended 
-                format for UTC times to use a 'Z' to denote UTC time:
-                
-                    DateTime myDateTime = DateTime.UtcNow;
-                    Serialize(myDateTime.ToString("yyyy-MM-dd'T'HH:mm:ss.fffffffZ"));
-        
-                There is also a short-hand "o" format that will serialize a DateTime making use of the DateTime.Kind 
-                property that will serialize correctly regardless of whether the instance is Local, Utc or Unspecified:
-                
-                    DateTime myDateTime = DateTime.UtcNow;
-                    Serialize(myDateTime.ToString("o"));
-
-                SYMPTOM: 
-                An application is indirectly serializing a UTC DateTime with a library like XMLConvert or DataSet 
-                serialization :
-                    
-                    DateTime myDateTime = DateTime.UtcNow;
-                    String serialized = XMLConvert.ToString(myDateTime);
-                                                
-                CAUSE: 
-                XmlConvert and DataSet serialization use local formats for serialization by default.
-                Additional options are required to serialize other kinds of DateTime, such as UTC.
-                
-                CORRECTION:
-                For XML Convert, pass in XmlConvertDateTimeOption.RoundTrip.
-                
-                    DateTime myDateTime = DateTime.UtcNow;
-                    String serialized = XmlConvert.ToString(myDateTime, XmlDateTimeSerializationMode.RoundtripKind);
-                    
-                If using DataSet, set the DateTimeMode on the DataColumn object to DataSetDateTime.Utc.                                         
-                             
-            
-        -->
-	   <dateTimeInvalidLocalFormat enable="false" />
 
        <!-- 
             DirtyCastAndCallOnInterface (chriseck)                                               
@@ -522,20 +461,6 @@ ACTIVATION\REPORTING SCENARIOS:
         -->
 	   <invalidFunctionPointerInDelegate enable="false" />
 
-	   <!-- 
-            InvalidGCHandleCookie (chriseck)
-
-            This error event is fired when an invalid IntPtr cookie->GCHandle retrieval is attempted.
-            The cookie is likely invalid because it was not originally created from a GCHandle, 
-            represents a GCHandle that has already been freed, is a cookie to a GCHandle in 
-            a different appdomain, or was marshaled to native code as a GCHandle but passed back into
-            the CLR as an IntPtr where a cast was attempted.
-
-            The symptoms the user will see is undefined behavior (AVs, memory corruption, etc.) while
-            attempting to use or retrieve a GCHandle from a IntPtr.
-        -->
-	   <invalidGCHandleCookie enable="false" />
-
 
 	   <!-- 
             InvalidIUnknown (chriseck)     
@@ -1016,95 +941,6 @@ ACTIVATION\REPORTING SCENARIOS:
 
 
         <!-- 
-            StreamWriterBufferedDataLost (BrianGru)
-            
-            DESCRIPTION:
-            Intended to detect when users write data to a StreamWriter but 
-            don't flush or close the StreamWriter.  That data is then lost,
-            because StreamWriter cannot reliably write data to the underlying
-            Stream from its finalizer.  Users should use a using block when
-            possible to ensure they always close the StreamWriter.
-
-            Poorly written code:
-            void Foo() {
-                StreamWriter sw = new StreamWriter("file.txt");
-                sw.WriteLine("Data");
-                // Forgot to close the StreamWriter.
-            }
-
-            This MDA was implemented by adding a finalizer to StreamWriter
-            that looks for data in its buffer.  As such, it requires your 
-            program to get around to running finalizers before exiting.
-            This should happen in long-running apps automatically over time,
-            but can be forced in short-lived test apps (like the above) by 
-            calling GC.Collect then GC.WaitForPendingFinalizers.
-            
-            BEHAVIORAL IMPACT: 
-            None.
-
-            SCENARIOS:
-                SYMPTOM:
-                User attempts to write to a file, but the last 1K - 4K of data
-                haven't been written to the file.  This MDA detects this
-                data loss during finalization of the StreamWriter.
-
-                CAUSE:
-                User did not properly close their StreamWriter, or arrange for
-                it to be flushed.
-
-                CORRECTION:
-                Use the using statement in C# & VB.  In managed C++, use a 
-                try/finally to call Dispose.  
-
-                void Foo() {
-                    using(StreamWriter sw = new StreamWriter("file.txt")) {
-                        sw.WriteLine("Data");
-                    }
-                }
-
-                Or users can use the long form, expanding out the using clause:
-                
-                void Foo() {
-                    StreamWriter sw;
-                    try {
-                        sw = new StreamWriter("file.txt"));
-                        sw.WriteLine("Data");
-                    }
-                    finally {
-                        if (sw != null)
-                            sw.Close();
-                    }
-                }
-
-                If neither of these solutions can be used (say, if you have a
-                StreamWriter stored in a static variable and thus you cannot 
-                easily run code at the end of its lifetime), then calling Flush
-                on the StreamWriter after its last use or setting its AutoFlush 
-                property to true before its first use will be sufficient.  
-                Here's an example:
-
-                internal static class Foo {
-                    private static StreamWriter _log;
-
-                    static Foo() {  // Static class constructor
-                        StreamWriter sw = new StreamWriter("log.txt");
-                        sw.AutoFlush = true;
-                        // Now publish the StreamWriter for other threads.
-                        _log = sw;
-                    }
-                }
-
-                OUTPUT:
-                An XML message, indicating this violation occurred. To the 
-                effect of "You lost data because you didn't close your 
-                StreamWriter."  It may include a file name and a stack trace 
-                showing where the StreamWriter was allocated, to help track 
-                down incorrect code.
-        -->
-        <streamWriterBufferedDataLost enable="true" captureAllocatedCallStack="false"/>
-
-
-	   <!-- 
             VirtualCERCall (rudim)                       
 
             This is just a warning. It indicates that a callsite within a CER call graph