C# typed vs untyped data-set

[stax76]

I want to build a small tool that shows MediaInfo for all files in a folder including sub folder in a WinForms DataGridView. I've a list of all MediaInfo properties with Objects of type Prop from which I could define an untyped data-set, it's a very very long list which I created with the sublime text multi cursor feature, probably only 10% of all this properties are actually useful, it's probably not too hard to define the most important properties with the designer to get a typed data-set. I want to store the data-set with XML for caching. I never worked with data-sets before, in general I prefer objects and static types, is it better to use a typed or untyped data-set in this case?


General

Audio_Codec_List
Audio_Format_List
Audio_Format_WithHint_List
AudioCount
Codec
Codec_Extensions
Codec_String
CodecID
CodecID_Compatible
CodecID_String
CodecID_Url
CompleteName
Count
DataSize
Duration
Duration_String
Duration_String1
Duration_String2
Duration_String3
Duration_String4
Duration_String5
Encoded_Application
Encoded_Application_String
File_Created_Date
File_Created_Date_Local
File_Modified_Date
File_Modified_Date_Local
FileExtension
FileName
FileSize
FileSize_String
FileSize_String1
FileSize_String2
FileSize_String3
FileSize_String4
FolderName
FooterSize
Format
Format_Commercial
Format_Extensions
Format_Profile
Format_String
FrameCount
FrameRate
FrameRate_String
HeaderSize
InternetMediaType
IsStreamable
OverallBitRate
OverallBitRate_Mode
OverallBitRate_Mode_String
OverallBitRate_String
StreamCount
StreamKind
StreamKind_String
StreamKindID
StreamSize
StreamSize_Proportion
StreamSize_String
StreamSize_String1
StreamSize_String2
StreamSize_String3
StreamSize_String4
StreamSize_String5
Video_Codec_List

Video

Count
StreamCount
StreamKind
StreamKind_String
StreamKindID
StreamOrder
ID
ID_String
Format
Format_Info
Format_Url
Format_Commercial
Format_Profile
InternetMediaType
CodecID
CodecID_Info
CodecID_Url
Codec
Codec_String
Codec_CC
Codec_Profile
Duration
Duration_String
Duration_String1
Duration_String2
Duration_String3
Duration_String4
Duration_String5
BitRate
BitRate_String
Width
Width_String
Height
Height_String
Sampled_Width
Sampled_Height
PixelAspectRatio
DisplayAspectRatio
DisplayAspectRatio_String
Rotation
FrameRate_Mode
FrameRate_Mode_String
FrameRate
FrameRate_String
FrameRate_Original
FrameRate_Original_String
FrameRate_Original_Num
FrameRate_Original_Den
FrameCount
Resolution
Resolution_String
Colorimetry
ColorSpace
ChromaSubsampling
ChromaSubsampling_String
ChromaSubsampling_Position
BitDepth
BitDepth_String
Bits_Pixel_Frame_
StreamSize
StreamSize_String
StreamSize_String1
StreamSize_String2
StreamSize_String3
StreamSize_String4
StreamSize_String5
StreamSize_Proportion
Encoded_Library
Encoded_Library_String
Encoded_Library_Name
Encoded_Library_Version
colour_range
colour_description_present
colour_primaries
transfer_characteristics
matrix_coefficients
Mastering_display_color_primaries
Mastering_display_luminance"}

Audio

Count
StreamCount
StreamKind
StreamKind_String
StreamKindID
StreamOrder
ID
ID_String
Format
Format_Info
Format_Commercial
Format_Profile
CodecID
Codec
Codec_String
Codec_Family
Codec_CC
Duration
Duration_String
Duration_String1
Duration_String2
Duration_String3
Duration_String4
Duration_String5
BitRate_Mode
BitRate_Mode_String
BitRate
BitRate_String
Channel_s_
Channel_s__String
Channel_s__Original
Channel_s__Original_String
ChannelPositions
ChannelPositions_String2
ChannelLayout
SamplesPerFrame
SamplingRate
SamplingRate_String
SamplingCount
FrameRate
FrameRate_String
FrameCount
Compression_Mode
Compression_Mode_String
StreamSize
StreamSize_String
StreamSize_String1
StreamSize_String2
StreamSize_String3
StreamSize_String4
StreamSize_String5
StreamSize_Proportion
Default
Default_String
AlternateGroup
AlternateGroup_String

[LoRd_MuldeR]

I would prefer typed, for the same reasons that MSDN explains:
Typed access is not only easier to read, but also fully supported by IntelliSense in the Visual Studio Code Editor. In addition to being easier to work with, the syntax for the typed dataset provides type checking at compile time, greatly reducing the possibility of errors in assigning values to dataset members. If you change the name of a column in your DataSet class and then compile your application, you receive a build error. By double-clicking the build error in the Task List, you can go directly to the line or lines of code that reference the old column name. Access to tables and columns in a typed dataset is also slightly faster at runtime because access is determined at compile time, not through collections at runtime.

As far as I understand, your data structure has a fixed layout that is known at compile-time, so no need for using an un-typed one:
Even though typed datasets have many advantages, an untyped dataset is useful in a variety of circumstances. The most obvious scenario is when no schema is available for the dataset. This might occur, for example, if your application is interacting with a component that returns a dataset, but you do not know in advance what its structure is. Similarly, there are times when you are working with data that does not have a static, predictable structure. In that case, it is impractical to use a typed dataset, because you would have to regenerate the typed dataset class with each change in the data structure.

[stax76]

Thanks, I'll try typed though it brings me to a new question if any data-sets are helpful for my app because DataGridView also works with plain (observable) object collections.