Custom file DeSerialization and file access

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I have to read files generated by 3rd party application, these files are in
a propriotary format ( not generated using the .NET framework ), I want to
implement a custom DeSerializer to read the data in the file, I wonder is it
possible to read files in this manner ( e.g. custom implementation of the
ISerializable interface )? is this right way to extract data from the file?
OR should I rather 'manually' use the FileStream to read the desiered chunks
of data?

Another Issue, is there a C# equivalent to the unmanaged CreateFileMapping,
MapViewOfFile ??? accessing files in this manner dramatically impove
performance as the kernel is resposible for loading the data from the disk (
and not the application ) so less context switch are done between the
application layer and the kernel...
 
Nadav,

While this certainly could be acheived using ISerializable, there is no
point in doing so. ISerializable's purpose is to implement custom
serialization - so that IFormatter (BinaryFormatter for example), can call
the proper constructor and the proper GetObjectData - in your case you are
probably better off implementing the "deserialization" to .NET via a non
ISerializable or Serializable mechanism.

Secondly,

Kernel32.Dll->CreateFileMapping and
Kernel32.Dll->MapViewOfFile ..

AFAIK donot have managed implementations.

But they can be easily used in C# like this --

[DllImport("kernel32.dll", SetLastError=true)]
static extern IntPtr CreateFileMapping(IntPtr hFile,
IntPtr lpFileMappingAttributes, PageProtection flProtect, uint
dwMaximumSizeHigh,
uint dwMaximumSizeLow, string lpName);

and

[DllImport("kernel32.dll")]
static extern IntPtr MapViewOfFile(IntPtr hFileMappingObject, uint
dwDesiredAccess, uint dwFileOffsetHigh, uint dwFileOffsetLow,
UIntPtr dwNumberOfBytesToMap);

TTFN :-)

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Sahil,

Thanks for you immediate responce, concerning the FileMapping issue, indeed
it is possible to use these APIs through DllImport BUT all access to the
mapped data would have to be done in an unsafe manner, therefor it is not
posibble to reffer to the mapped data directly as can be done in C++ ( by
pointers ), my guess is that usage of the file mapping API should be done
only in the unmanaged world....

Nadav.

Sahil Malik said:
Nadav,

While this certainly could be acheived using ISerializable, there is no
point in doing so. ISerializable's purpose is to implement custom
serialization - so that IFormatter (BinaryFormatter for example), can call
the proper constructor and the proper GetObjectData - in your case you are
probably better off implementing the "deserialization" to .NET via a non
ISerializable or Serializable mechanism.

Secondly,

Kernel32.Dll->CreateFileMapping and
Kernel32.Dll->MapViewOfFile ..

AFAIK donot have managed implementations.

But they can be easily used in C# like this --

[DllImport("kernel32.dll", SetLastError=true)]
static extern IntPtr CreateFileMapping(IntPtr hFile,
IntPtr lpFileMappingAttributes, PageProtection flProtect, uint
dwMaximumSizeHigh,
uint dwMaximumSizeLow, string lpName);

and

[DllImport("kernel32.dll")]
static extern IntPtr MapViewOfFile(IntPtr hFileMappingObject, uint
dwDesiredAccess, uint dwFileOffsetHigh, uint dwFileOffsetLow,
UIntPtr dwNumberOfBytesToMap);

TTFN :-)

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Nadav,

Good news. You can do pointer operations in C# using the unsafe keyword. I
am using Kernel32.dll->MoveMemory happily in a heavily used caching block I
wrote for a windows service that gets hit a few thousand times a second in
an enterprise block.

You have to compile this with the /unsafe option, but it works.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik


Nadav said:
Sahil,

Thanks for you immediate responce, concerning the FileMapping issue,
indeed
it is possible to use these APIs through DllImport BUT all access to the
mapped data would have to be done in an unsafe manner, therefor it is not
posibble to reffer to the mapped data directly as can be done in C++ ( by
pointers ), my guess is that usage of the file mapping API should be done
only in the unmanaged world....

Nadav.

Sahil Malik said:
Nadav,

While this certainly could be acheived using ISerializable, there is no
point in doing so. ISerializable's purpose is to implement custom
serialization - so that IFormatter (BinaryFormatter for example), can
call
the proper constructor and the proper GetObjectData - in your case you
are
probably better off implementing the "deserialization" to .NET via a non
ISerializable or Serializable mechanism.

Secondly,

Kernel32.Dll->CreateFileMapping and
Kernel32.Dll->MapViewOfFile ..

AFAIK donot have managed implementations.

But they can be easily used in C# like this --

[DllImport("kernel32.dll", SetLastError=true)]
static extern IntPtr CreateFileMapping(IntPtr hFile,
IntPtr lpFileMappingAttributes, PageProtection flProtect, uint
dwMaximumSizeHigh,
uint dwMaximumSizeLow, string lpName);

and

[DllImport("kernel32.dll")]
static extern IntPtr MapViewOfFile(IntPtr hFileMappingObject, uint
dwDesiredAccess, uint dwFileOffsetHigh, uint dwFileOffsetLow,
UIntPtr dwNumberOfBytesToMap);

TTFN :-)

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik


Nadav said:
Hi,

I have to read files generated by 3rd party application, these files
are
in
a propriotary format ( not generated using the .NET framework ), I want
to
implement a custom DeSerializer to read the data in the file, I wonder
is
it
possible to read files in this manner ( e.g. custom implementation of
the
ISerializable interface )? is this right way to extract data from the
file?
OR should I rather 'manually' use the FileStream to read the desiered
chunks
of data?

Another Issue, is there a C# equivalent to the unmanaged
CreateFileMapping,
??? accessing files in this manner dramatically impove
performance as the kernel is resposible for loading the data from the
disk
(
and not the application ) so less context switch are done between the
application layer and the kernel...
 
Back
Top