Megérkezett a WinForms támogatás a .NET Core-ba - és villámgyors lett
2018-09-13T13:35:20+02:00
2018-10-12T15:24:16+02:00
2022-07-18T23:01:27+02:00
  • El akarják engedni a sima .Net platformot és csak a Core-ra koncentrálni.

    Azt hiszem, ez a vélemény megdőlt.

    If you have existing .NET Framework applications, you should not feel pressured to move to .NET Core. Both .NET Framework and .NET Core will move forward, and both will be fully supported, .NET Framework will always be a part of Windows. But moving forward they will contain somewhat different features. Even inside of Microsoft we have many large product lines that are based on .NET Framework and will remain on .NET Framework.

    Érdemes a teljes bejegyzést végigolvasni a .NET jövőjéről.
    Mutasd a teljes hozzászólást!
  • Anno olyan követelmény volt, hogy egy datagridview-ban az A és az B oszlopokat írni kell tudni, és a C oszlopot checkelni, a D oszlop tartalma és a színe pedig az A, B, C értékétõl függõen változik. Ergo, ha A, B, C változik akkor D is, és a színe is. És nincs Ok gomb, ha a gridben változtattad A,B,C-t akkor D-nek is változnia kell. Na, ezt volt egy kicsit trükkös megoldani anno databindinggel.
    Mutasd a teljes hozzászólást!
  • Vagy csak egyszerűen a default on validation marad a típus. Ha egy formra ilyet teszel addig nem fogja visszaírni az értéket amíg nincs egy Ok gomb nyomás. Ha property changed a validáció működik rendesen. Mondjuk én is régebben használtam de erre emlékszem, hogy hülyén van megcsinálva, hogy mi a default binding mode.
    Mutasd a teljes hozzászólást!
  • Úgy 2010 táján játszottam ezzel utoljára, valami olyan baja volt, hogy a click után néha pont a checkbox állapotával ellentétes adat volt a bindelt táblában. Már nem emlékszem pontosan arra, hogy mi volt a megoldás de több eventet is rá kellett tenni a datagridviewra hogy mûködön. Azóta persze lehet hogy megoldották...
    Mutasd a teljes hozzászólást!
  • Nem véletlen, hogy a komponens gyártók még mindig fejlesztik a Winforms kontroljaikat és folyamatosan jönnek bele új featurék. Pl. a Devexpress megcsinálta a DirectX renderinget a Winformshoz. Kíváncsi leszek, hogy portolnak-e majd .net core-ra bár ahogy érzem muszáj lesz. A tradicionális framework napjai meg vannak számlálva.
    Mutasd a teljes hozzászólást!
  • Pl. ha azt akarod hogy egy gridben egy checkbox change hatására történjen valami.

    Simán működik bindinggal ott is. A winformsnak egész jó bindingja van (bár senki sem használja mert mindenki eventekkel baszakodik) ami hiányzik belőle a WPF-hez képest az a converterek illetve a komponensek közötti direkt binding.
    Mutasd a teljes hozzászólást!
  • mi lett a régi nickeddel?

    Egy ezer éves emailcímhez volt rendelve, aztán egyszer csak nem lehetett bejelentkezni vele.
    Mutasd a teljes hozzászólást!
  • Na, így már kezd hasonlítani egy vitára. A személyeskedéseket most is skippelem, hogy a lényegnél maradhassunk.

    Mert én eddig csak azt tapasztaltam, hogy a Winform maximálisan enged GÁNYOLNI.

    Ez így van. Gányolnak is benne rendesen, főleg azok a kezdők, akik bátran használnak valamit, ami érzésre könnyűnek tűnik. De erre valók a szigorú projekt konvenciók, a review-k, komolyabb esetben a refactoring task-force-ok, ha egy-egy alrendszerben elburjánzottak a szörnyűségek vagy új szabályt adtunk hozzá az automatikus kódanalizálóhoz, ami által kibukott egy-két csontváz.

    Így aztán teljesen mindegy, hogy a cégek rájöttek, hogy a winform még támogatva lesz, amikor a programjuk már csak egy kezelhetetlen bughalmaz marad

    Lásd fent, hogy kell ezt elkerülni. A legrondább kódokat amúgy tipikusan egyszemélyes "fejlesztőcsapatok" évek óta dédelgetett és toldozgatott magánprojektjeiben láttam. De ez többnyire technológiafüggetlen. WPF-ben legfeljebb azért látsz kevesebb ilyet, mert ritkán kezdik csak úgy, intuitív módon azt használni.

    Komplex rendszerek Ui rétegét írtam meg bennük, kb 1000x hatékonyabb és gyorsabb volt mint a Winforms-os elődje

    Nem kétlem, max a szorzót érzem költői túlzásnak. De nem pont ugyanarról beszélünk. Szerencsésebb esetben a komplex rendszerek nagy része nem a UI-ban van, és egy felület ritkán tartalmaz egyszerre több száz controlt egymásba ágyazva. Példának hozhatjuk magát a VisualStudiót - a rendszer igen komplex, de a UI főleg menükből, pár toolbarból, egy szép nagy kód editorból (ha épp az van nyitva) és az éppen megnyitott, valahova bedokkolt egyéb elemekből áll. Ez pár tucat control.

    Ezzel szemben egy olyasmi felület, ami pl. egy adóbevalláshoz hasonló adathalmaz összes lapját és rubrikáját külön controlokban tartalmazza, egyetlen window-ban, szépen tabokba vagy más hierarchiába rendezve, már durván képes túlterhelni a WPF-et. Nem azt mondom, hogy ez egy jó felület, csak hogy míg WinFormsban ez még kezelhető, bármilyen ronda is, WPF-ben már használhatatlan.

    Kis flash-szerű appokra -- olvasatom: nem értesz hozzá :)

    Akkor árnyalom az értő olvasat kedvéért: ha a feladat egy kis csilivili app, gondolkodás nélkül a WPF-et választom, ha egy sokkal komplexebb rendszer, akkor meg mérlegelek.

    Csak úgy pörög a CPU, zabálja az energiát. Egyszerűen nem tudok mit írni erre, ami ne lenne gúnyos

    A CPU is egy dolog, igen (elég összehasonlítani az első VS verziót, ami már WPF alapú volt az őt megelőzővel), és egy megint másik pl. a memory footprint, ami WPF-nél jóval nagyobb. Egy ipari automatizáció területen meglévő integrált portál esetén jutottunk arra, hogy képtelenség lenne áttérni WPF-re, akkora memória overhead-et jelentene, hogy azt a legtöbb ügyfél nem tartaná elfogadhatónak. Ezenkívül mint említettem, komoly memory leak problémákkal szembesültünk. Bár ezek legtöbbje interop eredetű volt, mélyen a WPF engine belsejében maradtak olyan fel nem szabadított referenciák, amiktől csak csúnya reflection kinullozások árán tudtunk megszabadulni. Ezek alattomos hibák, mert intenzív használat vagy stress test nélkül esetleg ki sem derül, hogy baj van. Mindenesetre a Microsoft Gold Partnership miatt közvetlenül tudtunk együttműködni a MS architektjeivel, és szerintem mára ezek java része megoldódott, bár a témát azóta jegeltük.

    mint a WPF-beli OnRender"
    van ilyenje a WPF-nek? Mondjuk c#-ban is van gc.collect. kismókusok meg is hívják :)

    Pár száz objektumig, ha nem kritikus a performancia kérdés, bevallom, én sem félek használni, mert kényelmes, és pl. egyszerűbb vonaldiagramokat remekül lehet vele rajzolni. :) De ha te nem kismókus, hanem öreg róka vagy, bizonyára kerülöd az OnRendert, és mást választasz, pl. közvetlen bitmapra rajzolást. Ami ugyan a GC-t már nem fogja telehányni rövid életű objektumokkal, de lévén tisztán CPU-t eszik, még mindig sokkal lassabb, mint a GDI/GDI+, amit mára a létező összes video driverben szénné optimalizáltak, és bőven GPU támogatottak.

    Persze 3rd party megoldások is vannak, de ha ilyesmit használsz, akkor már eltávolodunk a natív WPF-től.

    De most komolyan, te a ViewPort3D-re játékot akartál írni?

    Mondtam ilyet?

    najó, meguntam

    Mindenesetre a hozzászólás érdemi gondolatait értékelem.
    Mutasd a teljes hozzászólást!
  • ja, hát ha valaki bindolva akar többezer objektumot mozgatni, az ne csodálkozzon :)


    Nagyon sok fejlesztőnek oktattam WPF-et, akik elötte winformoztak
    volt, aki meglátta a deklaratív nyelv és az MVVM előnyét.
    A többieknek ez a "rossz wpf" maradt - nem pont ezekkel a szavakkal.

    Akik elkapták a fonalat, azok kb két nap után dobták a szerkesztőt, és csak gépeltek.
    Olyan ez mint a mátrix, ott a pirosruhás nő :)

    mi lett a régi nickeddel?
    Mutasd a teljes hozzászólást!
  • A WPF szerintem akkor tud lassú lenni, ha valaki valami csúfságot csinál a viewmodelben és beköti valahová ahová nem kellene. A winformsban pedig a csúnya dolgok azok az ide-oda drótozott eventek, mert hogy a databindigja nem kicsit bénácska és egy pár dolgot bizony csak eventekkel tudsz megcsinálni, Pl. ha azt akarod hogy egy gridben egy checkbox change hatására történjen valami. Anno elég sokat szívtam ilyennel, ebbõl a szempontból megváltás a WPF.

    Amit annyira nem szerettem benne amikor utoljára dolgoztam vele, az a WPF form designere. De az már vagy 6 éve volt. Gyakorlatilag minden xaml-t kézzel kellett megírni, a vizuális tervezõje kb. olyan szinten volt használhatatlan, mint az asp.net web formsnak. Ezzel szemben a winforms form editora használható, bár itt-ott az is bugos volt amikor utoljára használtam. Mondjuk az sem ma volt...
    Mutasd a teljes hozzászólást!
  • hát nem szép az élet :)

    Biztosan sok WinFormos projectet láttál már. Ha szerencséd volt, akkor elkerülted a legalját. Mert én eddig csak azt tapasztaltam, hogy a Winform maximálisan enged GÁNYOLNI.
    értsd a legalsó közvetlen hardware rétegbe is nyugodt szívvel bepakol valaki egy combobox selecteditem-et.
    Ugyanzet Wpf-ben kissé nehez tudod megcsinálni (ha van egy hozzáértő UI-os, akkor meg sehogy)
    Így aztán teljesen mindegy, hogy a cégek rájöttek, hogy a winform még támogatva lesz, amikor a programjuk már csak egy kezelhetetlen bughalmaz marad (bár ez legyen az Ő bajuk)

    "Kisebb toolokat, vagy ha látványos UI-t akarok csinálni, én is szívesebben kezdek azzal. Kis Flash-szerű appokra pl. tökéletes."

    Komplex rendszerek Ui rétegét írtam meg bennük, kb 1000x hatékonyabb és gyorsabb volt mint a Winforms-os elődje
    Kis flash-szerű appokra -- olvasatom: nem értesz hozzá :)

    "Viszont mindennek ára van, sokkal erőforrásigényesebb, mint a WinForms"
    Csak úgy pörög a CPU, zabálja az energiát. Egyszerűen nem tudok mit írni erre, ami ne lenne gúnyos

    "és ha igazán telepakoljuk controlokkal (elég egy sima űrlapra gondolni sok-sok füllel és textbox-szal), olyan lassú lesz, hogy még a gépelés, meg a kurzor villogása is szaggatni fog, nemhogy az ablak átméretezése"
    Tapasztalatom, hogy a kezdő hozzá nem értők mindig belefutnak valami olyasmibe, amitől a program lassú és kezelhetetlen lesz.
    Hogy ez nekem nem jött elő az eltelt 8 évben az biztos csak a véletlen műve, pedig néhány "apró flash alkalmazás"-nál azért jóval nagyobb project is volt itt

    "mint a WPF-beli OnRender"
    van ilyenje a WPF-nek? Mondjuk c#-ban is van gc.collect. kismókusok meg is hívják :)

    '3D-nél még rosszabb a helyzet, a WPF-beli ViewPort3D és társai iskolapéldának jók, de ha az ember sebességet is akar, jobban jár, ha egy WinForms-os form vagy panel DC-jét felkonfigurálja egy Direct3D vagy OpenGL kimenetnek, és közvetlenül babrálja a neki tetsző rendering engine-t.'
    De most komolyan, te a ViewPort3D-re játékot akartál írni?

    najó, meguntam
    Mutasd a teljes hozzászólást!
  • De milyen jó nekünk, annyira azért nem voltál lusta, hogy egy vitára tökéletesen alkalmatlan személyeskedést meg ne eresszél.

    Szerencsére eddig egész jól kijöttem az embereimmel és egyéb stakeholderekkel számos különféle projekten, úgyhogy most kölcsönösen örülhetünk, hogy sikeresen elkerültük egymást. :)

    De legalább megtudtam, hogy egész jól megélek abból is, hogy közöm nincs az egészhez. :P
    Mutasd a teljes hozzászólást!
  • túl lusta vagyok sorról-sorra  reagálni,
    Az egészről ordít, hogy közöd sincs hozzá, akik meg lájkolták, azzokkal se szívesen dolgoznék egy projecten - persze van az a pénz :) 
    nem, mégsincs
    Mutasd a teljes hozzászólást!
  • Ez lenne üzletileg a leglogikusabb.
    Mégha technikailag képes lenne többre, akkor is.
    Mutasd a teljes hozzászólást!
  • Azt nem mondtam, hogy a MS ezt fogja tenni, csak azt, hogy elvben simán lehetséges.
    Szerintem ez igazából arra lesz, hogy a legacy winformsos cuccot is be lehessen húzni core alá.
    Mutasd a teljes hozzászólást!
  • Vagyis ha a MS átveszi a projektet, "korlátlan anyagi lehetőséggel" fejleszti, hozzáteszi a saját kódjait, akkor akár jó kis multiplatformot hozhat össze.

    De ugye most akkor megint két párhuzamos termék lenne, mikor pont a WPF lenne hivatott az eszköz és oprendszer függetlenségre. Saját termékei között ellentmondásos?
    Mutasd a teljes hozzászólást!
  • Ok, kiváncsi leszek rá, hogy mennyire foglalkoztak a linuxos világgal.
    Mutasd a teljes hozzászólást!
  • A mono-ban egész pofás kis winforms implementációt csináltak anno, ami vígan mûködött linux alatt is. A Cairo tetején ült ha jól emlékzem. Anno a data binding körül voltak vele gondok, de volt már vagy 10 éve hogy utoljára néztem, azóta akár javíthatták is.
    Mutasd a teljes hozzászólást!
  • A cikkben említett multiplatformosságot honnan vette a cikkíró?

    Valóban kérdéses merre indultak.
    A WinForm ugye eredetileg csak egy héj a Win32 réteg felett.
    Ezt nem lehet multiplatformosítani.
    De átírhatták teljesen, mondjuk a Mono kódból kiindulva akár, ezzel lehet multiplatformosítani, de akkor kérdéses a kompatibilitás szintje.

    Mindenesetre érdekes, hogy megint burjánzik a GUI-k száma, ahelyett hogy erősen egységesedne és közeledne egymáshoz.
    Mutasd a teljes hozzászólást!
  • Itt is attól függ, miről van szó. Dinamikus átrendezését a felületnek (főleg, ha méretek is változnak) valóban egy rémálom hatékonyan megvalósítani WinForms-ban, arra szerintem is jobb a WPF.

    Ha viszont egyszerűen csak rengeteg egymásba ágyazott controlod van, és maximum az ablak átméretezése miatt változnak a méretek, már nem ilyen egyértelmű a helyzet. WPF-ben az eventek mindenen keresztül tunnelezése/buborékoltatása (ami az input processinget is érinti) egy roppant rugalmas megoldás, viszont azt eredményezi, hogy sok és mélyen egymásba ágyazott control esetén akár a gépelés is rettentően belassul.

    WinFormsnál ilyen nincs, ott a fókuszban lévő control az input eseményeket többnyire közvetlenül kapja meg, ezért teljesen mindegy, mi veszi körül, ugyanolyan gyors lesz (cserébe nemigen léteznek parent controlban lekezelhető Preview események, vagy csak korlátozottan).

    Az ablak átméretezés megint más tészta, ezt tipikusan lehet nagyon rosszul is csinálni WinFormsban. Az összes AutoSize megoldás, de még az Anchoring is kész katasztrófa (pedig többnyire mindenki ezt használja, mert kézenfekvőnek tűnik). Sokkal jobban járunk, ha WPF módjára mindent egymásba dockolgatunk, akár láthatatlan paneleket is felhasználva, szükség esetén Padding-ok beállítgatásával. Nemcsak kezelhetőbb, hanem sokkal gyorsabb is lesz így a felület. Illetve így már az sem feltétlenül probléma, hogy dinamikusan beszúrj/kiszedj mondjuk egy új sor panelt, dockolva a már meglévőkhöz.
    Mutasd a teljes hozzászólást!
  • Itt is arról írnak, hogy a WinForms egyáltalán nem döglött:
    https://iamtimcorey.com/ask-tim-is-winforms-dead/
    Mutasd a teljes hozzászólást!
  • sokkal erőforrásigényesebb, mint a WinForms, és ha igazán telepakoljuk controlokkal (elég egy sima űrlapra gondolni sok-sok füllel és textbox-szal), olyan lassú lesz, hogy még a gépelés, meg a kurzor villogása is szaggatni fog

    Érdekes, amit írsz, nekem pont ezzel ellentétes tapasztalatom volt.

    Még kb. 8-10 éve dolgoztam egy alkalmazáson Forms alapon, aminek dinamikusan kellett relatív bonyolult control-okat megjelenítenie (összetett objektumot lehetett szerkeszteni, képeket beleértve).

    A program - akkori gépeken - használhatatlanul lassú lett néhány elem megjelenítése után, kb. úgy, ahogy te is leírod. Nyilván beépíthető lett volna valami dinamikus adattöltögetés (bár annyira meg nem nagy adatmennyiségről volt szó), de jóval egyszerűbb megoldásnak bizonyult WPF control-t készíteni és azt hostolni a Forms-ban.

    Ma egy picit is komplexebb programot én nem állnék neki Forms-ban készíteni.
    Mutasd a teljes hozzászólást!
  • Köszi! :) Kicsit tényleg utána kellett volna néznem, csak az volt a bajom, hogy erről nem szóltak a hírek.
    Mutasd a teljes hozzászólást!
  • Na jó, átgondoltam az előző hozzászólásom végét, azért ez még nem akkora szám, mint egy platformfüggetlen Mono esetében, hiszen nyilván csak Windowsról van szó.

    De legalább még erősebb a gyanúm, hogy hamarosan WPF-re is bejelentik ugyanezt, annak meg szintén örülni fogunk. :) Főleg, ha az is 2-3-szor gyorsabb lesz, mint a classic frameworkön.
    Mutasd a teljes hozzászólást!
  • Az a cég, amelyik 15 évvel ezelőtt winforms alapokon kezdte a több tízezer fős ügyfeleinek szóló bármilyen rendszerét fejleszteni, nyilván nem fogja a 15 éve toldozott-foldozott, fejlesztett kódbázisát lecserélni.

    Ebben teljesen igazad van.

    Az utóbbi években meg kizártnak tartom, hogy élő ember winforms-al állt volna neki bármilyen komolyabb rendszernek is :D

    Ebben viszont nincs. Bár manapság a fókusz erősen áttolódott a webes alapú fejlesztésre, desktop alkalmazások esetén az üzleti világban legalább annyi új projekt indul WinForms, mint WPF alapon (most direkt nem hozom elő az egyelőre alig észrevehető UWP-t, és a mobil platformokra célzó Xamarint).

    Emögött gyakran pusztán az áll, hogy még mindig jóval kevesebb a WPF-ben profi szakember, és hogy a cégek rájöttek, hogy míg világ a világ (Windows a Windows), WinForms támogatás lesz, és ez biztosan nem fog úgy járni, úgy mint a Silverlight.

    És ahol valóban brutális méretű alkalmazásokról van szó, sok országban sok telephelyen történő fejlesztés ezrek együttműködésével, a WinForms legtöbbször praktikusabbnak bizonyul, még ha a UI az üzleti domain csak egy kis szeletét is teszi ki.

    Az elmúlt tizenpár év alatt, mióta van WPF is, egyszerűen kiderült, hogy a két platform nem ugyanabban erős. A WPF valóban nagyon átgondoltan tervezett, iszonyú rugalmas. Kisebb toolokat, vagy ha látványos UI-t akarok csinálni, én is szívesebben kezdek azzal. Kis Flash-szerű appokra pl. tökéletes. Viszont mindennek ára van, sokkal erőforrásigényesebb, mint a WinForms, és ha igazán telepakoljuk controlokkal (elég egy sima űrlapra gondolni sok-sok füllel és textbox-szal), olyan lassú lesz, hogy még a gépelés, meg a kurzor villogása is szaggatni fog, nemhogy az ablak átméretezése. De igazán gyors renderelésre sem valami jó, 2D esetén a jó öreg GDI/GDI+ rajzolás sokkal gyorsabb, mint a WPF-beli OnRender, ami objektumokat szúrogat be a visual tree-be. 3D-nél még rosszabb a helyzet, a WPF-beli ViewPort3D és társai iskolapéldának jók, de ha az ember sebességet is akar, jobban jár, ha egy WinForms-os form vagy panel DC-jét felkonfigurálja egy Direct3D vagy OpenGL kimenetnek, és közvetlenül babrálja a neki tetsző rendering engine-t. 

    A másik, hogy az az elgondolás, miszerint a programozó, és a programozáshoz annyira nem értő designer egyszerre dolgozhat ugyanazon a projekten, egyszerűen nem működik, mert a designernek ugyanabba a XAML-be kéne pakolnia az animációkat meg mindenféle effekteket, ahová a programozó teszi a bindingokat. Így a gyakorlatban 2-3 fősnél nagyobb társaság már nagyon nehezen tud ugyanazon dolgozni, hacsak nem ért mindenki egyaránt a programozáshoz is. Ezenkívül mi rengeteg memory-leak problémával is küzdöttünk, de ez már kb. 10 éves tapasztalat, lehet, hogy ezen már javítottak.

    A WinForms elavultság-érzetét erősítette, hogy amikor a WPF megjelent, a Microsoft elkezdte látványosan hanyagolni a WinForms-ot, és csak a legutóbbi konferenciáin szokott rá, hogy lelkesen bejelent valami apróságot WinForms téren is. Pedig a natív Win32 komponenskészletet bőven fejlesztették az egyes újabb Windows verziókban is, amiből a .NET WinFormsa már semmit nem követett le. Olyanokra gondolok, mint pl. glass window, command link buttonok, SplitButton, progress a tálcán, progress warning/error, ribbon controlok, fading animációk kb. minden controlra, egy csomó design-beli apróság pl. ListView, TreeView esetén, stb. Pár Windows messaging trükkel mindezek előcsalhatók az eredeti controlokra is, de leginkább a neten elérhető számtalan 3rd party komponenskészlettel használhatjuk ki ezeket (míg pl. Delphi vonalon a VCL mindig is folyamatosan megújult). A tiszta design, MVC vagy MVVM pattern is simán megvalósítható WinForms alapokon, ez csak policy és projekt konvenciók kérdése.

    Tovább árnyalja a helyzetet, hogy a WPF ugyanúgy nem lett platformfüggetlen, mint a WinForms, és manapság kezdik azt is sokan obsolete-nek beállítani a még újabb technológiák javára. A Mono belebukott a WPF portolásába (bár hivatalosan sosem adta fel), és bár a WinForms támogatása nem mentes a kompromisszumoktól, legalább létezik valami .NET-es UI, ami valamelyest platformfüggetlennek tekinthető.

    Én tehát örülök, hogy a Microsoft nem szégyelli újra "felvállalni" a WinForms-ot. Persze van egy olyan reményem is, hogy azért ezt jelentették most be, mert ezt volt könnyebb portolni, de azért javában dolgoznak a WPF portolásán is, és meglépik azt, ami annak idején a Monónak nem sikerült. Na az tényleg nagyot szólna...
    Mutasd a teljes hozzászólást!
  • Nem baj, ha nem érted, olvass utána bátran :)

    Az egész .Net Core eleve az Asp.Net-hez lett kitalálva, csak utána annyira megtetszett mindenkinek (mert tényleg ütős lett), hogy elkezdték kiterjeszteni a támogatását más fejlesztői irányokba is.
    Gondolom a WinFormshoz is csak azért jutottak el, hogy végre végleg nyugdíjazhassák a jó öreg .Net Frameworköt.

    LTS verzió meg hónapok óta van a 2-eshez is, hogy a himi-humi hosting cégek nem támogatják az Asp.Net Core-t, az meg kit érdekel, amikor Azure-ban / AWS-ben / Google AppEngine-ben "ingyen" tudod hostolni. A himi-humi hostingok akkor se fogják támogatni, ha van LTS verzió hozzá :D Náluk fent van egy Apache, meg egy Mysql a garázsban üzemeltetett 10 éve a pc bontóból összerakott "szerveren" azt jóvan az úgy.
    Mutasd a teljes hozzászólást!
  • Hivatalos a .NET 3.0 - teljes értékű WinForms támogatással

    Nem a .NET 3.0 lett hivatalos, mert az 2006-ban már megjelent, hanem a .NET Core 3.0 :)
    Mutasd a teljes hozzászólást!
  • A cikkben említett multiplatformosságot honnan vette a cikkíró? Mert én korábban több  anyagot láttam ezzel kapcsolatban, és ott csak azt ígérték, hogy Windows-on lesz támogatva a WinForm.
    Mutasd a teljes hozzászólást!
  • LTS van 2.1-től, nem?
    .NET Support Policy

    Amúgy ettől függetlenül azure-ban, vagy docker alatt (gyakorlatilag bármelyik vps szolgáltatónál használható) üzemeltethető most is.
    Mutasd a teljes hozzászólást!
  • Én továbbra sem értem ezt az egész .NET Core koncepciót.

    Azt értem, hogy többnyire az asztali alkalmazásfejlesztést célozzák meg, de ott van mellette az ASP.NET Core, amivel szerintem jobban lehet kaszálni. Ehhez képest azt látom, hogy ennek az elérhetősége egy hosting-on egyáltalán nincs, mivel nem adtak ki még a .NET Core 2-höz LTS verziót. Nem azt kéne befejezni előbb?
    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