{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "Won't do",
    "ClosedDate": "2010-01-22T23:56:50.427-08:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "It is worth exploring, for several reasons. \nCurrently DotNetZip relies on a managed port of an older zlib, v1.1.4. \n- Zlib is continually being maintained, getting bugfixes, expansions to the library, and performance improvements (sometimes big ones).\n- because DotNetZip relies on a port of zlib, there is a not-insignificant maintenance cost to DotNetZip to stay current with ZLIB.  I have to do the port again. \n- the port of zlib used in DotNetZip is actually a port of a Java port.  So the problem is even worse that I described above.\n \nIt would be nice if improvements and fixes could come to DotNetZip \"for free\", or almost free.  Imagine just re-compiling the zlib sources (in C) and linking them with DotNetZip wrapper code and logic, into a single mixed-mode assembly.  An update of Zlib would imply a very small cost.  And, there might even be perf advantages to relying on native code to do the deflate. \n \nWith C++/CLI and the VC9 compiler, this is now theoretically possible. It would require some R&D and heavy testing.",
    "LastUpdatedDate": "2013-05-16T05:32:27.6-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2009-03-13T10:55:33.833-07:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Use a native-C++ version of ZLIB within DotNetZip (for performance)",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 2,
    "Id": 7272
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "I would strongly vote against any mixed-mode assembly. Please tell if you want to develop into that direction soon, because I'll drop DotNetZip and will switch back to SharpZipLib.",
      "PostedDate": "2009-03-18T08:20:50.49-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Foxfire, Really?  What's so wrong with a mixed-mode assembly?  ",
      "PostedDate": "2009-03-30T15:00:06.437-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2009-03-30T15:00:37.327-07:00",
      "Id": -2147483648
    },
    {
      "Message": "My class library that uses DotNetZip is also used under Mono on Linux, Mac and potentially other OSes. Mixed-mode assemblies won't work there. In fact afaik they won't even work on .Net compact framework.",
      "PostedDate": "2009-04-03T02:42:13.213-07:00",
      "Id": -2147483648
    },
    {
      "Message": "I would also strongly vote against switching to a C++ back-end, mainly because it's 100% safe against crashing.  However, if the actual compression code (inflate.cs and deflate.cs ?) would run significantly faster in C++, then I would have it available as an option.  (And maybe a couple helper routines.)  But the rest of the code is unlikely to have much impact on overall performance.  Also, if this library will be useful for Mono, Silverlight, or XNA applications, or ones targetd for the .Net Compact Framework, it MUST be able to run with 100% managed code.\r\n\r\nI would also recommend that the enumerations are renamed to .Net-friendly names and dump the java/zlib garbage that's in the library -- for example, for the CompressionMode enumerations, instead of \"LEVEL1_BEST_SPEED\", use \"Level1\" and \"BestSpeed\" and etc.",
      "PostedDate": "2009-05-25T12:56:22.37-07:00",
      "Id": -2147483648
    },
    {
      "Message": "I'd vote against mixed-mode as well.  \r\n\r\n1) Mixed-mode requires full trust\r\n2) Mixed-mode can't be ILMerged",
      "PostedDate": "2009-06-19T11:21:24.43-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2009-08-14T05:21:13.95-07:00",
      "Id": -2147483648
    },
    {
      "Message": "I haven't worked in C++ for a decade now, but can't you compile the C/C++ source into a pure managed DLL? This might solve the problems with the porting.\r\n\r\nHaving the best performance by using a mixed-mode assembly would also be nice sometimes, but only as an additional option. And I suppose it would also introduce some problems with moving to 64bit, a problem which does not exist when having a pure managed library.",
      "PostedDate": "2009-08-14T08:06:54.887-07:00",
      "Id": -2147483648
    },
    {
      "Message": "100% managed code is the best goal. Much easier to manage. A lot of problems and depencies come when mixing. Especially regarding signed dlls, 64 bit systems and permissions. So my vote is that we should not introduce or mix managed and unmanaged.",
      "PostedDate": "2009-08-23T12:21:58.967-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2010-01-22T23:55:58.03-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2010-01-22T23:56:50.427-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:44:25.34-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:32:27.6-07:00",
      "Id": -2147483648
    }
  ]
}