.NET Framework 3.5 vs. 4.0 szenvedés

Próbáltam installálni három programot is, amik mind azt írták, hogy .NET Framework 3.5 kell nekik. Nem gondoltam, hogy ezt szó szerint gondolják. Felraktam ezért a .NET Framework 4.0-t, gondolván hogy az a legfrissebb verzió, akkor biztos azt kell használni.

De nem. Valamiért vannak programok, hogy csakis a 3.5-ös .NET-tel hajlandóak működni. De emellett vannak olyanok is, amiknek meg a 4.0-s verzió kell. Tehát ilyenkor egyszerre kell felrakni a 3.5-öt és a 4.0-t is. De a .NET 4.0 miért nem egyenértékű a .NET 3.5-tel?

Nem az lenne a logikus, hogyha egy programnak a .NET Framework 3.5 kell, akkor a 4.0-n is vígan elfut? Illetve nem az lenne a logikus, hogy azonos programból nem telepítunk egymás mellé több verziót, hanem mindig a legfrissebbet csak?

Csak a szokásos M$ gányolás.

Hozzászólások

Melyik az a három program és melyik Windows? Lehet, hogy a fejlesztő fixre állította a verziót. De egyébként AFAIK fel kellett volna kerüljön a gépre a .NET 4-el a régebbi cuccok is, vagy legalábbis, ami kell a visszafelé kompatibilitáshoz.

"Csak a szokásos M$ gányolás."

Backward compatibility... Jó dolog tud az lenni.

"Illetve nem az lenne a logikus, hogy azonos programból nem telepítunk egymás mellé több verziót, hanem mindig a legfrissebbet csak?"

.NET az nem kifejezetten egy program, hanem egy platform/runtime/lib/framework csomag. És Linuxon pont ebből van egy csomószor probléma, hogy adott program valamiért X, másik program ugyanabból a libből Y verziót követel meg, de az idióta ostoba csomagkezelési mánia miatt richtig szopattyú van ilyen esetben. Főleg, ha a lib fejlesztője a turbóbazári modell szerint random verziónál töri az API-t.

----------------
Lvl86 Troll

Linux-on is lehetne ám úgy gányolni mint win-en, hogy szállítja minden app az összes lib-jét - és így tízszer meglenne ugyanaz a lib szétszórva különböző mappákban. Mint biztos tudod, a Linux disztrók ezért a release-re összeillesztik a program verziókat és pl. libjpeg-ből is 1 van telepítve normál esetben. Azért ég és föld a 2 megoldás között, szerintem pont ezt nem érdemes fírtatni.

Az, hogy te mit gányolsz vagy épp fejlesztés miatt szükséged van 3 külön verzióra ugyanabból a lib-ből, nem érdekes. A szállított alap rendszerben használhatja a user az elérhető program verziókat. Nincs rákényszerítve hogy operációs rendszert fejlesszen.

Azert a minden melle odacsomagolunk mindent es a csak egy darab van mindenbol, aztan ha broken, akkor broken megoldas kozott szerintem eleg jo kompromisszum a .NET es az OSX-fele framework elkepzeles. A Linuxnak is jot tenne ilyen, nagy mertekben novelne a kompatibilitast a disztrok es verziok kozt.

Mondjuk azért tegyük már hozzá azt is, hogy (.NET viszonylatban) nagyon sok olyan dolgot elintéz a .NET FW, amihez neked külső libre kellene nyúlnod.

Tény, hogy vannak átfedések, de tekintve egy átlagos alkalmazásméretet engem marhára nem tud érdekelni az a +1-2 gb-nyi lemezhely, cserébe, hogy működik. Eddig is ott volt a WinSxS, két azonos verzió nem töltődött be 2x, aztán a W8-ban lesz deduplikáció FS-re is.

----------------
Lvl86 Troll

Nekem azt mondták, hogy a .BET 3.5 tartalmazza a régebbi .NET-et is azaz, 3.x 2.x stb. Míg a 4.0 már nem, abban csak a 4-es van, így kellhez hozzá a 3.5 is.

Fedora 16, Thinkpad x61s

Mert ujrairtak az egesz runtime rendszert, ide ertve a jit-et, es a base class library-t is. A verziozasra azt a megoldast valasztottak, hogy parhuzamosan futtathatod a kulonbozo verziokat, nem pedig a tobbe-kevesbe mukodo deprecation. Ahol inkabb binarisokat szallitanak, elobbi megoldas egy fokkal jobb...

https://en.wikipedia.org/wiki/.NET_Framework

Java eseten igy nez ki a verziozas:

"The Java 2 SDK, v1.4 is upwards binary-compatible with Java 2 SDK, v1.3 except for the incompatibilities listed below. This means that, except for the noted incompatibilities, class files built with version 1.3 compilers will run correctly in the Java 2 SDK, v1.4.

In general, the policy is that

Maintenance releases (for example 1.2.1, 1.2.2) within a family (1.2.x) will maintain both upward and downward binary-compatibility with each other.

Functionality releases (for example 1.3, 1.4) within a family (1.x) will maintain upward but not necessarily downward binary-compatibility with each other.

Some early bytecode obfuscators produced class files that violated the class file format as given in the virtual machine specification. Such improperly formatted class files will not run on the Java 2 SDK's virtual machine, though some of them may have run on earlier versions of the virtual machine. To remedy this problem, regenerate the class files with a newer obfuscator that produces properly formatted class files. "

http://java.sun.com/javase/compatibility_j2se1.4.html

Nem egy javas programot láttam már, ami az egyszerűség kedvéért valami outdated jre-t szállított magában, elkerülve az inkompatibilitásból eredő problémákat. Nincs nagy különbség igazából, sőt, javaból is lehet több jre-t telepíteni egymás mellé. Sajnos ezek a frameworkök túl nagyra híznának, ha mindig meglenne a visszafele kompatibilitás, ezért inkább ezt a megkerülő megoldást választják, és reménykednek abban, hogy idővel a régi verziók kikopnak a használatból.

A gond akkor lenne, ha nem tudnál egymás mellé telepíteni több verziót, és az új nem lenne visszafele kompatibilis a régivel.

Nem gányolás, csak fingod nincs róla. Te elképzelsz valamit (bár totál alaptalanul), aztán ha nem úgy van, akkor az faszság. Mert Firefox 4 + Firefox 5 = Firefox 9, ugye? Meg .Net 4 = .Net 3.5 + 0.5? Vagy mégis hogy gondoltad? E-gyen-ér-té-kű? Már miért lenne az? Akkor talán ugyanazt a verziószámot kapná, ha ugyanaz, nem gondolod?

Amúgy meg, mégis mi olyan baromi nagy szenvedés abban, hogy felteszed mindkettőt? Kezdjük ott, hogy winupdate kapásból lerántja őket. Ja, és a kompatibilitás megvan, de forráskód szinten. Az illető program készítőinek annyi lenne a dolga, hogy átállítják a target framework-öt 4.0-ra, nyomnak egy F5-ot, és ennyi. Ha ennyire nem képesek, az nem az MS hibája.

[ NeoCalc - Earnings Calculator for NeoBux ]