<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>AnalyticGal - Code Blog comments on Microsoft's Suggestions for .NET Application Improvements</title>
    <link>http://code.analyticgal.com/</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>AnalyticGal - Code Blog comments</description>
    <item>
      <title>"Microsoft's Suggestions for .NET Application Improvements" by nhughes</title>
      <description>&lt;p&gt;
Back in February 2005, my development group visited the Whidbey TAP lab in Redmond, WA.  We met with quite a few of the groups one-on-one, such as &lt;a href="http://www.microsoft.com/resources/practices/default.mspx"&gt;Patterns and Practices&lt;/a&gt; (aka Platform Architecture Guidance), &lt;a href="http://msdn.microsoft.com/visualc/default.aspx"&gt;Visual C++&lt;/a&gt;, ADO.NET, threading, and others.  Here are the suggestions from Microsoft compiled while we were there:  
&lt;/p&gt;&lt;p&gt;
&lt;strong&gt;Threading&lt;/strong&gt;
&lt;/p&gt;&lt;ul&gt;
&lt;li&gt;Do not use System.Timer in your applications, instead use System.Threading.Timer.   System.Timer does not use the thread pool and is less efficient.&lt;/li&gt;
&lt;li&gt;Instead of using a Timer for counting time in your application, a StopWatch is more appropriate and more efficient.&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt;
&lt;strong&gt;Enterprise Instrumentation vs. Enterprise Library&lt;/strong&gt;
&lt;/p&gt;&lt;p&gt;
If you are using Enterprise Instrumentation for logging, STOP IT!  Look into the new, and majorly improved Enterprise Library.  It requires less work and is less error prone.  When our application was using Enterprise Instrumentation, we had major memory leaks.  Since the implementation of Enterprise Library, the application's performance has improved 100%.  See this &lt;a href="http://blogs.msdn.com/tomholl/"&gt;blog&lt;/a&gt; for more info on Enterprise Library. 
&lt;/p&gt;&lt;p&gt;
&lt;strong&gt;Visual C++ - Ressurected&lt;/strong&gt;
&lt;/p&gt;&lt;p&gt;
There are 3 situations in which you might use &lt;a href="http://msdn.microsoft.com/visualc/using/multimedia/newc/default.aspx"&gt;Visual C++&lt;/a&gt; rather than C#: 
&lt;/p&gt;&lt;ul&gt;
&lt;li&gt;If the developers are used to C++ and would like to continue its use, rather than ramp up on a new technology.&lt;/li&gt;
&lt;li&gt;If the application uses complicated or multiple InterOps to native code.&lt;/li&gt;
&lt;li&gt;If you want a lower-level of control in your development.  For instance, the ability to override a method with a different name is available in C++ but not in C#.&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt;
They've even implemented the &lt;a href="http://msdn.microsoft.com/visualc/whidbey/default.aspx?pull=/library/en-us/dnvs05/html/stl-netprimer.asp"&gt;STL&lt;/a&gt; in .NET.
&lt;/p&gt;

</description>
      <pubDate>Mon,  2 May 2005 00:42:00 PDT</pubDate>
      <guid>&lt;a href="/articles/2005/05/02/microsofts-suggestions-for-net-application-improvements"&gt;Microsoft's Suggestions for .NET Application Improvements&lt;/a&gt;</guid>
      <link>&lt;a href="/articles/2005/05/02/microsofts-suggestions-for-net-application-improvements"&gt;Microsoft's Suggestions for .NET Application Improvements&lt;/a&gt;</link>
    </item>
  </channel>
</rss>
