Der Algorithmus, den der DeflateStream verwendet hat sich geändert. Vermutlich mit Framework 4.7.2, genau weiß ich es nicht. Meine Anwendung ist für 4.6.1 gebaut, trotzdem hat sich das Verhalten geändert.
Mein Problem: Ich speichere Daten komprimiert und nicht doppelt. Die Id für einen Stream habe ich aus dem Hash des komprimierten Streams gebildet. Damit kann ich nach Duplikaten suchen. Solange der Algorithmus sich nicht geändert hat, hat das funktioniert.
Jetzt nicht mehr. Wird jetzt ein Dokument komprimiert, dass ich früher schonmal hatte, sieht der komprimierte Stream anders aus und hat einen anderen hash. Ich finde also das Duplikat nicht mehr.

Die saubere Lösung für mich wäre, den Hash des Originals zu verwenden. Nun habe ich aber schon Millionen alte Datensätze, für die ein Update nicht mal eben schnell gemacht ist.

Daher würde ich gerne als Zwischenlösung auf den alten Algorithmus zurückgreifen.

Weiß jemand, ob und wie das geht?

Ich habe folgenden Schalter gefunden, der leider nicht hilft:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

DoNotUseNativeZipLibraryForCompression gibt's leider nicht.

Siehe Decompression changes in DeflateStream

Zitat

Support for decompression by using Windows APIs is enabled by default for applications that target .NET Framework 4.7.2. Applications that target earlier versions of .NET Framework but are running under .NET Framework 4.7.2 can opt into this behavior by adding the following AppContext switch to the application configuration file:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

Würde mich wundern, wenn es das wirklich nicht geben würde. Wäre ein Bug, der sicherlich jemanden vorher aufgefallen wäre.
Sicher, dass das Setting zieht?

Wie schon gesagt, hilft das nicht.
Der Schalter ist scheinbar für's dekomprimieren, nicht für's komprimieren.

Sowohl true als auch false liefern das selbe Ergebnis und das ist ein anderes, als vor einiger Zeit.
Kann leider nicht genau sagen, seit wann.

Ah; sorum geht der Hase.
Wenn Du auf den alten Kompressionsalgorithmus keinen Zugriff mehr hast / haben kannst; dann musst im Zweifel Deinen Datenbestand migrieren.

Da .NET Framework 4.7.2 allgemein große Breaking Changes beim Thema Crypo hat, wirst Du da evtl. langfristig nicht drum herum kommen.
Wir speichern bei solchen Hashes auch immer den Identifier des Algorithmus ab; so kann man das bei den meisten Anwendungen zur Laufzeit migrieren (zB. User Passwords stehts mit dem neuesten, sichersten Algorithmus speichern).

Das ich migrieren muss ist mir klar.
Werde ich tun.
Ich hatte nur gehofft, einen sehr schnelle fix zu finden, denn die Migration wird ein wenig dauern und bis dahin funktioniert die Duplikatserkennung nicht mehr richtig. Das Produkt ist komplex und wir releasen nicht alle paar Tage. Einen Hotfix könnte ich schnell nachschieben, die Migration nicht.

Bist Du gezwungen, auf .NET Framework 4.7.2 zu gehen?
Wenn nicht kannst Du ja problemlos eine Soft Migration durchführen:
- Weiterhin auf die alten Hashes gehen
- Neue Hashes generieren
- Wenn alle Hashes durch sind, dann auf 4.7.2 gehen

Das Produkt haben viele Kunden auf eigenen Servern. Das Kind ist schon in den Brunnen gefallen. :-(
Kann denen nicht sagen, sie sollen Windows- oder Frameworkupdates zurücknehmen. Das Problem ist gestern aufgefallen. Wie lange es schon da ist, also was genau der Auslöser ist, kann ich nicht nachvollziehen. Ich vermute, dass es Framework 4.7.2 ist, muss aber nicht sein. Ich weiß nur, dass jetzt das compress andere Ergebnisse liefert, als vor einiger Zeit. Könnte den Zeitpunkt zwar theoretisch eingrenzen, aber das ist leider auch nicht trivial. Da arbeite ich lieber weiter an der richtigen Lösung.

Hatte halt die Hoffnung, dass es da einen einfachen Schalter gibt.

In den Changelogs von 4.7.2 wird ja auf die Breaking Changes der Compression hingewiesen.
Wird also schon die Ursache sein.