Since the source code to ASP.Net was made available, I’ve been using it extensively. Here’s a great example of why it’s so valuable.

I’ve been trying to integrate the Enterprise Library 3.1 Exception Handling Block into my application. My application is split into a core and web UI specific components, so I’ve defined errors in my code to be thrown when a resource is not available. The web application configuration file specifies that if a specific exception, e.g. a ResourceNotFoundException, is thrown, the Exception Handling Block should replace that exception with a 404 Resource Not Found error using Http. That should in turn use the CustomErrors feature to redirect to a 404 not found page.

Makes sense, and sounds simple, don’t you think?

Nothing in the docs says that it shouldn’t work.

But it doesn’t. It simply won’t work. Why? Well, there’s nothing on the web. But after spending some serious hours digging through the source code, I can finally see why.

Here’s a lovely little hidden-to-the-world snippet of the code I got inside of Visual Studio:

code = HttpException.GetHttpCodeForException(e);

// Don't raise event for 404.  See VSWhidbey 124147.
if (code != 404) {
  WebBaseEvent.RaiseRuntimeError(e, this);
}

So it would never work!

Nice of them to let me know.

.Net 3.5 had some nice tricks in it. LINQ-to-XML was one of them. With the new "X"-types, you can make working with XML really easy.

VB.Net 9 takes it one step further, and lets you write XML in your code without strings.

"Hey Rich, that’s old news," I hear you say. "And who’s interested in VB today anyway?"

Well, apparently there are a lot of VB-er’s still out there. I am mainly a C# developer myself, but I found that VB was perfect for a problem I had recently -  loading of XML data into a SQL Server table.

SQL Server 2005 and XML Fields

I recently came across the need to load a database with XML data fields in SQL Server 2005. I had a series of XML documents which all needed to be pumped into a table containing a field of type XML. I could have opened up SQL Server Management Studio and fired in a load of strings, but I was a bit concerned that the XML might not be formatted quite correctly, which would have caused problems in the loading process.

Another problem was that I wanted to be able to add dynamic XML. I wanted to generate some XML data on the fly. That’s not so easy with insert statements in SQL.

LINQ-to-SQL and XML Fields

Using my recently-acquired LINQ-to-SQL knowledge, I knew that the Entities generated for an XML field are translated to XElements – the new XML type in .Net 3.5. I also knew that VB 9 lets you create an XElement by using XML in code itself:

So I came up with a plan…

Inserts with LINQ-to-SQL

For data-loading, LINQ-to-SQL is magic. A simple Insert is a piece of cake.

First, create your DataContext using the Visual Studio template, then drag the table you are inserting to onto the DataContext canvas. That gives you an Entity class. You then can create an Entity in your code, call InsertOnSubmit on the DataContext table, then call SubmitChanges on the DataContext itself.

Using Object Property Initializers, you can make this really easy.

Here’s what it looks like with VB.Net using an XML datatype:

(Sorry to have torn the edge off the code there, but it wouldn’t fit nicely in my post at full width. XML can be a little long sometimes.)

The great thing here is that any malformed XML is highlighted (or even automatically corrected) for me by the VB compiler. I can also add parameters and generate lots of different XML using the familiar ASP syntax:

It’s all super-easy, and takes about 1 minute to get started.

Visual Studio 2008 has lots of goodies in it, like LINQ syntax, CSS editing, and testing tools. There’s a lesser-known feature which I really appreciate though – the “Remove and Sort Usings” command in the C# editor.

You activate the command by placing your cursor over the using statements and clicking on the right mouse-button.

Using this groovy tool, I’ve been able to go through my old ugly C# files and get rid of all the superfluous using statements, then tidy them up, all at the click of a button. It’s something I always wanted to do, but had no time for, and didn’t want to pay for an extra tool to do it for me.

The only problem with the feature is that you have to go through every file and right-click on the “using” statements to tidy them up. That can get a bit tedious, but it’s worth it.

But now it’s the Visual Studio Extensibility Team to the rescue!

The VSX team at Microsoft have just released PowerCommands for Visual Studio 2008. It’s a free tool for Visual Studio with loads of new tools for making a VS-developer’s life easier. And one of those new tools is a Remove and Sort Usings command at the project level.

You activate it with a right-click on the project itself.

The tool then does the same Remove and Sort command for every file in the project.

Tip: Make sure your project is buildable before using the tool. If there is an error stopping the build from running, you will get dialogs asking you to confirm every change in every file.

PowerCommands for Visual Studio 2008 also contains commands for:

• Collapse Projects
• Copy Class
• Paste Class
• Copy References
• Paste References
• Copy As Project Reference
• Edit Project File
• Open Containing Folder
• Open Command Prompt
• Unload Projects
• Reload Projects
• Remove and Sort Usings
• Extract Constant
• Clear Recent File List
• Clear Recent Project List
• Transform Templates
• Close All

So, where can you get the tool?

The official site for PowerCommands is at the Visual Studio Gallery, but when you get there, you won’t see a download button. You actually have to click the “Learn More” button to go to the download page at the MSDN code gallery.

You can read more about PowerCommands on the Visual Studio Team Extensibility blog.

Yesterday I thought I’d learn about the LinqDataSource in ASP.Net 3.5, and got an interesting surprise.

The new LinqDataSource can also be used with a LINQ-to-SQL model to perform updates. You simply add the DataSource to your page, set the table name, and set EnableUpdate to true. Then, using a standard DataControl, you can make updates to your data entities.

The question is, how does this work? It appears to be a bit magical.

The Magic of LINQ

In a previous post, I mentioned that LINQ-to-SQL updates can be done in two ways: either you make a call to retrieve a row, then update it, or you provide known values for all fields and try to update using optimistic concurrency.

If the LinqDataSource used the first technique, the performance might be bad. Plus, it would have to only update those fields that had been updated by the DataControl, and ignore the rest. That wouldn’t make sense, so I correctly supposed that was not what was happening.

It makes more sense that the LinqDataSource would use the values input by the user to make the changes. It could use optimistic concurrency to compare all the entered values.

The problem is, I don’t always display all fields from a particular row on the form, so how would the LinqDataSource know what the missing fields were. Remember, all the fields involved in the update are required for the optimistic concurrency to work. That is usually all the fields in a row, and they aren’t usually all displayed.

So, have a guess. Where does the LinqDataSource store it’s values?

Let’s think now. Where would be the easiest place to keep it? To keep it really simple, I’ll let you ignore all other aspects of building an application, like security or performance.

Yep, you guessed it – ViewState.

The ViewState actually contains all values for all the fields in a LINQ-to-SQL entity by default. Those values are sent to the client, even if the user isn’t supposed to be able to see them.

Aaaarrgghhhh!

Now, let’s not get overexcited. The ViewState is encoded, so it’s not easy to just go and change it. But it’s not impossible. In general, I don’t think it’s such a great idea to have all data sent to a client by default. Someone is going to overlook something one day, and there’ll be a costly mistake.

And what if you display a large grid using the LinqDataSource. Well, you aren’t just getting the ViewState from the grid sent back and forth with your page, but the LinqDataSource is going to store all your data retrieved in the ViewState too.

Bummer!

Great control. Large overhead.

Kicking out the ViewState

The good news is that the ASP.Net team realized that this was a problem and did something about it.

If you look carefully, you will notice that the LinqDataSource has a property StoreOriginalValuesInViewState. By default (sigh) that property is set to true. If you set it to false, the control won’t work any more. Simple as that.

Here’s what the official documentation has to say about that:

If you set the StoreOriginalValuesInViewState property to false, the original values are not persisted in view state for the data-bound control. In that case, LINQ to SQL cannot verify the integrity of the data. LINQ to SQL will throw an exception that indicates a data conflict even if the data in the data source has not actually changed.

That’s in the remarks section of the LinqDataSource.StoreOriginalValuesInViewState property documentation.

Funnily enough, the same section states the problem with stuffing data into the ViewState:

Storing the original values in view state can cause the page size to become unnecessarily large and can expose sensitive data to a malicious user.

Now, I don’t know about you, but that looks like a pretty serious warning to me. Why isn’t it in a more obvious place, like as a comment that pops in up Intellisense whenever you use a LinqDataSource?

Check the UpdateCheck

So how do you handle it? How can you use the LinqDataSource?

The answer lies in the generation of the LINQ-to-SQL model which you generate. Each entity field has a Column attribute which allows you to specify if it is used for checking during an optimistic concurrency field comparison.

For example, you could create a Model with the following Property:

[Column(Storage="_AddressID", UpdateCheck=UpdateCheck.Never, ...
public int AddressID
...

Notice the UpdateCheck.Never value. That means that the field will not be used in the optimistic concurrency check.

The documentation helps a little again:

By default, when update and delete operations have been enabled, the LinqDataSource control stores the original values for all the records in view state. The LinqDataSource control stores values for all primary keys and all properties not marked with UpdateCheck.Never in the Column attribute. You set the UpdateCheck property of the Column attribute in the O/R Designer.

Admittedly, I haven’t yet tried that, so I don’t really know how if you can change that setting for a field without changing generated code, which would be a big no-no. I’ll just have to get back to you on that.

Stamp In, Please

However, there is a shortcut trick.

Basically, if you add a field of type timestamp to your record, only that field will be used for the concurrency check, and only that field’s data will be stored in the ViewState.

If the underlying data source contains a timestamp field that is automatically updated during an update, you can store only that value in view state. In that case, the timestamp property in the entity class is set to IsVersion=true and all the properties are set to UpdateCheck.Never. Because a timestamp field is automatically updated by the database every time that data in that record changes, LINQ to SQL determines from that value if data has changed. This helps reduce the size of view state, and no sensitive data is exposed. LINQ to SQL will check for data consistency by comparing the timestamp value in view state with the timestamp value in the database.

The documentation is great, if you know where to find it.

Conclusion

So, the answer is, if you use the LinqDataSource to throw a quick application together, make sure you use a timestamp field in your table. Call it UpdatedOn, or something. It will make the use of the LinqDataSource a lot easier, if only because you’ll sleep better not worrying about it.

Until recently I thought this was a well-known feature. After demonstrating it a few times, I found out it wasn’t.

A long time ago, in an cubicle far, far away, someone created the .Net Framework. To cut a long story short, they simultaneously produced guidelines for creating Exception classes, which you should always use or face having your fingernails pulled out with a staple-gun.

The guidelines state:

“Use the common constructors shown in the following code example when creating exception classes. “

[C#]

public class XxxException : ApplicationException
{
public XxxException() {… }
public XxxException(string message) {… }
public XxxException(string message, Exception inner) {… }
public XxxException(SerializationInfo info, StreamingContext context) {…}
}

If you don’t believe me, you can look here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconerrorraisinghandlingguidelines.asp

Now, I don’t know about you, but I can’t remember all that every time I create a custom exception class. Maybe that’s why the guidelines also state:

In most cases, use the predefined exception types. Only define new exception types for programmatic scenarios, where you expect users of your class library to catch exceptions of this new type and perform a programmatic action based on the exception type itself.

But let’s ignore that. It’s not relevant.

So, did you know that there is a Visual Studio code snippet that does the work for you? Here’s how you use it.

1. Create a new class.
2. inside the namespace definition of the new class, type

   Exception

3. Press the tab key twice.

You then get the following code, free of charge:

[global::System.Serializable]
public class MyException : Exception {

  public MyException() { }
  public MyException(string message) : base(message) { }
  public MyException(string message, Exception inner) : base(message, inner) { }
  protected MyException(
  System.Runtime.Serialization.SerializationInfo info,
  System.Runtime.Serialization.StreamingContext context)
    : base(info, context) { }
}

What’s more, you get code snippet functionality which automatically changes the names of all the constructors when you change the name of the class.

I wonder what other code snippets are available. Do you know of any cool ones? What are your favorites?

Scott Guthrie has just announced that the source code for the .Net framework has just been made available for reference use.

It will be particularly useful to see how the controls in ASP.Net and Windows Forms have been done.

Detailed instructions for how to set it up are here.

One caveat: it’s not available for the Express editions of Visual Studio. Shame! I was just starting to have some fun with them too.

I was recently asked to do some research and give a presentation about using Visual Studio Team System 2008. I thought I’d experiment with Slideshare.net and post it here.

The presentation was for a large corporation, and will possibly not come across as being very useful for an online presentation. I have been working on it for a while though, and I think it’s worth publishing, if only as an introduction.

I’ve used competitive products to Team System for a long time, mainly open source:

• SubVersion for source version control
• CruiseControl.Net as a build server
• NAnt for build scripts
• MbUnit for testing
• NCover for seeing my testing code coverage
• VersionOne for project planning, task management, tracking and reporting
• BugTracker for bug tracking
• A Wiki for project documentation and guidelines

I wasn’t all-too impressed with the standard of Visual Studio Team Suite 2005, but I am a little bit happier with the 2008 version. It took a while to get it installed so that I could test it, and there were lots of seemingly undocumented points which hindered my progress, but once I’d got it up-and-running, I didn’t find it that bad. (I did have to install it on  virtual machine, and run it on my laptop.)

I think the best thing about Team System is that all the things I need to do are now integrated into one place. I didn’t have to go make changes to a dozen XML files in order to get a build server working. I didn’t have to install a Wiki for the project documentation. Using Team System would also avoid resistance to using the products, as I’ve faced before trying to get other team members to use such tools. Everything would just be there, out-of-the-box, and no one would argue about using them.

What I didn’t like about Team System are some of the subtle details which don’t work as they should do. I did a basic test of multiple check-outs, using the new features, but it didn’t work. The Unit Tests that I generated were confusing and were buggy.

The biggest problem though is the price. It’s darn expensive. I wouldn’t be able to afford Team System if I was just a small development shop. However, for a large corporation, it really could make sense.

I actually wonder if there’s room for a better competitor (Rational is possibly the only serious contender, and I find their software pretty naff). It actually wouldn’t to be too hard for some Python hackers somewhere.