Compression/Decompression using C#(Only using C# APIs. no third party)
-
we have implemented the Compression/Decompression in C# using J# APIs. This J# supported in .Net 2.0 but MS have removed the support for J# in .Net4.0. we are migrating to .Net 4.0 and need to rewrite J# implementation in C# as J# is no longer supported. We tried using GZipSteam/ZipPackage but that do not provide the backward compatiblity i.e, we cannot use J# compressed file for decompressing. Also multiple file compression using GZipSteam is complex. Is there any other solution to do compression/decompression in C# itself.(We do not want to use third party library). Is is possible to write compression/decompression algorithm in C#? Any suggessions are welcome.
-
we have implemented the Compression/Decompression in C# using J# APIs. This J# supported in .Net 2.0 but MS have removed the support for J# in .Net4.0. we are migrating to .Net 4.0 and need to rewrite J# implementation in C# as J# is no longer supported. We tried using GZipSteam/ZipPackage but that do not provide the backward compatiblity i.e, we cannot use J# compressed file for decompressing. Also multiple file compression using GZipSteam is complex. Is there any other solution to do compression/decompression in C# itself.(We do not want to use third party library). Is is possible to write compression/decompression algorithm in C#? Any suggessions are welcome.
Yes - if you know what the algorithm J# used is. (I don't) But an easier solution (if a bit clunky) would be to create a J# standalone module in .NET 2 and call into that from your C#. It means you have some code base you can't alter easily, but it would ensure that you could read your existing files. You could then automatically migrate them to Zip as you come across them, so eventually the J# stuff has disappeared.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Yes - if you know what the algorithm J# used is. (I don't) But an easier solution (if a bit clunky) would be to create a J# standalone module in .NET 2 and call into that from your C#. It means you have some code base you can't alter easily, but it would ensure that you could read your existing files. You could then automatically migrate them to Zip as you come across them, so eventually the J# stuff has disappeared.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
