ASP.NET 2.0 Remote debugging

How to implement remote debugging in Visual Studio 2005
Remote debugging setup is greatly simplified in Visual Studio 2005. Although the DEBUG verb is still sent to the Web site to ensure that the remote process is running, all remote debugging scenarios except T-SQL debugging use the Remote Debugging Monitor (Msvsmon.exe).

Keywords: VB.NET, C#.

Visual Studio for Database Professionals

Scott Guthrie announces
Visual Studio for Database Professionals and other Cool Data Management Tools for .NET
"VS for Database Professionals has been getting rave reviews, and includes support for database refactorings, schema and data comparisons, database unit testing, and automated data generation."

Visual Studio .NET 2005 automatization script

Scott Allen explains how to automate SiteMap generation by VB script macro.

Technologies: ASP.NET 2.0, C#.NET, VB.NET, Web Site Map.

Beware of HtmlEncode in GridView DataBound fields

I tried to use asp:BoundField DataFormatString="{0:d}" in asp:GridView for displaying date in short format.
Unfortunately it didn't work - I still was getting long date format, completely disregarding DataFormatString property value.

After some googling I found out that HtmlEncode needs to be set to false, in order to allow DataFormatString property work.

Read this
MSDN HtmlEncode note:
"When the HtmlEncode property is true, the value of the field is HTML encoded to its string representation before the formatting string is applied. For some objects, such as dates, you might want to control how the object is displayed with a formatting string. In those cases, you must set the HtmlEncode property to false."

Technologies: ASP.NET 2.0 ASP.NET 2005 C# VB.NET GridView control DataBound field.

Concurrency problem with auto-binding GridView

I always was suspicious about using ObjectDataSource as data source for ASP.NET 2.0 controls. It saves you some C# (or VB.NET) coding, but adds lots of automatically generated ASPX stuff, which is hard to maintain. Plus flexibility of the code is just not there.

Now I have another good reason not to use ObjectDataSource and automatic binding, because such approach has serious concurrency issues.
Basically if two users are using the same page simultaneously, they could delete rows which they didn’t intend to delete.

This ugly bug caused by the fact that datagrid is trying to delete rows based on row index, not based on row ID.
Read more details about the issue in: Concurrency issues with GridView by jdcrutchley.

Scott Mitchell provides a workaround (hack) to this problem, so you still can use ObjectDataSource. However the need of using hacks just kills the whole idea of using ObjecDataSource with automatic GridView binding. The advantage was to make coding easier. Now the coding with ObjecDataSource is getting more complex than straitforward approach which I like to use:
============
<asp:GridView ID="gridView" runat="server" AutoGenerateColumns="false">
  <Columns>
    <asp:TemplateField HeaderText="Delete">
      <ItemTemplate>
        <asp:LinkButton ID="Delete" runat="server" Text="Delete" OnCommand=" Delete_Command" CommandArgument='<%# Eval("RowId") /%>' />
      </ItemTemplate>
    </asp:TemplateField>
  </Columns>
</asp:GridView>


protected void Page_PreRender(object sender, EventArgs e)
{
  gridView.DataSource = MyBusinessClass.GetMyData();
  gridView.DataBind;
}

protected void Delete_Command(object sender, CommandEventArgs e)
{
  int rowId = int.Parse(e.CommandArgument);
  MyBusinessClass.DeleteRow(rowId);
}
============