.NET-Code doch auslese-sicher?

Ist doch egal wofür es eigentlich gut war, mir gefällts wie´s ist.

@petaod zwei bits innerhalb eines bytes, z.b. für mirroring, was man für die FFT z.b. braucht
@wertherchen welche DLL Hölle?

jvbsl schrieb:

welche DLL Hölle?

Frag ich mich auch.

Dlls, sind doch mega praktisch. Man kann seinen Code viel besser kapseln und und und....

googlen ist heute schon nicht mehr drin? bitter
en.wikipedia.org/wiki/DLL_Hell
de.wikipedia.org/wiki/DLL-Konflikt

Danke fürs Googlen, war natürlich direkt ersichtlich, dass das nen Allgemeiner Begriff sein soll.
Außerdem scheint das meiste seit 1900 vorm Krieg behoben worden sein und der Rest liegt am Dev+com. Wie gut com ist wissen wir ja bereits alle. Also tut mir leid, aber ich hab diese Hölle noch nicht erlebt.

tolio schrieb:

googlen ist heute schon nicht mehr drin? bitter

DANKE!

Momentan weiß ich aber nicht was bitterer ist: das Unvermögen sich schlau zu machen oder ständig eine Technologie zu preisen, deren Ursprung man gar nicht versteht..

Markus Jacobs schrieb:

thefiloe schrieb:

Was soll das mit .NET Native zu tun haben?

Man kann keine Managed Assemblies in fremden Code injizieren, dass meinte ich damit.

thefiloe schrieb:

Zudem das wahrscheinlich eh nicht für Desktop-Apps raus kommt.

Wo haste das denn her?

Du kannst soar ne managed DLL in n nativen Prozess injecten musst halt vorher die CLR reinladen dann geht das.


Und die Tatsache das .net native sicher ware als managed .net is krampf.
Absolut sicher gibts sowieso nich.
Es ist aber schon möglich "relativ sichere Sicherheitssysteme" zu kreieren... Stichwort Dongle und Codevirtualization

Rikudo schrieb:

.net native

Paradox detected.
C++/CLI ist schlicht und weg CLI es gibt zwar von MS einen rein nativen Cpp Compiler, aber der hält sich nur halbwegs an die Standards.

@jvbsl
Wer redet denn hier von C++/Cli?

@nafets ich wüsste nicht was ".net native" sonst sein sollte?

.Net native, aufbauend auf dem Roslyn compiler projekt, compiliert z.B. C# quellcode direkt in maschinencode, nicht mehr IL. Wird aber derzeit nur für Store Apps verwendet, sodass diese bis zu 30% schneller arbeiten und glaub bis zu 50% schneller starten.

Deshalb war meine Aussage auch korrekt..