My favorites are new features to make code navigation simpler:

• Call Hierarchy: being able to see in design mode what method calls and is called by other methods is brilliant! This is only available for C# in this revision, but that’s really the only .Net language I code in anyway.
• Navigate To: an easy way to type any part of an identifier name and find it anywhere in the current solution.

I’m really happy about this. One of the most cumbersome things when working in Visual Studio has been navigating through code.

I still miss one of the best features of Visual DataFlex Studio, Code Explorer, in Visual Studio. While I appreciate the improvements for making code easier to find in VS 2010, I always have Code Explorer open in the Visual DataFlex Studio. Code Explorer is a docking panel that displays the structure of the current code file. This makes it very easy to locate a class, object or method with a click.

Class View at first appears somewhat similar, but the way it’s implemented, it still takes a lot more steps to find something.

This is great; it allows you to develop and run a database application without requiring a connection to an SQL Server or even installing SQL Server on the client PC that runs the application. You can then use this as a standalone single user application or synchronize data between the application’s local cache and a running SQL Server database.

When you create a new strongly typed DataSet in the Studio via Data > Add New Data Source, if the data source is an SQL Server database, you get the option to “Enable local database caching”. If checked, Visual Studio will automatically create a Local Database Cache (.sync) file and add it to your project. The code in your DataSet is created using System.Data.SqlServerCe.SqlCexx so that your code can connect to the SQLCE database. It also creates the local SQLCE database (a .sdf file), and adds it to your project.

The key piece in this process is the Local Database Cache (.sync) file. This is what allows you to configure which tables can be cached in your local SQLCE database. If you bring up the Configure DataSet Wizard to either create or edit a DataSet and it won’t allow you to select some tables to be cached locally, you can create or edit the .sync file. The How to: Configure Data Synchronization to Use SQL Server Change Tracking page shows you how to create this file from scratch.

If you already have a .sync file, you can configure it by right-clicking on the file in Solution Explorer and choosing View Designer from the context menu. It’s kind of hidden, but if you click the Add button to add a table (provided there are more tables available in your database that can be added), you will see a link to Learn more about which tables can be cached…, which explains the rules determining which tables can be cached.

Quite recently (August 2009) Amazon once again changed the name of their web services API and also the rules for making call to it, now requiring cryptographic signature authentication. While Amazon provides code samples, for some odd reason the only (yet new) C# SOAP sample provided by Amazon uses the dated and likely soon obsolete Web Services Enhancements (WSE) class library instead of Windows Communication Foundation (WCF). I assume this sample is for developers still using .Net 2.0, but a sample using more current technology would have been appropriate, as well.

I searched the web for a suitable sample to implement the signature authentication using .Net 3.5 and eventually came across a very appropriately titled blog entry: Signing Amazon Product Advertising API requests — the missing C# WCF sample, by Oren Trutner. Attached to Oren’s very appropriately titled blog entry are 3 samples that make implementing the calls using WCF very straightforward.

Great work and thanks, Oren!

This came to mind recently when I wrote a short routine that determines if a mapped drive is a local drive:

[DllImport("mpr.dll")]
static extern uint WNetGetConnection(string lpLocalName, StringBuilder lpRemoteName, ref int lpnLength);

// returns whether the current drive is local
internal static bool IsLocalDrive(String driveName)
{
    bool isLocal = true;  // assume local until disproved

    // strip trailing backslashes from driveName
    driveName = driveName.Substring(0, 2);

    int length = 256; // to be on safe side
    StringBuilder networkShare = new StringBuilder(length);
    uint status = WNetGetConnection(driveName, networkShare, ref length);

    // does a network share exist for this drive?
    if (networkShare.Length != 0)
    {
        // now networkShare contains a UNC path in format \\MachineName\ShareName
        // retrieve the MachineName portion
        String shareName = networkShare.ToString();
        string[] splitShares = shareName.Split('\\');
        // the 3rd array element now contains the machine name
        if (Environment.MachineName == splitShares[2])
            isLocal = true;
        else
            isLocal = false;
    }

    return isLocal;
}

There is a post on stackoverflow asking how to do this, and, like many others, it has several answers showing several ways to do this. So, is my method correct? This code seems to work, but I’ve been programming long enough to know that code that “seems to work” doesn’t necessarily work in every circumstance and could have other negatives, such as performance issues.

So, knowing that this code I may have to tweak or replace at some future point in time, I will try to encapsulate it as much as possible to make it easier to work with in an isolated manner later. By keeping the code in a separate method, I can easily use a unit test to try it in various test scenarios without affecting any other code.

Of course, this is a very simple scenario, which made it perfect for this post. It can be much tougher to abstract and isolate more complex code, but that doesn’t mean we shouldn’t strive to do so whenever possible.

My biggest problem was picking which sessions to attend, or worse, which ones not to attend.

I eventually chose to attend Sneak peek at C# 4.0 by Jimmy Bogard, who gave a similar session about C# 3.0 at last year’s camp, and 2 excellent 2 hour SQL Server sessions by Anil Desai, SQL Server Reporting Services: Report Creation and Deployment and SQL Server Performance Monitoring & Optimization. All 3 sessions were awesome, thanks guys!

Thanks to John Teague, all presenters, the Austin .Net Users Group, the sponsors and everyone else who helped make this event happen!