For one of our clients, I've been working on converting printed forms into web forms, and in the process have been dealing with a lot of tables that need to fit within a fixed width.  These tables are in a FormView in a User Control, which are then placed on webpages as needed.  I was finding that Visual Studio 2008's design mode was happy enough to accept my fixed-width columns and tables settings in my CSS stylesheet when working on the User Control, but once that User Control is placed on an actual page the fixed-width settings are no longer respected in both design mode and in debug mode displayed through a browser.  What to do?  After much frustration I found the embarrasingly simple answer: I wasn't putting "px" at the end of pixel measurements for table/column widths.  For whatever reason the Visual Studio 2008 FormView designer was content without the "px" but nothing else was.  In my rush to get things working I was leaving off the "px" figuring that I could go back later and add them on after the fact.  So lesson learned: be standards compliant, even if your development tool of choice lets you get away with not being standards compliant.

Still on the topic of fixed-width tables and columns, have you ever wanted to figure out exactly how many pixels wide/tall something is on a webpage, be it a table row, table column, header graphic, etc.?  Enter Pixel Ruler--a free app that displays a rotatable ruler on your screen and even tracks your mouse cursor and keeps a running measurement of how many pixels away you are from the zero mark on the ruler (in one dimension of course--it doesn't do diagonal measurements).  This app will save me countless hours of eyeballing and hoping for the best, instead providing me with precise measurements to the pixel.

The Patterns & Practices team at Microsoft recently released the 3.0 version of the ever-useful Enterprise Library.  Among the changes in the current iteration of the library is the addition of a new application block - the Policy Injection Application Block ("PIAB").

The purpose of the PIAB is to provide developers a way to define "policies" that can be applied selectively throughout an application.  Imagine that you're building a human resources application and one of the requirements is that the application provide an audit trail for all changes made to an employee's personnel record.  The PIAB allows you to define this requirement as a "policy" and configure its behavior external to your application.

Here's how it works:

• Using the Enterprise Library Configuration tool, you define a policy (in this case we'll name it "Audit Policy")
• Each policy can have any number of associated "matching rules"; these rules define how/when the policy is applied.  The PIAB provides the following rules out-of-the-box:
  • Assembly Matching Rule
  • Custom Attribute Matching Rule
  • Member Name Matching Rule
  • Method Signature Matching Rule
  • Namespace Matching Rule
  • Parameter Type Matching Rule
  • Property Matching Rule
  • Return Type Matching Rule
  • Tag Attribute Matching Rule
  • Type Matching Rule
• Each policy can also have any number of "handlers"; handlers determine what happens when a policy is executed.  The PIAB provides the following handlers, which utilize other Enterprise Library application blocks, out-of-the-box:
  • Authorization Handler
  • Caching Handler
  • Exception Handling Handler
  • Logging Handler
  • Performance Counters Handler
  • Validation Handler
• In our HR application example, we'll elect to use a "Tag Attribute Matching Rule" that allows us to mark methods in our business tier classes as requiring audit functionality; in addition, we'll choose to apply the Enterprise Library's Logging Application Block as our policy's handler.
  
   The resulting XML in our application's configuration file looks like this (the Logging Application Block section has been omitted for brevity):
  

<policyInjection>
<policies>
<add name="AuditPolicy">
<matchingRules>
<add match="Audit" ignoreCase="false" 
  type=
  "Microsoft.Practices.EnterpriseLibrary.PolicyInjection.MatchingRules.TagAttributeMatchingRule,
  Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.0.0.0,
  Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  name="Tag Attribute Matching Rule" />
</matchingRules>
<handlers>
<add logBehavior="After" beforeMessage="" afterMessage="" eventId="0"
  includeParameterValues="true" includeCallStack="false" includeCallTime="true"
  priority="-1" severity="Information"
  type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.LogCallHandler,
  Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers,
  Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  name="Logging Handler">
<categories>
<add name="General" />
</categories>
</add>
</handlers>
</add>
</policies>
</policyInjection>

• In our application, we're going to mark each method that requires an audit trail with a "Tag" attribute...notice that "Audit" corresponds to our matching rule defined above:
  

      /// <summary>
      /// Note:  class must inherit MarshalByRefObject 
      /// for use with the PIAB
      /// </summary>
      class Employee : MarshalByRefObject
      {
          [Tag("Audit")]
          public void Save()
          {
              //write employee to data store
          }
  
          [Tag("Audit")]
          public void Delete()
          {
              //remove employee from data store
          }
      }

• The "policy injection magic" performed by the PIAB will occur as a result of the way we create an instance of our Employee class: 
  
  

  Employee ourEmployee = PolicyInjection.Create<Employee>();
  ourEmployee.Save();

  
  The Create() factory method actually builds and returns a "proxy class" -- in this example, the proxy class intercepts our call to the Save() method, evaluates the matching criteria and determines that the handler should be executed because of the "Audit" tag match.  The result in this case is that an entry is written to the Windows event log as defined by our Logging Application Block configuration.
  

The "policy injection" pattern is worth a look if you have common functionality that needs to be applied throughout your application, and you want to do so in a declarative, transparent way.

In the slides from Scott Guthrie's 'ASP.NET Tips and Tricks' TechEd Presentation, I ran across this gem.  You can turn off debugging server-wide by adding the following to <system.web> section in the server's machine.config file (typically located in C:\windows\Microsoft.NET\Framework\v<version>\Config):

       <deployment retail="true"/>

This is a great backup in case developers forget to turn it off in the application using <compilation debug="false"/>.  Scott also mentions a few of the negative results of forgetting this little setting:

• Slower performance due to debug code
• App uses much more memory
• Client-side scripts are not cached

One of the most useful tools for .NET development is Lutz Roeder's .NET Reflector, now in version 5.  It uses reflection to peek inside .NET assemblies and disassembles the IL back into C# or VB code for those times that you need an in-depth look into any .NET library.  Ever wonder what the code for System.String looked like? This release adds some really nice features:

• Formatted code comments- doubles as a documentation browser for XML code-commented members
• 'Expand members' in disassembler lets you see code for an entire class at once- previously you had to look at each method separately.
• New analyzer features shows where classes are instantiated and exposed.
• Search Google or MSDN for a member

In addition to helping you debug code, this is also a great learning tool.  What better way to understand framework development than to peek inside The Framework itself?

Ever wondered what a secure ASP.NET 2.0 application should look like?  The ASP.NET Internet Security Reference Implementation rolls all of the Patterns and Practices Security Guidance into real-world sample application, complete with full documentation about all of the security features, why and how they were implemented, and the drawbacks to doing so.

If you are doing ASP.NET 1.1 or 2.0 web design, you should download this, read through it, and check out the code.  While the code is 2.0, all of the security concepts- and some of the solutions- map to 1.1 apps as well.

One note: it installs into C:\Program Files\Microsoft\Internet Security Reference Implementation by default.  It took me forever to find it!

Craig Utley presented a very useful Microsoft Webcast a few months back on three common OO design patterns (Singleton, Factory, and Observer).  In addition to describing practical coding techniques to solve particular problems, Craig also shows two methods for implementing each pattern -- a "traditional" approach that uses coding constructs available in most languages, and a more elegant ".NET" approach that takes advantage of features of the .NET framework to achieve the same goal; for example, his .NET implementation of an "Observer" pattern uses delegates/events to communicate between publisher and subscriber objects, rather than having the publisher aggregate references to the subscribers. 

There is also a good reference to various patterns, with sample implementations, here.