Megszűnik a külön .NET Framework és a .NET Core - ezek után csak egy .NET lesz

Megszűnik a külön .NET Framework és a .NET Core - ezek után csak egy .NET lesz
2019-05-07T08:22:04+02:00
2019-05-13T20:56:37+02:00
2022-10-18T08:50:46+02:00
  • azt nem mondtam hogy van logikus oka is...
    Mutasd a teljes hozzászólást!
  • mármint 14 éves középiskolásként van egy ügyfeled, aki megkötötte hogy WebForms-ban írd meg amit kért?
    Mutasd a teljes hozzászólást!
  • Elvileg a mono-ban van valami webforms támogatás, de tényleg elég trágya az egész webformsosdi. Eredetileg arra volt kitalálva, hogy az fejlesztők majd új csinálnak vele formokat mint a winforms-ban. Csak egyrészt a wpf-fel ez a húzd és ejtsd dolog már a desktop oldalról is kikopott, másrészt a web formsban soha nem is működött normálisan. A helló világnál csak egy picit is komplexebb appoknál már szétszáll a designer, ráadásul az összes data kontroll benne van a form designjában, ami akkor is szétcs***szné a dolgot, ha amúgy ez a húzogatósdi egyébként működne.
    Cserébe viszont egy jó nagy rakás szemét utazik ide-oda a böngésző és a szerver között (a viewstate). Ráadásul, az egész cucc tesztelhetetlen. Az egész kb. olyan korszerû mint a gőzautó.
    Mutasd a teljes hozzászólást!
  • nekem akkor is kell, mert vmi idióta vonzalmat érzek iránta.
    úgyhogy ennyi, meg fogom csinálni a WebForms Core-t.
    Lehet kész lesz mire a sima webforms támogatása véget ér

    ui.: valszeg senkinek nem fog kelleni, és olyan bugos lesz mint eleinte a mono volt,
    de nem baj.
    Mutasd a teljes hozzászólást!
  • Miért olyan fontos a WebForms?

    Támogatott marad, attól nem kell félni, még ha nem is (továbbra sem) fejlesztik tovább. Ha van egy stabil cuccod, ami erre épül, az szépen elketyeg legalább még egy évtizedig, de valószínűleg tovább is (referenciának: a .NET 3.5 legalább 2028-ig támogatott marad, pedig 2007-ben adták ki).

    Ha ennél hosszabb távon van rá szükség (vagy már beleütközött az ember a korlátaiba, amiért szabadulna tőle), szépen apránként célszerű migrálni modernebb környezetbe, leválasztva kisebb service-eket a monolitikus egészből. Az egész folyamat felhasználók számára transzparens módon le tud zajlani, leállás nélkül.

    (A WCF más tészta, a .NET blogon is sokan említik, hogy ez elég nagy érvágás: hosszú évek alatt kifejlesztett stabil rendszerek alapulnak rá. Remélhetőleg a Microsoft a véleményükre hallgatva ezt még átgondolja.)
    Mutasd a teljes hozzászólást!
  • Ez leginkáb szerzői jogi kérdés, pl. sw esetén a 70 év anakronisztikus és vicces :)

    Technologiailag és üzletileg 10-20 év elég lehetne, ami ennyi év alatt nem térül meg az bóvli, illetve minek védeni, ha elavult már.

    Sőt, valami olyat is lehetne tenni a szabályozásba, hogyha nem megszerezhető legális forrásból (természetesen korrekt áron) és nem tud adni mellé támogatást, akkor elveszti a szerzői jogot.

    A társadalom kettős érdekét tudomásul kellene venni, a fejlesztőnek "monopol/szabadalom/kizárólagosság" jogot a befektetés megtérülésére, de a felhasználóknak is kell legyen joga a használatban.
    [Mindent, ami monopolium az államnak kell korlátoznia, extra szabályokat alkotni, akár ármeghatározás vagy forgalmi kötelezettség szinten... ez más gazdasági területeken annyira egyértelmű, mint a gyártói felelősség is :) ]
    Mutasd a teljes hozzászólást!
  • De akkor csak úgy forrás nélkül engedhetnék a világnak hogy használják.
    A DOS-t is lehet használni, csak nem érdemes. A VB6-ot is lehet használni, csak
    szintúgy nem érdemes.
    Mutasd a teljes hozzászólást!
  • De, költséget okoz nekik, mert kiadás előtt ellenőrizni kell, hogy nincs -e benne valami olyan kód, ami vagy más szellemi tulajdona, és aminek beépítésére csak ők kaptak licencet, vagy nem -e sért olyan szabadalmat, aminek használatára nekik ugyan van joguk (mert saját vagy mert licencelték máshonnan), de külső személyeknek nincs.

    Ha van ilyen kód vagy megoldás, akkor pedig csak akkor lehetne kiadni az adott szoftvert, ha az érintett részeket helyettesítenék másik,  szabadon terjeszthető kóddal, vagy eltávolítanák a funkcionalitást. Ami ha meg is oldható, akkor is munka és költség - de legtöbbször ráadásul nem is oldható meg, illetve értelmét veszti általa az egész közzététel.

    Szóval ez nagyon nem annyi, hogy feltöltjük a már amúgy is meglévő forrást a GitHub-ra egy license.txt fájl társaságában, és annyi. Ráadásul sokszor régi szoftvereknek a forrása sincs meg vagy csak részben van meg.
    Mutasd a teljes hozzászólást!
  • Igen, de egyesek örülnének neki, nekik néhány kattintás,
    üzletileg meg nem okoz nekik kárt. Végül is, a DOS forrását is kiadták,
    pedig nem hinném, hogy az a jövő...
    Mutasd a teljes hozzászólást!
  • Meg ha már itt tartunk, jöhetne az IE, az EdgeHTML, az aero, és még sok más régi,
    már nem használt ms cucc kódja.

    Minek? Úgy értem a Microsoft szempontjából. A Microsoft nem azért adta ki a .NET, a Számológép, a kriptográfiai könyvtára, a PowerShell, a Windows Terminal, stb. forrását, mert azok a múlt és már nem használja senki őket, hanem mert azok a jövő, és mert azt szeretné, hogy még az eddigieknél is többen használják őket.
    Mutasd a teljes hozzászólást!
  • Én csak a szegény WebForms-ot sajnálom, nagyon fog hiányozni.
    Mondjuk én a ms helyében kiadnám a legacy api-k forrását, sokat úgyse vesztenek vele,
    de én mondjuk örülnék a WebForms, a wcf és társai kódjának.

    Meg ha már itt tartunk, jöhetne az IE, az EdgeHTML, az aero, és még sok más régi,
    már nem használt ms cucc kódja.
    Mutasd a teljes hozzászólást!
  • Ha ez egy támogatott platform, akkor igen.
    Mutasd a teljes hozzászólást!
  • Értem, köszi a válaszodat.
    Akkor pl. az is megvalósítható, hogy pl. nekem van egy Synology NAS-om armv8 (64 bit) CPU-val, s arra .Net Core-ban fejlesztek, s a deploy során erre a CPU-ra kérek teljes deploy-t, s az alkalmazásom menni fog, persze a hardver és az OS képességeinek a keretei között.
    Mutasd a teljes hozzászólást!
  • Semmit nem kell: lehetőség.

    1. Képes vagy a runtime-ot hozzácsomagolni az alkalmazáshoz, azzal a megkötéssel, hogy ilyenkor a pontos platformot meg kell jelölnöd (x86, x64, ARM), illetve természetesen nagyobb lesz a csomag is. Utána copy/paste-tel lehet deployolni, bármelyik könyvtárba, önállóan fog futni. Így lehet egy .NET Core app-ot pl. Raspberry PI-n egyszerűen futtatni.

    Ennek a segítségével el lehet szakadni az OS-ra telepített runtime-tól, többféle .NET Core verzió lehet egy gépen.

    2. Hagyományos módon (OS-ra telepített runtime-nál) meg a bináris JIT segítségével futtatáskor a megfelelő architektúrára fordul, ahogy a normál .NET-nél. Egy bináris - többféle architektúra.

    Azt használod, ami a célodnak jobban megfelel.
    Mutasd a teljes hozzászólást!
  • (Hacsak nem kizárólag az Apple könyvtáraival megy az együttműködés - ami azért nem valószínű -, akkor "könyvtárakkal" szerintem jobb lenne)
    Mutasd a teljes hozzászólást!
  • Engem a deployment része érdekel, tudtommal van 2 féle:
    - .Net Core nélkül, ekkor azonban az OS-re telepítve kell lennie a .Net Core runtime-nak
    - Integrálva a .Net Core

    Kérdés:
    Ez azonban egyben lehetőség és kényelmetlenség is, ugyanis ez azt jelenti, hogy mind a kettő formában ki kell adni az általam fejlesztett alkalamzást?
    Mutasd a teljes hozzászólást!
  • Viszont a 12es verziotol a sima SE is kereskedelmi licensszel rendelkezik es nem csak a tamogatasert kell perkalni.

    Ezt rosszul tudod, illetve ez így nem pontos. Az Oracle által támogatott Oracle JDK kerül pénzbe, ahogy az egyéb támogatott JDK-k eddig is pénzbe kerültek.

    Az OpenJDK is az Oracle terméke, az Oracle a fő fejlesztője, és az Oracle JDK szinte teljesen megegyezik az OpenJDK-val forrás szinten. 

    Nem is beszelve Ali es Amazon kihivojarol az OpenJDK-val szemben.

    Ez mind újracsomagolt OpenJDK. 

    En az utobbi hetekben kezdtem foglalkozni kenyszerbol a Javaval. Velemenyem szerint az irany pont ellentetes mint a .NET teren latunk.

    Nem tudom pontosan mire gondolsz, de az Oracle most tol szinte mindent open-sourceba. Supportért meg gondolom Microsoftnak is kell fizetni.
    Mutasd a teljes hozzászólást!
  • Tudtommal Java 11-ig befezoleg magan celra ingyen hasznalhato a Java. Viszont a 12es verziotol a sima SE is kereskedelmi licensszel rendelkezik es nem csak a tamogatasert kell perkalni.

    Ezt kivitelezhetik mert a JVM melle melle nem kell SE mert maga az alkalmazas tartalmaz minden fuggoseget. Ergo a fejleszto cegen cehajthato a love (akar per user akar per cpu)

    Es az OpenJDK... Kivancsi Kivancsi a kozosseg erejere es hogy nem nyillik e az ollo az Oracle es OpenJDK funkcionalitasa kozott...

    Nem is beszelve Ali es Amazon kihivojarol az OpenJDK-val szemben.

    En az utobbi hetekben kezdtem foglalkozni kenyszerbol a Javaval. Velemenyem szerint az irany pont ellentetes mint a .NET teren latunk.
    Mutasd a teljes hozzászólást!
  • Nem gondolom, hogy ez arról szólna, hogy meglévő alkalmazásokat futtassanak mostantól .NET platformon, sokkal inkább meglévő Java libek .NET-es alkalmazásban történő felhasználásának van értelme. Ezt is írta egyik kolléga:

    Not being able to call java libraries is one of the biggest problems with .NET. There are a ton of java libraries that don’t have good .NET equivalents. https://news.ycombinator.com/item?id=19842199

    Biztos lesz arra is példa, hogy áttesznek valamit .NET-re, de ezt aligha vállalnák egy komplexebb rendszer esetében. Egy működő alkalmazást egy stabil, kipróbált JVM-ről áttenni egy totál idegen platformra az alkalmazás teljes újratesztelésével, a teljes tooling leváltásával, support kollégák leváltásával/újra tanításával elég irreálisnak tűnik. Értelmes céget aligha navigálnak bele egy ilyen pénzügyi buktába.

    A Java license problémája meg eléggé túl van lihegve. A legtöbb cég, akinek kell fizetős support eddig is fizetett, őket nem érinti. Azokat érintheti leginkább, akik nem kívánnak valamiért együtt menni az OpenJDK verzióváltásaival, vagy lassabb ütemben, de nem kell nekik fizetős support. Azok meg választhatnak maguknak továbbra is akár ingyenes, vagy akár az Oracle-nél olcsóbb alternatívát. 

    Azt írták egyébként, hogy:

    We intend to take the Java interop that Mono already supports, improve it as needed, and make it available to other scenarios beyond just Android. https://news.ycombinator.com/item?id=19841431

    A mono féle megoldás ez: Java

    Kétirányú együttműködést terveznek tehát, nem csak .NET alkalmazásból lehet majd Java kódot hívni, hanem fordítva is.
    Mutasd a teljes hozzászólást!
  • Valószínűleg a terv egyébként is ez volt, csak nem mondhatták azt 2014-ben, hogy várjatok srácok, most mindent elkezdünk újraírni nulláról, majd 2020-ban jelentkezünk. Ezért jöttek ki a .Net Core 1.0-val, ami még tök buta volt, és folyamatosan adták hozzá az új feature-öket, optimalizációkat, .Net Framework API-kat.
    Így most a 3.0 eléri az APi paritást a .Net Frameworkkel, azaz ettől kezdve tényleg semmi értelme nem lesz .Net Frameworkkel új projekteket indítani.
    S így hogy mindenki szépen átszokik .Net Core-ra, jöhet végre az egységes, új komplett .Net, és szépen fokozatosan, immár fájdalom mentesen el lehet hagyni a régi széttöredezett platformokat.
    Mutasd a teljes hozzászólást!
  • A .NET Core-t 2014 körül kezdték el fejleszteni, Nadella CEO-vá kinevezése körüli időben és ez még így is 2020 végére készülhet csak el.
    Mutasd a teljes hozzászólást!
  • Hmmm... Érdekes. A Java összedrótozhatóság felettébb kellemetlen irányt vehet az Oracle számára. Java licencelési feltételeinek változása bizonyos körökben szerintem elég érzékeny lesz. Viszont megjelenik a .NET ami használni képes a már meglévő Java kódokat, ez nem kerüli ki az Oracle-t viszont megjelenhet egy réteg az alkalmazásokban ami már .NET alapon lesz. Ez pedig a későbbiekben áttolódhat teljesen a .NET felé, visszaszorítva a Java kódot. Idővel ebből az MS biztosan profitálni fog és az Oracle meg húzza a rövidebbet. MS profitábilis része úgy is a szolgáltatásokon van már (pl Azure) nem  Windowson.
    Szerintem ez egy ügyes húzás és felettébb hasznos döntés hosszútávra. Már csak a Javaról történő átszoktatást kell kieszközölniük valami módon és az felhő szolgáltatásain keresztül meg lecsapolni a hasznot.
    Mutasd a teljes hozzászólást!
  • És mindehhez mit szóltak az Apple meg a Google?
    Mutasd a teljes hozzászólást!
  • Évekkel ezelőtt már meg kellett volna ezt lépni!
    Mutasd a teljes hozzászólást!
  • Vééégre
    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