One of the biggest drawbacks of using ASP.NET is the way it can really bloat a page size with ViewState.  That is because http and the web in general are stateless by nature, but when creating applications developers often need to track what changed on a form ... hence ViewState was introduced to essentially let the development code as if the web was stateful.  Although some left-wing purist might argue, my more pragmatic nature causes me to think this was a good thing overall because of the dramatic increase in productivity it offers.  However, the downside was bloated pages to the client ... but now ASP.NET 4.0 offers a better way to control that.

Pre 4.0, ASP.NET offered the EnableViewState property which you could put on a page or control.  If you set that value to false, it disabled all viewstate for that control and any child controls.  The problem was you didn't have the ability to override that behavior in any of the child controls.  So this was more of a system where it had to be enabled at a high level, but then disabled in an opt-out fashion where you didn't really need it.  The result was that people just didn't opt-out.  That isn't because they were lazy (well, not completely) ... its just that pattern doesn't encourage good practices.

ASP.NET 4.0 includes a new ViewStateMode property that is completely different than EnableViewState.  It allows you to set the overall viewstate for a site off by default, but that can be overridden at any level below that.  This creates an opt-in pattern.  When I first tried to confige this setup, I ran into a few problems because I was trying to mix EnableViewState with ViewStateMode. EnableViewState always trumps the ViewStateMode setting.  I think it is much simpler to not mix the two and just avoid the old school EnableViewState property all together, and solely rely on ViewStateMode to control your ViewState.

The ViewState Opt-In Pattern Using ViewStateMode

1. Set the site's masterpage(s) to have a ViewStateMode setting of "Disabled".  Unfortunately you can't set that property at the page level in the web.config, but disabling at the master page level should have a similar site-wide effect.
   
   <%@ Master Language="C#" ViewStateMode="Disabled" ...
   
   You could optionally set the ViewStateMode="Disabled" on one or more of the content placeholders in your master page:
   
   <asp:ContentPlaceHolder ID="ContentPlaceHolder1" ViewStateMode="Disabled" ...
   
2. Then, when you need viewstate on a certain page or control ... just set ViewStateMode="Enabled" at that location.  It is usually very obvious when you need this when you are developing the site from scratch, but this type of pattern can be more difficult to retro-fit into an existing app.  Essentially the things that typically need ViewState are controls that you will need to access the values of on a PostBack to the server (e.g. textboxes, drop downs, checkboxes, etc).
   
   One tricky thing I have ran into is that you can't set the ViewStateMode at the page level in the Page directive like this (at least when using master pages):
   
   <%@ Page Title="Dynamic Schedule" ViewStateMode="Enabled" ... // WON'T WORK
   
   Instead you should preferrably set it for the individual controls that need it that way only the ViewState data that is required would be sent to/from the client, and the page wouldn't be bloated with unnecessary ViewState data.
   
   <asp:CheckBoxList ID="cblProducts" ViewStateMode="Enabled" ...
   
   If you have many controls that you need to enable ViewState on, and you didn't want to have to set the property on all of them ... you could optionally just enable viewstate for an entire content placeholder section like this:
   
   <asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" ViewStateMode="Enabled" ...

Here are a few more helpful resources on the new ViewStateMode functionality:

http://msdn.microsoft.com/en-us/library/system.web.ui.viewstatemode.aspx
http://weblogs.asp.net/sreejukg/archive/2010/04/06/viewstatemode-in-asp-net-4-0.aspx
http://www.mostlylucid.net/archive/2009/01/28/1312.aspx

This is a T-SQL code snippet I find myself using regularly to find all references to a particular field or table, or search for comments from a particular date.  It essentially allows you to search for a keyword in all of the definitions for stored procedures, functions (scalar or table-valued), and views.  It uses some of the built-in methods SQL Server provides for obtaining metadata, which are essentially simplified views of the data contained in system tables like sysobjects and syscolumns.  I know this T-SQL script works on SQL Server 2005 & SQL Server 2008, but don't know if the methods it is dependent on were available on previous versions.

DECLARE @Keyword varchar(64)
SET @Keyword = '%keyword%'

(
  SELECT  [ROUTINE_TYPE] AS 'Type', [SPECIFIC_NAME] AS 'Name'
  FROM  INFORMATION_SCHEMA.ROUTINES
  WHERE  [ROUTINE_DEFINITION] LIKE @Keyword
 UNION
  SELECT  'VIEW' AS 'Type', [TABLE_NAME] AS 'Name'
  FROM  INFORMATION_SCHEMA.VIEWS
  WHERE  [VIEW_DEFINITION] LIKE @Keyword
)
ORDER BY [Type], [Name]

Here is an example of the results of the script:

During my career, I have written a few components that used colors to visually encode data.  Recently I found myself looking at a color chart and trying to choose colors that were easy to distinguish from one another ... again.  It seems like I have done that a few times during my career, so this time I wanted to put it to bed for good.  Instead of relying on my unscientific approach, I figured this had to be a problem that someone solved before ... and Excel came to mind.

When you create a chart in Excel, it automatically assigns each series a different color.  Microsoft almost certainly poured a ton of research/money into this same problem I was trying to solve:

Which set of colors are easiest to differentiate from one another?

They probably also took visual disabilities into account, like color blindness (which I have) and poor vision.  So why reinvent the wheel with this stuff?  Here is a pie chart that displays default color series Excel 2007 automatically assigned to a simple pie chart, which includes the HEX and RGB values for each series color:

A few things to keep in mind

• Here is an helpful excerpt from Information Dashboard Design (a very research driven book) on this topic: "When organizing data into distinct groups using different expressions of any preattentive attribute, you should be careful not to exceed five distinct expressions. ... When using hue, keep in mind that even though we can easily distinguish more than five hues, short-term memory can't simultaneously retain the meaning of more than about nine in total."
• When using colors to visual encode information, think about what it would look like if printed in black and white.  Would you still be able to distinguish between the different series or groups, or would that encoding be lost without color?  Although the project you are working on may never be printed black and white, almost 10% of males have some type of color blindness ... so thinking through this scenario can help you understand their perspective.  Usually adding a label (like the numbers in the example above) or patterns (e.g. stripes) in addition to color would be enough to enable someone to make sense of the encoding, even if they aren't able to process it preattentively like the color coding.

Here is a C# code snippet that I use, which returns a list of the related colors outlined above:

/// <summary>
/// Returns a list of colors derived from the defaults Excel uses for chart series.
/// These colors should be very easy to differentiate from one another.
/// </summary>
public static List<Color> DefaultExcelColors
{
    get
    {
        return new List<Color>()
            {
                Color.FromArgb(69,114,167),
                Color.FromArgb(170,70,67),
                Color.FromArgb(137,165,78),
                Color.FromArgb(113,88,143),
                Color.FromArgb(65,152,175),
                Color.FromArgb(219,132,61),
                Color.FromArgb(147,169,207),
                Color.FromArgb(209,147,146),
                Color.FromArgb(185,205,150),
                Color.FromArgb(169,155,189)
            };
    }
}

A few weeks ago, I started noticing that every time I opened a LINQ to SQL .dbml file in Visual Studio 2008 I would get an alert message that said "The connection property in the web.config file is missing or incorrect.  The connection string from the .dbml file has been used in its place."

The dbml file was configured to reference a connection string in the web.config file, but after I got this alert and clicked OK, Visual Studio would check out the project and add a new Settings.settings file under the Properties folder and generate a new connection string there, and then change the dbml file to reference that instead of the web.config.

This would probably be the behavior you would expect if the web.config was really missing the connection string, but in my case the referenced connection string was there and well-formed.  I know this, because the related code was under source control and other developers could open the same dbml file (from the shared code base) and they wouldn't get the alert and everything worked flawlessly.

To me, it seemed like the LINQ to SQL designer on my machine was simply having trouble reading from the configuration file ... so I thought it might be an issue with a particular dll or registry entry.  Another thing that convinced me of this was the fact that when you were in the dbml editor ... under the Connections property on my computer, none of the connection strings from the web.config were included in the drop down to select from.  But, when another developer would look at this on their machine (using the same exact code base and files), their Visual Studio environment would find those connection strings in the web.config and include them in the list to select from.

I figured out that I could just undo the changes to add the new file, and then view the differences of the dbml file's XML and undo the reference change to make it once again reference the web.config instead of the settings file it created ... and that worked fine for a couple weeks, but eventually jumping through those extra hoops that "should just work" got pretty old.

So I first tried to repair my Visual Studio install, but that didn't work.  Next, I completely uninstalled Visual Studio and then re-installed it and the related service packs ... but that didn't work either.  I was about to just format my machine and re-install Windows ... but I thought I would give Microsoft Support a chance, hoping they could help me.  I knew this was an obscure enough problem that they probably wouldn't be much help, but I really hate paving my machine ... so it was worth a little time to give them a chance.  After explaining what was going on to a technician, we tried to use ProcMon to figure out what was going on behind the scenes.  We noticed several registry errors, and that further convinced me that the problem was corrupted  or missing registry keys.  The support technician said he would have to look into it more, but I wasn't going to count on them as my only hope for a solution ... so I kept investigating myself.  Apparently when you uninstall Visual Studio, it doesn't remove all of the registry keys.  It also doesn't overwrite them all when you run a repair.  It doesn't even remove them all when you remove all the other software that might have hooks or add-ins related to Visual Studio.  So these corrupted or missing registry keys could have persisted through the repair and re-install.

Here are some of the issues we noticed in ProcMon (it is a snapshot of what was happening when I would open the dbml file and the pop-up alert would appear, and then I would click OK).  The one highlighted is the what I was guessing was the culprit, because that missed registry key occurred right between the read of the dbml file and the opening the related project (which I am guessing was to create the new settings file).  You can ignore the "Fast IO Disallowed" stuff, because that is unrelated.

So, although the support technician had actually explicitly advised me not to do this ... I decided to uninstall Visual Studio (and any other software add-ins that might be related to it), manually delete the related registry keys contained in any folder that appeared related to Visual Studio, and then do a fresh install.  I never think hacking in the registry is a good solution to a problem, but this was my last ditch effort ... and I was resolved to do a full re-install of Windows if it didn't work.  To my surprise ... it actually worked.

I can't guarantee this will work for you, or even recommend it ... but here are the registry folder locations I manually deleted:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\VSCommon
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\VSTAHost

Hopefully if you are still reading, this is the exact problem you are having and this will work for you as well.  The only thing I can say is ... it worked on my machine, and it saved me from having to completely re-install Windows to fix the problem.

We recently ran into a problem up at work where people were opening a particular spreadsheet from a network fileshare, which had a lot of formulas that were tied to a few inputs.  You would typically change one input cell, and a lot of the other related cells would be recalculated and updated automatically.  However, a wierd issue started occuring where some users would change the input and nothing would happen.  But ... when they saved the worksheet, all of the related calculated cells would be updated at that time.

I think the issue was related to one person opening the spreadsheet on a Mac that was running Office 2008, and when they saved it we noticed it changed a lot of subtle things like the colors or formatting ... but I think it may have also changed the formulas to be manually updated and only automatically updated when the file is saved, which is an Excel Option.  Regardless of how this issue occurred ... here is the fix:

1. Open Excel, and click on the  icon in the top left of the window, then go to Excel Options.
   
   
2. Then go to the Formulas tab, and change the Calculation options to Automatic, and hit OK to apply the changes.