A Base-64 Decoder That Works!

Let's face it...  debugging ASP.NET production websites can be challenging.  HTML sessions are 'stateless', meaning from one post to the next, the server has no idea what post came first.   For example, let's say there is a website that prompts the user for their name on one page, and on the subsequent page the user is prompted for their address.  Well, the server has no intrinsic way to join the data together from those two pages to save it all in a table somewhere.

Web scripting language use various methods to store this state information.  Some use cookies to store the data from one page to another.  Some use a unique key, placed into a cookie, or in the URL as a parameter to retrieve the data from an internal 'session store' on the server.  ASP.NET can save the session state several ways.  One way to save part of the session state is in something called a ViewState.  This is basically the state of a page; just part of the entire session state.

Well, this ViewState is stored right in the web page as a 64 bit encoded string.  It's not encoded but definitely looks that way.  It's unreadable without a decoder.  Anyway...  If something is stored in the ViewState, programmers can have a bitch of a time trying to pull it apart and see the data.  But...  This information can be invaluable to debugging a production problem.   There are varied ViewState tools on the web for decoding this gobeldygook into something that is somewhat coherent.  I use Base64 decoder and encoder at motobit.  It's simple and works.

Simple Is Still Simple

Yes, contrary to the conventional state of technology and computer programming, simple is still simple.  Well, at least it should be.

Quite frequently I read different articles about programming in an attempt to maintain professional relevance.   Some are well written articles on good programming techniques.  Some are poorly written but the core material is still good.  Some are well written pieces about some fluff fad and then there are occasionally the poorly written article about some programming technique or library or concept  that has 'bad idea' written all over it.

OMG .NET, You Are Crazy!!!

OK, so I am doing something simple...  adding a ControlParameter to a SQLDataSource.  I just want to add it as an optional filter.  The ControlParameter points to a TextBox.  Like this...

<asp:ControlParameter ControlID="txtFiltCC" Name="TCity" PropertyName="Text" Type="String" DefaultValue=""/>

Not only does the result return nothing, according to the Microsoft SQL Server Profiler, the query is never even sent to the server!!!  

What the HELL!?!?!?!?

I change the SelectCommand to not use the @TCity paramater and still...  no query sent.  The GridView bound to the SQLDataSource reports that no records were retrieved.   Hmmm...  makes sense since according to SQL Server Profiler, no query was sent.

Then I find the ConvertEmptyStringToNull property on the ControlParameter.  It's default is 'True'.  Hell, I don't want it to be null, so I change it to False.  Friggin SHAZAM!  The SQL query is sent and I get a result set.  Why the HELL would the ConvertEmptyStringToNull cause a query to not be sent, especially if the parameter isn't even used in the query????  This works fine...

<asp:ControlParameter ControlID="txtFiltCC" Name="TCity" PropertyName="Text" Type="String" ConvertEmptyStringToNull="False" DefaultValue=""/>

Really, Microsoft...  This is a crazy little piece in ASP.NET

So...  For anyone scratching their head about a GridView not being populated from a SQLDataSource that is using a ControlParameter pointing to a TextBox, this just may be the solution.

C# Background Workers Using Shared Memory

It doesn't happen often in my particular coding shop, but once in a rare while the requirement for different threads in a program to use a shared memory variable rears it's head.  It really isn't difficult to handle this requirement in C#; actually, it is surprisingly easy if you are careful to avoid deadlock situations,

The key to this solution is a simple static class:

using System;
using System.Collections.Generic;
using System.Text;

namespace ThreadCom
{
    static class StaticShare
    {
        public static object MsgLock = new object(); // Functions as a lock when accessing Messages.
        public static string Messages = ""; // This is what is shared and used in all threads of this sample program.
    }
}

Basically, this snippet of C# code creates a static class with two public properties: MsgLock and Messages.  MsgLock is used to control access to Messages; a string that contains the data shared among the different threads.  Remember, performance is important; keep the shared static variable terse and small.

Here is how a thread (specifically a BackgroundWorker) might use the StaticShare class to lock, access and change the shared data without causing noticeable contention or throwing exceptions:

                lock (StaticShare.MsgLock)
                {
                    ReportProgress(0, "From " + BWName + " -> " + StaticShare.Messages);
                    StaticShare.Messages = BWName + " current time: " + DateTime.Now.ToString();
                }

The first line locks MsgLock, or causes the thread to wait until another thread's lock is released.  The ReportProgress() line is a method belonging to a BackgroundWorker, that line, in this case is accessing our shared variable Messages.  The last line in the Lock() block assigns something to the shared variable.

One big caveat here...  Make the code within the lock() block short, concise, to the point and fast.  If the code there is time-consuming or performs poorly, the lock() could cause other threads to be blocked.

Remember...  thread blocking is not cool!

You can download the entire c# project from my Google Drive here.  Standard code disclaimer: This code is for education, information and perhaps a few laughs.  It may not be perfect but does demonstrate a valid implementation of using shared storage with a multi-threaded C# application.

-whew-

C# Programming Tip - ViewState

A C# page's ViewState is a real cool place to put state information and variables you want to stick around for the lifetime of a web page.  Actually, most ASP page components save their state information in the ViewState.

Saving stuff in the ViewState is easy.  Here is an example:

ViewState["mode"] = "A"

Accessing it is easy as well:

if (ViewState["mode"].ToString() == "A") {...}

You can also do cool things like put more complex items in the ViewState like:

SomeComplexClass ComplexObject = new SomeComplexClass();
...
ViewState["ComplexObjectVS"] = ComplexObject;
...
SomeComplexClass ComplexObjectCopy = (SomeComplexClass)ViewState["ComplexObjectVS"];

So long as the object is seralizable (more on that later), you can save it in the ViewState.  There is a big drawback... space and bandwidth.  A page's ViewState is stored in the page!  So, each time the page loads, is posted or there is a postback, the entire ViewState is sent over the network.  If you want to maximize the efficiency of your page, minimize your ViewState usage.  The size of a ViewState can grow quickly if you have a large and/or complex page.

Also...  ViewStates are NOT secure.  With enough smarts a person can decode them, so don't put anything in the ViewState that you want to keep secure.

For those curious, here is what a simple ViewState looks like in a simple page:
<input id="__VIEWSTATE" name="__VIEWSTATE" type="hidden" value="/wEPDwUJNzkzMjk1ODg4D2QWAmYPZBYCAgEPZBYCAgsPDxYCHgRUZXh0BQgxLjAoZGV2KWRkGAEFHl9fQ29udHJvbHNSZXF1aXJlUG9zdEJhY2tLZXlfXxYBBSZjdGwwMCRNYWluQ29udGVudCRMb2dpblVzZXIkUmVtZW1iZXJNZbVBilGyAMpTuiSmFozdPPwfgNyhxhHXWwhU4O2NRdBd" />