.NET Framework 2.0 Final-Version (englisch)

Software Das .NET Framework wurde von Microsoft mit dem Zweck entwickelt, die Programmierung von Applikationen für Windows zu vereinfachen und zu beschleunigen. Mit .NET stehen dem Programmierer neue Funktionen und Werkzeuge zur Verfügung. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
x64 verstehe ich ja, aber was bedeutet IA64 ??
 
@Cracker: Intel Itanium 64 Bit Struktur... (Serverprozessor)
 
@Cracker: Das ist der 64-Bit-Befehlssatz der Itanium-Prozessoren.
 
@Cracker: Itanium 64-Bit  Ooops, dreifach hält besser!
 
^^ lool, wie geil, alle 3 zur gleichen Zeit gepostet :D
 
Itanium (IA64)
64-Bit-Prozessor-Baureihe von Intel, gemeinsam mit Hewlett-Packard als Nachfolger für deren PA-RISC und die von Compaq (und von diesen von DEC) übernommene Alpha-Architektur entwickelt. 2001 nach sieben Jahren Entwicklungszeit nach mehrern Verzögerungen in Form des Merced-Kerns mit 800 MHz Taktfrequenz vorgestellt, später abgelöst von McKinley (Itanium 2) und Madison und mit der Variante Deerfield (für maximal Dual-Systeme) ergänzt. Die Itanium-Linie ist für große Multiprozessor-Server gedacht und führt 32-Bit-x86-Code nur langsam aus.

 
Na wenigsten ausführlich__wenn schon Letzter!!
 
Das Setup ist aber nicht in Englisch sondern in Deutsch.
 
@Kingkaktus: Liegt bestimmt am deutschen Installer.
 
@Kingkaktus: liegts auch
 
Ich hab das auf den Titel bezogen "(englisch)"
wenn der Installer ML ist dann kann man es ja in den Titel schreiben.

 
@Kingkaktus: Die eigentlichen .NET Framework 2.0 Komponeten sind aber eben nur in Englisch, daher ist der Titel schon korrekt.
 
@Kingkaktus: Der Installer ist ein globales Objekt in deinem OS und dieses .NET-Paket nutzt ihn nur. Deshalb hat diese News eigentlich nichts mit dem (deutschen) Installer an sich zu tun.
 
@blue32: So ganz stimmt das in diesem Fall auch nicht. Wenn du die dotnetfx.exe entpackst wirst du sehen das sie eine länderspezifische DLL und EULA für den Setup enthalten (aber nur für den Setup).
 
Tja, jetzt kann man wohl erstmal warten, bis alle Programme richtig darauf laufen. Hab es gerade mal installiert und dann World Wind gestartet (einziges bei mir derzeit installiertes Programm, von dem ich weiß, dass es .NET benutzt). Ergebnis: Programm läuft zwar, ich kann aber mit dem Mausrad nicht mehr zoomen.
 
@Aldaris: Ich habe .net 1.1 und die 2.0 gleichzeitig installiert, da geht eigentlich alles...
 
@Aldaris: Ich würde nicht so vorschnell urteilen das dies an der .NET Framework Version 2.0 liegt, auszuschliessen ist es aber natürlich auch nicht.
 
@swissboy: Lies mein Posting nochmal, denk einen Moment drüber nach und Du wirst vielleicht feststellen, dass ich das auch gar nicht geurteilt habe. :-) Edit: @imagodespira: Danke für den Tipp, ich wusste nicht, dass das geht. Hab .NET 1.1 deinstalliert vor der Installation von 2.0. Jetzt funktioniert auch das scrollen in World Wind wieder.
 
Also die ganze Installationsgeschichte läuft in deutsch ab. Auch des Eulazeugs und so (Steht auch im Pfad beim Ausführen Culture: Neutral)
 
@nokiaexperte: Ja, aber eben nur nur der Setup, die eigentlichen .NET Framework 2.0 Komponeten sind aber eben trotzdem nur in Englisch. Das ist aber nicht weiter schlimm.
 
Wie ist das jetzt? Beinhaltet das 2.0 auch das 1.1 oder nicht? Kann es einfach drüberinstalliert werden, oder muss das alte 1.1 vorher deinstalliert werden??
 
@bachmaniac: Sowohl darüberinstalliern wie auch die Version 1.1 zuerst deinstallieren sollte problemlos möglich sein. Die Version 2.0 beinhaltet auch die notwendigen Komponenten der Version 1.0 und 1.1.
 
@bachmaniac:

einfach nebeinbei installieren! Da wird nichts drüerinstalliert sondern beide Versionen lauen nebeneinander und ein Entwickler hat auch die Möglichkeit bei mehreren .Net Framework Versionen auf einen Zielrechner auszuwählen, welche nun wirklich benutzt wird. V1.1 Programme laufen auch auf Version 2.0, denke nicht das es da große Einschränkungen gibt.
 
Hm, wieso ist die IA64 gleich doppelt so gross wie die x86? Ist ja lustig.
 
@Muvon53: 2 x 32 = 64 :-)  Im Ernst: Eine mögliche Erklärung wäre das die Komponenten doppelt installiert werden. Einmal 32-Bit für 32-Bit-Anwendungen und einmal 64-Bit für echte 64-Bit-Anwendungen (ist aber nur eine Vermutung).
 
@swissboy: Nein, daran liegt es nicht. .NET ist an sich schon von der Rechnerarchitektur unabhängig, da muss man nichts doppelt installieren. @Muvon53: Stichwort "RISC": IA64 ist eine RISC-Architektur. "RISC" steht für "Reduced Instruction Set Computing", d.h. der Prozessor hat einen sehr kompakten oder "reduzierten", hoch optimierten Befehlssatz. Das Ergebnis ist eine höhere Performance um den Preis wesentlich größerer ausführbarer Dateien, weil man wegen des kleinen Befehlssatzes einfach mehr Platz braucht, um dieselbe Software unterzubringen. Dieses Phänomen ist von anderen RISC-Architekturen wie etwa SPARC bekannt, allerdings dürften die meisten Leser hier eher wenig mit SPARC zu tun haben. Manchmal entsteht sogar der Eindruck, Software für RISC-Architekturen sei "überfettet". Das stimmt allerdings überhaupt nicht, es ist genau dieselbe Software, der Größenunterschied hat technische Gründe und ist für RISC-Architekturen sogar ein Vorteil.
 
@installer: Meines Wissens werden die Assemblies auf 64Bit-Systemen sehr wohl einmal als 32Bit-Version und einmal als 64Bit-Version installiert.
 
also ich arbeite schon seit ein paar monaten mit 2.0 (beta) und ich muss sagen wirklich sehr gut was MS da hingelegt hat. nur bei den generics haben sie vielleicht ein bisschen übertrieben, aber ansonsten erste sahne.
 
@telefonzelle:
Inwiefern übertrieben? Generics sind doch echt ne schöne Sache. Merke gerade wie sehr die einen eigentlichen fehlen. Muss momentan ein Prjekt mit Framework 1.1 machen und die ganze Umwandlungen sind echt nervig.
 
@snowwolf3000: jaja schon, aber hast du schon mal gesehn was man mit den generics aufführen kann ? das schießt weit über das hinaus was die templates in c++ können. war net notwendig sowas einzubaun (dadurch geht eine der grundprinzipien von c$ verloren - einfachheit), aber is ja geschmackssache ...
 
@telefonzelle: Was können denn Generics was Templates nicht können? Bin selber C$ Entwickler und verstehe nicht was du mit übertrieben meinst, nenn am besten mal nen Beispiel.
 
1. Generics sind das rein objektorientierte Äquivalent von Templates. 2. Generics machen die Sprache einfacher, da man Typensicherheit nicht mehr durch Typprüfung und dynamische Casts durchsetzen muss. Außerdem kann man damit Klassen typsicher mehrfach mit verschiedenen Typen verwenden. Darum gehören generics ja in jede moderne Sprache.
 
funktioniert diese version eigentlich ohne den neuen installer ? die beta hat immer nach nem neueren intaller geschriehen
 
@maxfragg: Ich weiss nicht, aber was hast du denn gegen die aktuelle Version 3.1 des Windows Installers? Dann installierst du den halt erst mal schnell.
 
War zu Anfang vom .net-Framework und C$ ziemlich begeistert, weil das ganze wirklich aus einem Guss und sehr flexibel war. Jetzt hab ich mir die Änderungen des .net 2.0 Frameworks angesehen und bin schwer enttäuscht.
Microsoft hat anscheinend aus den Fehlern, die man schon bei VB gemacht hat nicht gelernt, denn für .net 1.1 compilierter Code ist binär nicht aufwärtskompatibel.
Das heisst z.B., ich kann eine neue Version einer Bibliothek für mein Produkt nicht verwenden, weil der Hersteller der Bibliothek ab nun die neuen Generics benutzt.
Microsoft ist anscheinend noch nicht klar, dass niemand "mal eben" sein gesamtes Projekt neu compilieren, testen, debuggen, produzieren und ausliefern wird, nur weil man in einer Komponente neue Features verwenden möchte.
Das heisst im Endeffekt nichts Anderes, als das der gesamte für 1.1 erstellte Code nun für 2.0 komplett neu aufbereitet oder gar neu geschrieben werden muss. Ich denke, dass wird nicht nur mich, sondern auch viele andere Softwareentwickler in Zukunft abschrecken .net zu verwenden.
Im Übrigen: Java 5 hat zwar bei neuen Features Kompromisse eingehen müssen, dafür ist die Binärkompatibilität voll gegeben. Es geht also.
 
@AgentSmith: man muss auch hin und wieder abstriche machen wenn man nach vorne gehen möchte
 
@Kalimann: Extremer Vergleich: Was würdest du sagen, wenn du deine bestehenden Dokumente in der kommenden Microsoft Office-Version nicht mehr öffnen könntest? Eben :-)
Uraltlasten über Bord zu werfen fände ich ja noch ok, aber das nicht einmal die Kompatibilität zur Vorversion gegeben ist, ist Wahnsinn. Und genau das Kreide ich MS hier an.
Ich denke, dass das schlicht verantwortungslos ist. In funktionierendem Code stecken hohe Investitionen (Architektur, Design, Implementierung, Test, Wartung). Dann muss ich alles neu überarbeiten, weil ich bei einer Klasse (von möglicherweise 10000en) einen Versionshub machen möchte? Schöner Schaden.
Und: Bei Java geht's ja auch.
 
@All: Nur um es gleich klarzustellen, diese Kompatibliäts-Einschränkungen betreffen "nur" die Entwickler bzw. Programmierer, NICHT die Anwender von Software die für .NET Framework 1.0 und 1.1 geschrieben wurde. Die Version 2.0 beinhaltet auch die notwendigen Komponenten der Version 1.0 und 1.1.
 
@swissboy: Hast Recht, swissboy. Mein Statement ist natürlich rein aus Entwicklersicht. Bestehende Applikationen funktionieren auch mit 2.0. Danke für die Klarstellung.
 
@AgentSmith: also im RC1 von sv 2005 konnte ich problemfrei projekte aus vs 2003 öffnen und diese auch bearbeiten, verändern, hinzufügen usw... natürlich musste auch einiges verändert werden. das einzige was leider nicht geht sind ebend neue eigenschaften aus 05 in 03 projekte zu integrieren. aber die weiterentwicklung des 03 projektes in 05 wahr mit den gleichen möglichkeiten wie in 03 möglich. also weis ich nicht wo dein problem liegt. BIsher gab es immer leichte Probleme mit einem Projeklt aus dem vorgänger VS.
 
@Kalimann: Es geht mir nicht darum, dass alte Projekte nicht mehr bearbeitbar sind. Mir geht es darum, dass ich alte und neue Binaries (übersetzte Teile) AFAIK nicht mischen kann.
 
@AgentSmith: Du musst ja alte und neue Binaries nicht mischen, das ist das tolle am Framework. Verschiende Versionen einer Assembly existieren friedlich nebeneinander, Schluss mit der DLL-Hölle, bei der ein Programm eine DLL-Datei durch eine neue ersetzt, die zum anderen Programm allerdings inkompatibel ist...
 
Hab die Kompatibilität der versch. Frameworks miteinander gerade ausprobiert und empfinde nur noch eins: blankes Entsetzen.
Simpelstes Beispiel: Mein Programm verwendet die Klasse MyLibraryClass der Bibliothek SomeLibrary (über DLL-dynamisch gebunden). Habe folgenden Code in ein .exe kompiliert (Framework 1.1).

using System:
using SomeLibrary:

class MyClass
{
static void Main() {
Console.WriteLine(MyLibraryClass.test(new Int32())):
}
}

Hier die Definition der Klasse MyLibraryClass. Das ganze als .dll compiliert (Framework 1.1):

namespace SomeLibrary
{
using System:

public class MyLibraryClass {
static public String test(object o) {
return o.ToString():
}
}
}

Bei Ausführen von test.exe wird somelib.dll brav hinzugebunden. Die (erwartete) Ausgabe "0". Sehr schön.

Jetzt die Klasse MyLibraryClass auf Generics angepasst und mit Framework 2.0 neu kompiliert:

namespace SomeLibrary
{
using System:

public class MyLibraryClass {
static public String test(T o) {
return o.ToString():
}
}
}

Alte Version der somelib.dll durch neue Version ersetzt. Wohlgemerkt, beide Runtimes vorhanden! test.exe ausgeführt => Ergebnis: "Die Anwendung hat einen Ausnahmefehler verursacht, der nicht verarbeitet werden konnte."
Sprich: Beim tollen Framework kann man GAR NICHTS miteinander mischen. Wer auf 2.0 umsteigen will, darf das nur nach dem Motto: Entweder ganz oder gar nicht. Einzelne Komponenten auf neue Features umzustellen funktioniert nämlich gar nicht.
Und für alle Kritiker: Unter Java geht GENAU das SO und exakt in DIESER FORM. P.S.: .net mag einige andere Vorteile haben, aber das ist echt schwach.
 
@AgentSmith: ms hat von anfang an gesagt das sich viel an v2 ändern wird und viel älteres nciht mehr funzen wird. also ziehe niocht son getuhe auf
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles