Laden...

.NET Standard Output wird mit .NET Framework ausgelesen und bringt anderes Ergebnis

Erstellt von trashkid2000 vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.483 Views
T
trashkid2000 Themenstarter:in
156 Beiträge seit 2010
vor 4 Jahren
.NET Standard Output wird mit .NET Framework ausgelesen und bringt anderes Ergebnis

Hi,

ich kämpfe nun schon eine ganze Weile, und es bringt mich bald um den Verstand....
Wir haben eine API, die unter .NET Core 2.1 läuft, und unter anderem Daten verschlüsselt....
Das macht die Bibliothek 'System.Security.Cryptography.Pkcs'. Diese erstellt eine verschlüsselte Nachricht für ein oder mehrere Empfänger. Per nuget eingebunden.
Soweit alles gut, läuft 🙂

Auf Clientside empfangen wir die Nachrichten und müssen sie auch wieder entschlüsseln.
Und genau hier gehen die Probleme los...

Der Client ist gegen .NET Framework 4.7 programmiert. Die oben genannte Bibliothek ist in der gleichen Version per nuget eingebunden, aber es verhält sich anders...
So können die verschlüsselten Werte auch wieder entschlüsselt werden, aber der Wert, der da raus fällt, passt nur so halb.

Es sind immer irgendwelche Sonderzeichen am Anfang drin...
Das scheint irgendwie ein Codierungs-Problem zu sein. Aber wir benutzen überall UTF8.
Gegen netStandard 2.0 können die Werte ganz normal entschlüsselt werden.

Ich sehe auch, dass das Package je nach Framework unterschiedliche Assemblies einbindet, vielleicht liegt darin das Problem??

Ist da was bekannt?
Für Antworten bin ich sehr dankbar,
lG Marko

16.807 Beiträge seit 2008
vor 4 Jahren

So wie Du es beschreibst, kann es nicht sein: das .NET Ökosystem funktioniert so gar nicht.

.NET Standard ist nur ein Vertrag - keine Runtime.
.NET Standard ist aus C# sicht als Interface zu sehen, während .NET Framework, Mono, Xamarin, .NET Core.. als konkrete Implementierung zu sehen sind.

Gegen netStandard 2.0 können die Werte ganz normal entschlüsselt werden.

Das kann daher nicht sein, denn .NET Standard ist niemals zur Laufzeit bekannt.

Der Sinn ist, dass der Code, der gegen .NET Standard läuft, auch in allen Runtimes genau so läuft, die die jeweilige .NET Standard Version unterstützen.
Als ob man eben ein Interface deklariert und alle implementierenden Klassen sich genau so verhalten, wie es das Interface als Vertrag vorgibt.

Die Frage ist hier also eher, ob sich jede Runtime identisch verhält.
Die Runtimes sind aber auch von Außenfaktoren (zB. Windows Settings) abhängig - das gilt es auch zu überprüfen.

Konkretes Beispiel?
[Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden

T
trashkid2000 Themenstarter:in
156 Beiträge seit 2010
vor 4 Jahren

Hi Abt,

.NET Standard ist nur ein Vertrag - keine Runtime.
.NET Standard ist aus C# sicht als Interface zu sehen, während .NET Framework, Mono, Xamarin, .NET Core.. als konkrete Implementierung zu sehen sind.

Soweit dachte ich auch. Wie gesagt, die API auf dem Server ist gege .NET CORE 2.x entwickelt.

Die Frage ist hier also eher, ob sich jede Runtime identisch verhält.

Konkretes Beispiel?

>

Das habe ich mir gestern gebaut, in dem ich eine dumme Consolen-App geschrieben habe, die unter .NET Framework 4.6 läuft, und einmal ein Binary vom Server mit Framework-Bordmitteln entschlüsselt. Da kommt das Besagte bei raus.
Zusätzlich inkludiert das Testprojekt noch eine netStandard-Bibliothek in 2.0, wo genau das Gleiche getan wird.
Und da passt es dann 🤔
Wenn ich heute mal dazu komme, werde ich es hier mal posten.
Danke erstmal, Marko

16.807 Beiträge seit 2008
vor 4 Jahren

Zusätzlich inkludiert das Testprojekt noch eine netStandard-Bibliothek in 2.0, wo genau das Gleiche getan wird.
Und da passt es dann 👶

In der Formulierung kann es nicht sein; Deine .NET Standard Bibliothek kann nicht ausgeführt werden.
Daher kannst Du hier direkt draus kein Resultat bekommen.

Du kannst die Bibliothek höchstens irgendwo referenzieren und dann in .NET Core, .NET Framework... ausführen.
Daher in der Form der Erklärung eigentlich nur zwei potentielle Ursachen:

  • Unterschiedene der referenzierten Pakete
  • Runtime Unterschiede

Verhält sich denn Deine Bibliothek identisch, wenn Du es von .NET Framework und .NET Core ausführen lässt?
Kannst einfach nen Unit Test schreiben; der braucht ja eine Runtime.

T
trashkid2000 Themenstarter:in
156 Beiträge seit 2010
vor 4 Jahren

Hi Abt 🙂

Du kannst die Bibliothek höchstens irgendwo referenzieren und dann in .NET Core, .NET Framework... ausführen.
Daher in der Form der Erklärung eigentlich nur zwei potentielle Ursachen:

  • Unterschiedene der referenzierten Pakete

Ja, die NETStandard-Bibliothek wird in ein .NET Framework-Projekt refrenziert.

Und genau, der Unterschied liegt in dem von dem Package referenzierten Pakete:

Unter .NET Framework 4.6 sind es diese:
System.Security.Cryptography.Encoding (≥ 4.3.0)
System.Security.Cryptography.X509Certificates (≥ 4.3.0)

Unter .NETStandard 2.0 diese:
System.Buffers (≥ 4.4.0)
System.Security.Cryptography.Cng (≥ 4.4.0)
System.Memory (≥ 4.5.1)

Ab .NET Framework 4.6.1 gibt es keine Abhängigkeiten mehr...

Ich habe es zum Laufen gebracht, indem nun die Assembly, die für NETStandard 2.0 gedacht ist, sowie alle da abhängigen Assemblies, geladen werden.

Aber so ganz verstehen tue ich es trotzdem nicht 🤔
lG, Marko

//EDIT: Ich werde mal ein konkretes Beispiel nachstellen

4.931 Beiträge seit 2008
vor 4 Jahren

Hallo,

du hast den Beitrag von Abt wohl immer noch nicht ganz verstanden. Es gibt keine .NET Standard Runtime Library, sondern nur konkrete Implementierungen davon.
Auch .NET Framework Libraries sind .NET Standard Implementierungen (nur eben z.B. .NET Framework 4.6 entspricht .NET Standard 1.3), s.a. .NET Standard bzw. interaktiv .NET Standard Versions.
Und .NET Framework 4.6.1 ist eine Besonderheit, denn es entspricht .NET Standard 1.4 - 2.0 (s. Fußnote ² im oberen ersten Link).