jcarle.com » .NET Framework

Trusting Network Shares with Visual Studio 2010 / .NET Framework v4.0

Jean-Sebastien Carle — Thu, 20 Jan 2011 21:10:28 +0000

If you are like me and you store all your code on a server, you will have likely learned about trusting a network share using CasPol.exe. However, when moving from Visual Studio 2008 (.NET Framework 2.0/3.0/3.5) over to Visual Studio 2010 (.NET Framework 4.0), you may find yourself scratching your head.

If you are used to using the Visual Studio Command Prompt to quickly get to CasPol, you may find that some of your projects will not seem to respect your new FullTrust settings. The reason is that, unless you are carefully paying attention, the Visual Studio Command Prompt defaults to adding the .NET Framework 4.0 folder to its path. If your project is still running under .NET Framework 2.0/3.0/3.5, it will require setting CasPol for those versions as well. Just a note, I have also personally had more success with using 1 as a code group instead of 1.2.

To trust a network share for all versions of the .NET Framework, simply call CasPol for each version using the full path as below:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1 -url file://YourSharePath\* FullTrust
C:\Windows\Microsoft.NET\Framework\v4.0.30319\CasPol -m -ag 1 -url file://YourSharePath\* FullTrust

Communicating multi-byte integers across platforms

Jean-Sebastien Carle — Thu, 06 Jan 2011 05:36:35 +0000

Developing applications that communicate between different platforms can quickly hit ground if multi-byte integers are sent without taking the proper byte order into account. We often forgotten to watch for this as most of us stick to a single platform during development. Thankfully, the .NET Framework has taken all the guesswork out with a pair of simple methods.

Before transmitting integers over the wire, a quick call to IPAddress.HostToNetworkOrder() will change the byte order to the communications standard of significant byte first. Receiving integers also requires a single call to IPAddress.NetworkToHostOrder() to ensure the proper value is understood from the incoming bytes.

Read over the “Sockets Byte-Ordering Primer” article over at codeguru.com and the “Converting & Sending Sockets Data with a Leading Length Value” article over at developer.com for some great in-depth explanations on the matter.

Extending the SqlDataAdapter with a FillTimeout

Jean-Sebastien Carle — Tue, 21 Jul 2009 04:30:24 +0000

The SqlDataAdapter has a CommandTimeout property but does offer any method to set any kind of timeout during the Fill method. If you are returning rather large data sets, you can quickly run into a problem. The obvious solution would be to inherit the SqlDataAdapter and simply override the Fill method, except that the SqlDataAdapter cannot be inherited. As a result, we must implement the same methods that the SqlDataAdapter does and attach them to a private internal SqlDataAdapter to do all the heavy lifting. With the use of anonymous delegates, we can easily rework the Fill methods to offer a new FillTimeout property and throw an exception when we exceed our desired timeout.

public int FillTimeout
{
    get { return _fillTimeout; }
    set { _fillTimeout = value; }
}

public int Fill(DataSet dataSet)
{
    if (_fillTimeout == 0)
    {
        return _adapter.Fill(dataSet);
    }
    else
    {
        int rows = 0;
        Thread fillThread = new Thread(delegate() { rows = _adapter.Fill(dataSet); });
        fillThread.Start();
        if (fillThread.Join(_fillTimeout * 1000))
        {
            return rows;
        }
        else
        {
            try
            {
                fillThread.Abort();
            }
            catch (ThreadAbortException)
            {
                Thread.ResetAbort();
            }
            throw new TimeoutException();
        }
    }
}

Download the full ExtendedSqlDataAdapter class : ExtendedSqlDataAdapter.cs