如何设置DataRow对象字段？VB转C#迁移SetField报错及最佳实践咨询

First, Fixing the SetField Error #

Your error happens because SetField is an extension method from the DataRowExtensions class, which lives in the System.Data.DataSetExtensions assembly. Here's how to fix it:

• For .NET Framework projects: Right-click your project → References → Add Reference → Find and check System.Data.DataSetExtensions.
• For .NET Core/.NET 5+ projects: This assembly is included by default in the framework, and you already have the required using System.Data; directive, so that part is covered.

Also, there's a small mistake in your original code: ToShortDateString is a method, not a property—you need to add parentheses () to call it, otherwise you're assigning the method itself to the field instead of its return value:

// Correct usage of SetField
targetDataRow.SetField("DateValue", calendarRow.DateValue.ToShortDateString());

Is the Indexer Approach (targetDataRow["DateValue"] = ...) a Best Practice? #

Short answer: It’s a common, acceptable practice, but there are tradeoffs compared to using SetField. Let’s break down all your options:

1. Indexer (String Column Name) #

This is the most widely used approach, with these pros and cons:

• Pros:
  • Intuitive and readable—you explicitly name the field you’re setting
  • No extra assembly references required
  • Clean, concise syntax
• Cons:
  • No compile-time type checking: Typos in column names or mismatched data types will only throw errors at runtime
  • For nullable fields, you have to manually use DBNull.Value instead of null (e.g., targetDataRow["DateValue"] = DBNull.Value; for a nullable date column)

Example:

// Correct indexer usage (don't forget the () on ToShortDateString!)
targetDataRow["DateValue"] = calendarRow.DateValue.ToShortDateString();

2. DataRowExtensions.SetField #

This is the more type-safe option, with these benefits:

• Pros:
  • Generic overloads enable compile-time type checking (e.g., SetField<string>("DateValue", ...) ensures you’re assigning a string to a string column)
  • Automatically handles nullable types: You can assign null directly, and the method converts it to DBNull.Value for you
  • Reduces the risk of runtime type conversion errors
• Cons:
  • Requires referencing the System.Data.DataSetExtensions assembly (as covered earlier)

Example:

// Generic overload for type safety
targetDataRow.SetField<string>("DateValue", calendarRow.DateValue.ToShortDateString());

// Handling nullable fields seamlessly
targetDataRow.SetField<DateTime?>("NullableDate", null); // Auto-converts to DBNull.Value

3. Indexer (Column Index) #

This approach is not recommended. While it’s concise, it relies entirely on the order of columns in your DataTable. If the table structure changes (e.g., adding/removing columns), your code will break immediately, and it’s much harder to read:

// Not recommended—column order changes will break this
targetDataRow[1] = calendarRow.DateValue.ToShortDateString();

Final Recommendations #

• If you prioritize type safety and minimizing runtime errors, go with SetField—just make sure your project references System.Data.DataSetExtensions.
• If you need simplicity and don’t want to add extra references, the string indexer approach is totally fine. Just double-check column names and data types, and remember to call methods like ToShortDateString with parentheses.

内容的提问来源于stack exchange，提问作者Adham Enaya