News Visual Studio 2005 und .Net Framework 2 fertig

kaepten schrieb:
Kann denn eine Assembly einfach ins blaue hinein mit einem Framework genutzt/gestartet werden? Gibts da keine Versionsprüfung oder irgendsowas integriertes wo dann sagen würde : halt ich bin eine 1.1 Assembly Du hast 2.0 installiert es kann Probleme geben... Oder halt sowas in der Art :)

Doch gibt es, aber nur im umgekehrtem sinn, also wenn du eine 2.0 App in 1.1 starten willst kommt eine Meldung wie etwa "Die gestartete Software benötigt FW v2.0.xxxx und sie haben nur v1.1.xx instaliert. Instalieren sie bitte die neue Version und starten das Programm erneut.".

Diese Meldung kenne ich sehr gut, da ich wie gesagt schon mit beta-.net 2.0 programiert habe und das natürlich noch keiner dem ihc meine Prggs gegeben habe instaliert hatte...
 
Herrmann schrieb:
Probiert mal CD Burner XP. Es braucht eine 1.1 installation und läuft NICHT mit 2.0.:(
Aber sollte ich erst 1.1 installieren und dann v2.0?

Ich glaube kaum, dass es eine Rolle spielt.

PS: Encarta (link weiter) braucht scheinbar auch zwingend 1.1
 
Theoretisch ist es egal in welcher reinenfolge man die FW-Versionen installiert, paraktisch macht der Installer mgl. eine prüfung und lässt keine ältere installieren...
 
Hm, also ich als Hobby-Programmierer lasse von .net die Finger. Ich würde eher mal JAVA lernen, weil das in meinen Augen merh Sinn macht. Für Windows nehme ich lieber das gute alte C++ mit MFC und/oder Windows API, das ist weiter verbreitet und da kümmert sich keiner mehr drum, ob es jetzt installiert ist oder net, weil es keiner sieht :)
Und dank Microsoft's Entwicklungsumgebung (VS2003) kann ich den C++ Code auch noch mit Inline-Assembly (MMX z.B.) beschleunigen. Was will man mehr?


Ich hatte mir mal die Express-Beta von Visual C++ 2005 runtergeladen, und musste feststellen, dass da nur noch .net Anwendugnen mti geschrieben werden können. Ist das in der final auch so, oder kommt es da auf die Edition drauf an?
 
ich hab mich vor einer weile auch mal mit dem framework beschäftigt, also ich finde es einfach sehr gelungen. es bietet doch schon sehr sehr viele funktionen die man sonst mühevoll selber coden musste. werde mir mal die neue version ansehn und sehn was an neuen stuff dazu gekommen ist :)
 
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.
 
@Toengel
ja, die Frage ob es ein VS .NET 2005 geben wird war ernst gemeint. So wie ich das sehe gabs ja VS 2003 und VS .NET 2003, warum soll sich das ändern?
Ich hab nur mal bissel rumgesurft, selbst programmiert hab ich mit VS oder .NET noch nie (wie man vielleicht auch an meinen Äußerungen merkt *g*).

@UserNeo
Dass Eclipse nix mit .NET zu tun hat ist mir klar, Eclipse sollte ein Beispiel für die eklig träge GUI der Java-Programme sein.
 
seesharp schrieb:
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.

Das ist absoluter SCHWACHSINN was du da schreibst. DAS ist einer der größten Vorteile von .net: Mann kann alles in allem laden.
Du kannst eine 1.1er Bibliothek PROBLEMLOS in einer 2.0er Anwendung laden. Benutzt sie Funktionen welche in 2.0 anders sind muss nur das alte FW auch installiert sein. Ich mache das regelmäßig, das ich "alte" dll's lade.
In .net kannst du sogar unmanaged C++-Bibliotheken o.ä. importieren und damit arbeiten. Diese wird dann einfach in einen .net-Container gepackt und man kann damit Arbeiten wie wenn es eine .net-Assembly wäre.
In VS .net kann man sogar jede COM-Bibliothek welche am Rechner regestriert ist automatisch einkapseln und einbinden lassen. So kann man z.B. in seiner .net Anwendung ohne irgendwas den WMP oder IE einbinden und in seinem Programm laufen lassen.

Und wenn du im neuen VS "alten Code" lädst wird dieser automatisch in 2.0-konformen Code konvertiert.
 
Zuletzt bearbeitet:
Ui wie ich grad sehe is der neue SQL-Server auch in der MSDN verfügbar. Da wird in der Nacht aber mein Modem rauchen, VS 2005 hat viele gute Neuerungen wie ich finde :)

Edit:
Kagge mal wieder nur die englische erhältlich. Bin gespannt wie lange die wieder brauchen, bis die deutsche kommt...
 
Zuletzt bearbeitet:
@CaptainIglo: Bitte Vorsicht mit Formulierungen wie SCHWACHSINN. Natürlich kann ich alte Bibliotheken verwenden, nur darf ich AFAIK keine neuen Konstrukte verwenden. Sprich: Wenn mein Schnittstellenpartner Generics verwendet, kann ich mit altem Code diese Klassen bzw. Instanzen nicht mehr verwenden, ohne zumindest meine Sourcen neu übersetzen zu müssen.
 
Ich finde es seltsam das MS seit ein zwei Tagen auf der Update-Seite ein Service-Pack für Framework 1.1 anbietet, aber gleichzeitig 2.0 released. Wozu also dieses SP1 noch?
 
Aha?!? Dann frag ich mich warum es vor zwei Tagen, als ich Windows komplett neu aufgesetzt hatte, als Updates nicht angeboten wurde, aber heute schon?
 
Zuletzt bearbeitet:
Naja auf der Downloadseite von MS war das Update auf jeden Fall schon wirklich lange zu finden. Wer sich Visual Studio .NET 2003 (nicht 2002) installiert hat, dem wurde vor der Installation auch das Update installiert, wenns noch nicht installiert war (bei den notwendigen Komponenten)....

Ich warte erstma auf ne deutsche Version...was ich bisher vom VS 2005 gesehn hab (Beta) hat mich schon überzeugt. Sind viele gute Verbesserungen dabei...
 
Jo ich weiss jetzt auch warum. Da Framework eigentlich kein "Wichtiges Update" ist, hat er das auch nicht angezeigt. Ich vermute, das beim heutigen Abrufen der Updates der Installer Framework auf meinem Rechner gefunden hat und dann erst das "wichtige Update" SP1 angezeigt hat.
Blöd von dem Installer bzw. dessen Programmierer, das es nicht gleich mit angezeigt wird, wenn man Framework neu installiert, bzw. es nicht gleich integriert wurde. Naja MS eben :)
 
@CaptainIglo: Hab gerade das "problemlose Mischen" verschiedener dll-Versionen gerade ausprobiert und: Es ist schlimmer, als ich dachte. Blankes Entsetzen!
Dazu mein ganz simples Beispiel:
Mein Programm verwendet die Klasse MyLibraryClass der Bibliothek SomeLibrary (über somelib.dll-dynamisch gebunden). Habe folgenden Code in ein .exe kompiliert (mit 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():
}
}
}

Beim Ausführen von test.exe wird somelib.dll brav hinzugebunden. Die (erwartete) Ausgabe "0". Sehr schön.
Jetzt beschliesse ich, der Hersteller der Bibliothek, Framework 2.0 und damit sich's auch lohnt Generics zu verwenden. Normalerweise ja nichts ungewöhnliches, oder?
Also 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 die meinen: Na eh logisch. Unter Java geht GENAU das und in DIESER FORM. P.S.: .net mag einige andere Vorteile haben, aber das ist echt schwach.
 
Zurück
Oben