Új, egységes .NET platformot jelentett be a Microsoft
2016-09-28T09:32:40+02:00
2016-10-05T07:45:34+02:00
2022-07-21T18:56:43+02:00
  • Nagyon nem erről van szó.

    Itt nem vetélkednek egymással a fork-ok, hanem mindegyik más célra szolgál, a "szabvány" pedig egy interface-t jelent, és annak kötelező implementációját, nem egy újabb fork-ot.
    Mutasd a teljes hozzászólást!
  • Természetesen nem erről van szó: xkcd: Standards
    Mutasd a teljes hozzászólást!
  • Teljesen logikus, amit írsz, leszámítva azt, hogy nem értem, miért adná fel a Microsoft a többszáz milliós példányban futó saját platformját, rajta a megszámlálhatatlan, kész megoldással. Nem is fogja.

    A Windows jelentősége persze egyre inkább visszaszorul, de eltűnni nem fog, így az eredeti .NET sem. Viszont lesz egy egységes alap, ahol a kód teljesen megosztható (desktop, tablet, mobil, web, felhő), ráadásul nyílt.

    Már csak egy C# -> JS / XAML -> HTML fordító hiányzik, sajnos addig marad a kétévente teljesen lecserélődő trendy web UI-technológia követése.

    Szerk.: ez utóbbi egyébként nem sci-fi, független projectek itt és itt, és a hír blogbejegyzéséhez tartozó kommentekben a Microsoft sem zárkózott el ettől, csupán prioritásokról beszélnek.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy így lesz, de eredetileg nem így indult. Egy kis háttértörténet, akit érdekel, mert tényleg nem egyszerű követni az eseményeket.

    A "Core" név eredetileg arra utalt, hogy egy nem 100% kompatibilis subset-et hoztak létre, mivel nem volt cél a teljes kompatibilitás. Csak az alapok kerülnek bele, platformfüggetlenül, BCL nélkül, a "mag".

    Aztán jöttek újabb üzleti és technológiai döntések, megvették a Xamarint (Mono alapú), kitalálták, hogy a .NET Core legyen az UWP alapja is stb.

    Aztán rájöttek, hogy a .NET Core nem teljesen kompatibilis volta visszaveti a terjedést is, mert így nem túl egyszerű kódot portolni rá, és az alap rendszer teljesen fapados. Még egy email-t sem tudsz küldeni, csak külső csomaggal vagy amivel én küzdök: mai napig nincs MIT licenszes natív PDF-készítő. Márpedig ha mindent 0-ról kell újraírni, akkor nem sokan döntenek majd mellette, pedig hegyekben állnak a kész, kiforrott lib-ek.

    Úgyhogy a hírben szereplő .NET Standard 2.0 bejelentése (mert nem az egységes .NET platform itt az újdonság, hanem a kiterjesztése) pont ezt kívánja orvosolni: utólag kompatibilissé teszik az összes fork-ot, beleértve a BCL-t is, és a platformfüggő részeket is külön csomagokban elérhetővé teszik, ezáltal megkönnyítve a kódmegosztást. Itt tartunk most.
    Mutasd a teljes hozzászólást!
  • A cél szerintem hosszú távon a .NET a java alternatívájaként tud csak fennmaradni. A windows mint olyan előbb-utóbb pusztulni fog, ahogy én látom a MS sem nagyon ragaszkodik már hozzá. Ahhoz viszont, hogy a .NET java-gyilkos lehessen az kell, hogy platformfüggetlen legyen. A java pont azért tudott elterjedni, mert az aki java programot fejleszt tudja, hogy történjen bármi, az ő programját nem kell újraírni ha eltűnik egy platform. Az üzleti szoftverek világában ez elég lényeges kérdés: gondolj csak bele a y2k problémába anno. Kiderült, hogy akkoriban még vígan futkároztak az akkor 30 éves, egykor COBOL-ban írt szoftverek. És ebből él talán még ma is az IBM mainframe üzletága: nagyon-nagyon fontos volt, hogy az N+1-es verziójú szerveren (ott azért hardver-szoftver egy kézben van) fussanak az N-10-re írt szoftverek is.

    Ettől a legacy .NET framework is marad a WPF-fel, a régi ASP.NET-tel, meg a windows.forms-szal, amíg még lesz windows. És persze egyre fontosabb szerepet kap a mobil is.
    Mutasd a teljes hozzászólást!
  • Szerintem meg az a céljuk, hogy most fork-ként egymás mellett futtassák, de a jövőben a .Net Core legyen a belső magja (hihi core) a teljes keretrendszernek is.

    A monolitikus hagyományos keretrendszert áttolják hagymahéj szisztémába.
    Persze egy csak logikai levezetés.
    Mutasd a teljes hozzászólást!
  • Feltehetően nem a legjobb magyar fordítást használtam a "fork" kifejezésre, de a lényegen nem változtat: nem arról van szó, hogy lassan kivezetik a hagyományos .NET framework-öt, hogy teljesen átvegye a helyét a .NET Core.

    Ez csak egy fork, aminek kompatibilisnek kell lennie a nagy egésszel.

    Amikor elkezdték készíteni, ez még nem volt cél, ezért lehetett új project típust (JSON) használni. A célok sajnos menet közben változtak, ennek eredménye, hogy meg kell azt szüntetni, mert ez a kisebbik rossz döntés.
    Mutasd a teljes hozzászólást!
  • A .NET Core nem egy .NET platform oldalhajtás. Lásd a linket. A .NET család 3 tagja közül szerintem is a .NET Core lesz a felkapottabb a nem Enterprise szintű alkalmazásoknál lazán.
    Mutasd a teljes hozzászólást!
  • A .NET Core nem a .NET jövője, komolyan nem értem, honnan veszed ezt. Egy független oldalhajtás, más célokkal, más tulajdonságokkal, viszont cél, hogy kompatibilis legyen a teljes .NET keretrendszerrel a könnyebb kódmegosztás miatt.

    Légyszi olvasd már a .NET blogot: hibás tényekből kiindulva teljesen felesleges következtetéseket levonni.
    Mutasd a teljes hozzászólást!
  • Ennél erősebb érvek szóltak anno a VB6 és a win32 mellett. A .NET Core pedig a .NET jövője.
    Mutasd a teljes hozzászólást!
  • Nem teljesen világos, mire gondolsz.

    Hogy ne a levegőbe beszéljünk, idézem akkor:

    We had two choices. One was to move all .NET projects to use project.json. This would require us doing tooling work that touches all of the project types in Visual Studio, Xamarin and our partners like Unity. We would have to expand project.json to support all the build scenarios required by each of these project types and provide a migration story.

    Another choice was to build bridges so an .xproj project can reference a .csproj project and a .csproj project can reference an .xproj project in Visual Studio and Xamarin Studio. The bridge has challenges as well, for example when a customer creates a project they would now have to choose an .xproj or a .csproj, which just adds more choices and complexity.

    After looking at our choices, it was apparent that it would be easier to move .NET Core projects to .csproj/MSBuild so all .NET projects use the same tooling and build system.

    Tehát, amikor a JSON project típus készült, egyszerűen mások voltak a célok. Teljesen logikus és érthető döntés, hogy nem dobnak ki mindent csak emiatt, hanem az új project típust igazítják a meglévő rendszerhez.

    Viszont jó hír, hogy folytatódik a bejegyzés:

    But at the same time we don’t plan to give up the benefits of project.json. We plan to enhance .csproj to support the missing functionality:

    • No listing of files in the project system
    • CLI tool for doing any operations on the project file, for most scenarios you would not edit the file
    • Build packages directly from the project
    • Multi-targeting

    Összegezve: lehet ezen a döntésen siránkozni és visszalépésnek tekinteni, de a .NET Core csak egy apró része az egésznek, ezért teljesen logikus ez a változás, a többi lehetőség választása összességében rosszabb eredményt hozott volna.
    Mutasd a teljes hozzászólást!
  • Ha eddig is így gondolkodtak volna, akkor még mindig a jó öreg win32 API-nál és a VB6-nál tartanánk.
    Mutasd a teljes hozzászólást!
  • Ja! A Google-t sem kell félteni. Imádják kivágni az előző verziókat, a publikus API-kat is. Másnap reggel arra ébredsz, hogy nem jönnek a videók a YouTube Data API-ból mert úgy döntöttek, hogy új verziót kell használni. Igaz megvan verziózva minden (/v1/, /v2/, /v3/ ...), de attól még megszüntetik. Aztán csörögnek nekem, hogy nem működik semmi, nem jönnek a videók
    Mutasd a teljes hozzászólást!
  • Akkor láttad a problémát, láttad az alternatívákat.

    Tök logikus a lépés. Nem cseréljük le a kabátot egy új csili-vili gomb miatt.
    Mutasd a teljes hozzászólást!
  • Az okokat már előzőleg is olvastam. De akkor is erős visszalépésnek tartom a dolgot.
    Mutasd a teljes hozzászólást!
  • azt olvastam hogy hosszú távon dobni akarják a jó kis json alapú project fájlt és visszatérni a jó öreg msbuild-hez

    Már linkeltem neked a cikket az okokról, de úgy tűnik, feleslegesen, így nem ismétlem meg.

    Ja, és rövidtávon, nem hosszútávon (valószínűleg a VS "15"-ben jön ki ez a változtatás is).
    Mutasd a teljes hozzászólást!
  • Miért, Pl. az AngularJS-sel Pl. nem ugyanez van ? Pedig ez még csak a második verzió.
    Ami engem _sokkal_ jobban bosszant, hogy azt olvastam hogy hosszú távon dobni akarják a jó kis json alapú project fájlt és visszatérni a jó öreg msbuild-hez.
    Mutasd a teljes hozzászólást!
  • Amikorra a WP kijött, már el sem lett volna szabad kezdeni.
    Mutasd a teljes hozzászólást!
  • Csak ha kicsit előrelátóbbak, akkor pl. a winphone piac is másként alakul.
    Az elkészült .Net alkalmazások hatalmas tömege egyszerűen áttehető lenne (maximum egy gui cserével) egy winphone-ra, mert az alap .net osztályok azonosak lettek volna a win-es alkalmazással, így az alkalmazás kétharmada, három negyede már kész lett volna. Ahogy a silverlightnak sem kellett volna kihalnia... stb.
    Egy cégvezetésnek kicsit távlatosabban kellene terveznie 
    De ahogy látom ez sok más iparágban sem megy jobban nekik... a napi problémákba beragadva lehetetlen a jövőt tervezni, a víziókat megvalósítani.
    Mutasd a teljes hozzászólást!
  • Pedig az ASP.NET Cores perf teszteket látva majdnem kedvem támadt újra egy kicsit dotnetelni. De elment. Szokásos, 10 éve ismétlődő MS stratégia:

    10 cool ötlet (igaz, lopott, de cool) 20 b+, Bill, így nem jó, megcsináljuk jobban 30 gyermekbetegségek, szívás, de látod a fényt a végén 40 3.0 (vagy a 3. kiadás mindegy milyen néven) 50 fény 60 max még 1-2 verzió 70 GOTO 20
    Mutasd a teljes hozzászólást!
  • Ezért is kezdte el ~3 éve a forrásainak megnyitását, népszerű technológiák integrálását saját változat készítése helyett és több platform támogatását fejlesztői eszközökkel.
    Mutasd a teljes hozzászólást!
  • Ja. Ilyesmi előbb-utóbb mindenhol bekövetkezik, ahol feladják a monolitikusság elvét - vagy ahol eleve el sem kezdték. Van a PHPx és az alap libek, és vannak a tetején a különféle frameworkok amiknek az X verziója a PHP Y verzióját támogatja. Ehhez képest a .NET még mindig fantasztikusan egységes.
    Mutasd a teljes hozzászólást!
  • Őszintén, átfutod a cikket a tervekről, érted is?

    1.1, 1.6, vNext, 4.6.1, 4.6.2, Xamarin, Core, WTF? Nekem az a tábla tetszik, ami ez alatt van: "The table listed earlier shows which versions of .NET Framework supports which version of .NET Standard". Tehát, hogy a .NET 4.6.2 az .NET Standard 1.5 lesz, a vNext 1.6, de a .NET 4.6.1 meg majd 1.4 meg 2.0 lesz
    egyszerre. Teccikérteni?
    Mutasd a teljes hozzászólást!
  • Na igen, régen a windows volt a lényeg, és ennek akart egy normális, magas szintű API-t csinálni a MS. Most viszont már nem a windowson van a hangsúly, hanem a felhőn. A felhőben viszont már lehet akár linux is, ha az ügyfél ilyet akar.
    Mutasd a teljes hozzászólást!
  • Mert régen csak az ő platformjuk létezett, így nem volt igény.
    Mutasd a teljes hozzászólást!
  • Azért ha három platformra is kell is fejleszteni egy teljes lefedéshez, de legalább az alapkönyvtárak, legyenek közösek.
    Inkább az a kérdés, miért nem valamikor a 2 de legkésőbb a 4 első verziónál jutott eszükbe a nagy szalmakazal (minden mindennel összelinkelve) felszámolása egy rétegelt struktura kialakítása, ahol egyszerű kicsi mag, arra szélesebb, komolyabb hardveren (mindenféle oprendszeren) is futó környezet és csak a tetejére egy win teljes infrastruktúrán teljes környezet.

    Ahogy utólag jól látszik, többször próbáltak már jó irányba indulni, de a hatalmas windows túlsúly mindig félrehúzta.

    Az utóbbi időkben látszó irány azért tetszik (nyilt forrás, réteges, kevéssé összedrótozott környezet és most összekötni a három önállóságra indult platformot)
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd