Today, I uploaded the first minimal release of LINQ to Twitter.  LINQ is the acronym for Language Integrated Query, which is a new set of lanugage features for both C# and VB.NET that allow you to query data sources with syntax that is part of your programming language.  LINQ is an extensible technology, much like the rest of the .NET Framework, that allows you to reuse and extend the basic capabilities.  .NET ships with a few providers already, including LINQ to Objects, LINQ to SQL, LINQ to DataSet, and LINQ to XML.  LINQ to Entities, for the new ADO.NET Entity Framework, was recently released as part of the .NET 3.5/VS2008 SP1.  Some day (I don't know the date) in the future, Microsoft will release another LINQ provider named LINQ to Data Services, which allows you to query ADO.NET Data Services (formerly code name Astoria); a web-based service for accessing data in the cloud. Because of its extensibility there are many more LINQ providers, including LINQ to Oracle, LINQ to DB2, LINQ to MySql, and many more.

 

LINQ to Twitter is another example as a LINQ provider.  It is open source, available via CodePlex, and works similarly to any other LINQ provider. But that's the beauty of LINQ; regardless of data source, my query syntax stays the same.

The team at Mayo Software, including myself, have been hitting LINQ to SQL heavy since before C# 3.0 was RTM with many lessons learned along the way.  I've done some C# presentations over the last couple of years, which included a lot of LINQ material, but mostly at the presentation level. So, when it came time to give another presentation, LINQ was definitely on my mind, and I decided to do Advanced LINQ to SQL. If you're in Denver and can make it, you're welcome to stop by and say "Hi!"

As you might know, in a team environment, breaking the build is a painful experience in terms of cost, loss of productivity, and schedule delay. So, many teams, mine included, come up with processes to ensure it doesn't happen.  For all of our best intentions, stuff happens, and the build gets broken on a rare exception.  One of the anomalies that I've experienced recently was ASP.NET file renaming. Here's how it works:

 

1. User #1 renames *.aspx.

2. VS renames *.aspx.cs for User #1.

3. VSS renames file in source control, but User #1 has not done a check-in.

4. Because User #1 hasn't done a check-in, the @Page directive on the *.aspx in source control hasn't changed.

5. The CodeFile attribute in the @Page directive on User #1's local machine reflects the newly refactored name of the *.aspx.cs file, but that content is not yet checked into the VSS database.

6. User #2 does a Get Latest and they receive updates with the new file names, but the old content, including the @Page directive with the CodeFile attribute that points at the old file name, which no longer exists.

7. Because the build was broken at Step #3, User #2's code won't compile.

 

There are probably multiple resolution strategies to help get out of this problem, which depend on the process you use.  It is best if User #1 fixes the problem; They have intimate knowledge of that piece of code and what it should be doing. The best solution is prevention, and knowing what happens in VSS when you rename files can lead you to a more reliable process. i.e. delay the rename until you are near the end of your task and will be able to *reliably* check-in soon after.

One of the features of installing products that I've become accustomed to over the years is that the installation will wait on me forever if I need to interact with it. Today, I was installing a program (I won't mention which one because there isn't really anything wrong with the program and I don't want to accidentally give someone the wrong impression), which is typical of any other software installation, clicked a few buttons, and let it run. I turned my head for a few minutes, expecting the installation to continue and then wait for me when I decided to resume. When I returned to the install, I received an error message that the installation had failed. BTW, it was a pretty good message because it pointed me to the install.log file. Before trying to look up the error code from the log file, I decided to run the install again and watch what was happening. The culprit was security dialogs that ask me if I would like to continue. If you don't acknowledge these dialog windows within a certain amount of time, they fail the install. So, the second time around, I acked the security windows and the install proceeded smoothly. Again, there is discomfort when things don't work the way we are accustomed to, but security is important and Vista is protecting us from what would definitely be greater discomfort with uncontrolled malicious code. This is good - Really.

I was doing maintenance on some ADO.NET code that was using TableAdapters and encountered the following error:

 

Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints.

 

I found the simplest answer on Eric Charran's blog: After VS2008 breaks on the exception, open the Immediate window, and call GetErrors on the DataTable. You can index into the collection by typing myDataTableRef.GetErrors[0].