- Magyarított Android alkalmazások
- Telekom mobilszolgáltatások
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S21 FE 5G - utóirat
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Samsung Galaxy A56 - megbízható középszerűség
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A55 - új év, régi stratégia
- Samsung Galaxy A54 - türelemjáték
Új hozzászólás Aktív témák
-
martonx
veterán
// userdata a method paraméterében
var existingUserData = await db.SpotifyUsers.SingleOrDefaultAsync(x => x.Username == userdata.Id);
if (existingUserData is null) {
db.SpotifyUsers.Add(userdata);
}
else
{
existingUserData.X = userdata.X;
existingUserData.Y = userdata.Y
}await db.SaveChangesAsync();
Ennyi.
-
martonx
veterán
Érthető, de ahogy Alexios is írja, itt nincs semmi redundancia az update-nél
Hiszen te magad kéred le a kódban, hogy létezik-e. Ha létezik, akkor propertynként update és csá.
Hol itt a redundacia?
Ehelyett valami ezeréves szar trükközéssel próbálkoztál, ami persze hogy nem megy, mert ezer éves, azóta négyszer újraírták az FE-t meg amúgy is pont az a felesleges redundancia.
Az existinget meg nem where-el kellene lekérned hanem SingleOrDefault-tal, az már elég csúnya lenne, ha a username-ek duplikáltak lennének. -
martonx
veterán
válasz
ReSeTer
#10140
üzenetére
Unit teszt is jó ötlet. Érted (vagy nem), de önmagában a class library nem futtatható, ergo nem debuggolható
Ez nem debuggolási kérdés, vagy hogy VS-t használsz-e.
Visual Studio Code is pont ugyanúgy megfelel a célnak. Egy console app-ba be kell referálnod, vagy egy unit tesztbe, vagy bármibe ami futtatható, és azon belül fogod tudni debuggolni, futtatni a class librarydet. -
martonx
veterán
Srácok, olvastam a felvetést, de direkt nem válaszolok a trollkodásra. Mert ez már színtiszta trollkodás.
Mindenki tökéletesen értette, gyanítom pmonitor is, hogy mit írtam.
Mintha nem lehetne valaki react, vagy angular fejlesztő, miközben nyilvánvalóan javascripttel / typescripttel dolgozik.
Trollkodni mindig lehet, válaszolni ezekre a baromságokra semmi értelme. Kérem ne etessük a trollt, lépjünk tovább, nincs itt semmi látnivaló. -
martonx
veterán
Microsoft Graph-al valahogy így kellene nekiállni:
1. Get started using OneDrive API - OneDrive dev center | Microsoft Learn
2. Download a file - OneDrive API - OneDrive dev center | Microsoft Learn -
martonx
veterán
válasz
joysefke
#10101
üzenetére
Persze, csak a sima Auth annotációval ráraksz valamit, ami fekete doboz, és fogalmad se lesz, hogy teljesül-e vagy nem, vagy egyáltalán jó helyen keresgélsz-e. Csak azt látod, hogy 401.
Vagy ha mázlid van, akkor azt látod, hogy beenged.
Ezért gondoltam elsőre annotáció nélkül megdebuggolni a metóduson belül, hogy WTF, aztán majd persze csinálni erre egy custom Auth attribute-ot. -
martonx
veterán
válasz
joysefke
#10098
üzenetére
Szerintem ezt annotációval nem fogod tudni megoldani, no persze custom auth attribute-al szépen megoldható.
Elsőre elég lehet egy if az onGetAccountban, ami jól látod megvizsgálja a Usert. Remélhetőleg valahol látszódni fog a useren, hogy min keresztül lépett be.
És majd ha ez már szépen működik, majd ki lehet emelni egy custum Authentication attribute-ba. -
martonx
veterán
válasz
pmonitor
#10096
üzenetére
fontos, hogy nagybetűvel írtam a Usert, ugyanis Asp.Net-ben így hívják a user entitást, ami HttpContext-ben van. Szóval reményeim szerint érti, mire gondolok. Ez éppen egy nagyon jó példa arra, hogy még Asp.Net-en belül is annyiféle megoldás van, annyira szerteágazó, hogy rohadtul nem az a kérdés, hogy a byte array hány byte-on tárolódik, hanem lásd a fenti kérdést.
Amire még én, mint Asp.Net fejlesztő se tudok csukott szemmel válaszolni, mert razort pl. sose használtam, MVC-t, és API-t szoktam fejleszteni. Nyilván fingom sincs fejből, hogy mi lehet az OnGetAccount-ban, mire lát rá, mit kellene pluszban behúzni ahhoz, hogy megjelenjen a User.
Meg persze kód példa nélkül nehéz is konkrétumokról beszélni Meg persze, ha rászánnék még plusz 20 percet, és életemben először nyitnék egy razor page-es Asp.Net-es projektet, akkor valószínűleg pontosabban tudnék válaszolni neki, így csak iránymutatást tudok adni. -
-
martonx
veterán
A megfelelő github action dokumentációját kellene átnézd. Ennyiből amit küldtél még az se derül ki, hogy ez App Service vagy egy virtuális gép, vagy Azure function, vagy egy docker image. Szóval amelyik lépésnél dobódik ez a hiba, annak az actionnek a doksiját nézd át, github issue-jait, hátha meg lesz a megoldás.
Ha nem lesz meg, akkor pedig érdemes indítanod github issue-t nekik. -
martonx
veterán
válasz
skyrush7
#10001
üzenetére
Szia!
Ahogy látom a booking.com-nak van nagyon profi API-ja: Booking.com APIs and Documentation
Szallas.hu esetében viszont nem igazán találtam ilyet, én a helyedben felvenném velük a kapcsolatot, szeretném hinni, hogy van nekik is API-juk.
iCal-t a helyedben nem erőltetném, API integráció irányába mennék. -
martonx
veterán
válasz
rgeorge
#9993
üzenetére
.Net 8-nál tartunk. Számomra már az is csoda, hogy VS2022-vel ezek az ősi kódok még futnak. Gyanítom már senki sem teszteli komolyan, hogy újabb és újabb VS-el minden spéci 15-20 éves kód hibátlanul működjön.
Azért én a helyedben küldenék egy github issue-t a fejlesztőknek, hátha nem legyintenek rá, az őskövület kód problémájára. -
martonx
veterán
Az megvan, hogy amit írsz az nettó hülyeség? Mind a logger, mind a DB esetben?
Dependency Injectionről hallottál már?
De még ha nem is, akkor is hülyeség, amit írsz, ne mondd már, hogy Asp.Net Core-ban folyton újra és újra paraméterezgetni kell a DB-t, meg a Loggert
Vagy akkor valamit őrületesen rosszul kezdtél el, és előbb talán a hivatalos dokumentációt érdemes lenne átfutnod. Asp.Net Core nem is létezik DI nélkül. Akkor meg miről beszélünk? -
martonx
veterán
válasz
bandi0000
#9953
üzenetére
Ha Auto Migration kell, akkor a program.cs-be érdemes rakni egy ilyet:
//Auto migration
using var serviceScope = (app as IApplicationBuilder).ApplicationServices.GetRequiredService<IServiceScopeFactory>().CreateScope();
using var context = serviceScope.ServiceProvider.GetService<ApplicationDbContext>();
await context!.Database.MigrateAsync(); -
martonx
veterán
Úristen a razor pagestől a mai napig kiver a víz. Php-ról áttérők miatt került bele a keretrendszerbe. Egyébként teljesen rosszul kezdtél neki, előbb doksit kellene olvasnod, nagyon jól le van írva az ASP. Net Core identity tutorialokkal. Fórumokban kérdezgetés, meg vakon neki esés helyett:
1. Doksi olvasás
2. Doksiban lévő tutorialok végig nyomásaMajd ha ezek után még van kérdés, szívesen segítek. Jól választottál ASP. Net Core-al, php után Trabant - Mercedes a különbség.
-
martonx
veterán
válasz
CPT.Pirk
#9917
üzenetére
Ez esetben van egy jó hírem: Most gyorsan kipróbáltam .Net 7-tel. Ezek voltak a beállításaim a csproj file-ban:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<PublishSingleFile>true</PublishSingleFile>
<SelfContained>true</SelfContained>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
</Project>Lelövöm a poént 14Mb-os lett a dotnet publish után előálló .exe file-om, amiben benne van a szükséges runtime is. Igaz, hogy ez csak egy console app.
"másik nyelvnél még ilyen megoldással nem találkoztam" - nincs hátránya, hacsak az nem, hogy ilyenkor kötelező előre megmondanod, milyen OS-t célzol meg. Más nyelveknék előbb telepítened kell a runtime-ot, és majd csak utána tudsz bármit futtatni. A .Net eléggé király ezzel, hogy vinni tudja magával a minimálisan szükséges runtime-ot (gyorsan tegyük hozzá, hogy ez csak console appokra igaz cross platform szinten, nem cross-platform szinten windows only feature).
-
martonx
veterán
válasz
Alcsi69
#9866
üzenetére
Nem csak backend fejlesztésre használják. Winforms, WPF fejlesztés a mai napig is megy. De éldegél még a Xamarin is cross-platform fejlesztéshez.
Ennek utódja a reményteljes MAUI, amitől szintén nagyon félek, mert ez is új MS technológia és ez is a hányadék, régen semennyire se dokumentált, most nem tudom milyen állapotban lévő XAML leíró nyelvre alapul. Ha nem XAML lenne, már rég belevágtam volna a MAUI-ba. XAML helyett lehet MAUI-t hibrid Blazor appként is írni, ami meg számomra pláne a "húbazdmegezcsodahaműködik" kategória.
És jól látod, ott van még a Blazor, mint böngészős frontend technológia, amiről feljebb leírtam a véleményem.
Nyilván a böngészőben futó egyetlen nyelv a javascript. Webassemblyvel lehet az összes többi nyelvet futtathatóvá trükközni a böngészőkben, de ahogy írtam is ezek csak szerencsétlen trükközések, mert a DOM-hoz nem férnek hozzá, ergo nem tudják a régi jó JS-t megkerülni. -
martonx
veterán
válasz
Alcsi69
#9864
üzenetére
A Blazor jelenleg semennyire se népszerű. Egyrészt MS elég béna az új technológiákban, ezért jó érzésű ember fázik ráugrani az MS újdonságaira. Másrészt az egész WebAssembly technológia félkarú óriás a DOM manipuláció nélkül, azaz mindenképpen JS kell hozzá, és még lassú is, csomó kezdeti adatot letölt stb. Ezt persze a framework ügyesen próbálja leplezni, de ettől még a tények makacs dolgok.
Ettől függetlenül miért ne használhatnád, játszhatnál vele, ha érdekel? Nagyságrendekkel jobb nyelv a C#, mint a Js.
-
martonx
veterán
Én inkább félve kérdezem meg, próbálta már valaki komolyabban a MAUI-t (úgy értem sample todo appokon túljutva, komplexebb appokban, neadj isten productionben)? Minden új MS technológiától ráz a hideg, mert ki tudja mikor lövik le / veszítik el az érdeklődésüket.
Xamarinnal szopattam magam egy darabig, XAML-t rühellem, szóval erős fenntartásaim vannak a MAUI-al. -
martonx
veterán
válasz
Alexios
#9853
üzenetére
Na, éppen a react native az egy ótvar szar. Én ugyan. Net-ezek, de az új MS technológiákhoz, amikből folyton jön egy új megváltó, majd jól pofára eső, végül eltünő, nagyon óvatosan közelítek. Ami xaml-ön alapul, azt különösen ferde szemmel nézem.
Mivel react native egy fos, ha már mobil cross-platform a cél, akkor szvsz flutter.
De. Net 7 után lehet tennék egy próbát a MAUI-al is,addigra hátha kinő pár gyerek betegséget.
tboy93 kíváncsian várom majd a MAUI-os tapasztalatodat, véleményedet.. Net 6-al jelen állapotában, biztos hogy bottal se piszkálnám. -
martonx
veterán
válasz
leslie23
#9798
üzenetére
Manapság, amikor a gépeknek van minimum 8GB ramja, szerintem semmi se akadályoz meg abban, hogy ramban tárold, amit csak tudsz. Mi lehet a legrosszabb, ami történik? A winforms appod memória használata felmegy 1-2GB-ig? Na ügy
Az első kérdésedre elég egyértelmű, hogy mi történik. Ha nincs a connection stringben a timeout beállítva, akkor a default azt hiszem 30s.
Azt írod, hogy ezek egyenként 5-15 másodpercesek. Igen ám, de nem nehéz belátni, hogy ha ilyen queryből futtatsz 15-öt párhuzamosan, akkor szegény DB szervernek sem 5-15 másodpercébe fog kerülni egyet-egyet végrehajtani, hanem ki tudja mennyivel többe (SQL szerver erőforrásaitól függ). Ergo simán elérheti a 30 másodpercet is 1-1 lekérdezés ideje, és voilá, máris kapod a hiba üzenetet. Legalábbis szerintem ez történik, és ezért is javul meg, amikor connection stringben belefoglalod a korlátlan timeout időt. Vagy egyszerűen csak megölöd a DB-t, és timeout időn belül még új connectiont létrehozni sem sikerül felé.
Biztos, hogy valami ilyesmi lesz a problémád forrása. -
martonx
veterán
válasz
joysefke
#9774
üzenetére
"Kérdése alapján már a táblákban kódolva van a struktúra (ki-kinek gyermeke) ezt kéne dekódolni és meghatározni, hogy a gráf csúcsai hogyan nézzenek ki kódba öntve, illetve hogyan tárolják a köztük lévő relációkat."
Igen, ez elég egyértelmű volt
És erre küldtem a minimalista példa kódot, mert szemlátomást emberünk csak és kizárólag fix dimenziós tömbökben tud gondolkozni, ti meg rögtön gráf-os legbonylultabb esetek lekezeléséhez alkalmas módszerekkel kezdtétek bombázni, miközben jó eséllyel olyan bonyolultságú a gráfja, mint egy meghajtón lévő mappákban lévő file-ok szerkezete. Aminek leképezéséhez semmi spéci nem kell, csak az én példa classom.
Persze ez is csak feltételezés, mivel nem sok konkrétumot tudtunk meg. -
martonx
veterán
Abszolút rosszul állsz hozzá. Ezt bármilyen nyelven meg lehet csinálni, csak nem úgy ahogy te próbálod.
Felejtsd el az array-t. Csinálsz egy objektumot, amiben van egy lista.public class MyGraph
{
public string Name;
public List<MyGraph> Children
}És ebbe végig fel tudod építeni az egész gráfot,
-
martonx
veterán
"A visualstudio .net alapon hozna létre minden formot. (drag and drop a felülettervezés? Nem lenne komplex a weblap, csak 10 gomb meg 3 táblázat (dinamikus rádiógomobkkal meg checkboxokkal)."
Ilyen nincs. A webfejlesztés nagyon nem olyan, mint a winforms Szóval nincs mese, fel kell majd kötni a gatyát 
Hacsak nem az évek óta elavult, depreciated Asp.Net Web Forms-ra akarsz alapozni, amit felejts el nagyon gyorsan.A .Net 2017 óta cross platform (feltéve, hogy a brutál elavult Asp.Net Web Forms-ot szóba se hozzuk, mert az még nem volt cross platform, csak Windows szerveren futott), tök mindegy neki, hogy linuxon vagy windows-on fut.
"Ezen túlmutatóan ha objektumorientáltan akarom a táblázat elemeit megjeleníteni (leképzeni), mert mindegyik elem egy halmaz információt hordoz, akkor c#-ot hogy tudok egy weblap mögé tenni? (ez már gondolom mélyebb kérdés)"
2022-t írunk, a kérdésed szerintem az évtizede elavult Asp.Net Web Forms-ra vonatkozik. Javaslom egy nagy lendülettel ugorj a mába, és tarts pár év gyorsképzést magadnak.
Az internet tele van anyagokkal.Ezt a projektet meg egyelőre felejtsd el, amíg ennyire durván nem vagy tisztában semmivel, és koncentrálj a Hello World és ToDo szintű projektekre.
-
martonx
veterán
válasz
Victoryus
#9749
üzenetére
hagyd az access-es ősi db-t, használj localdb-t vagy valami rendes SQL-t. Delphi ide vagy oda, a local db, akkor sem fog magától átvándorolni a gépek között
EF Core-nál javaslom még a DB migration-t beröccenteni, és akkor legalább a DB sémád rendben tud lenni a gépek között.Úristen, ebből a jegyzetből még én is tanultam több, mint 10 évvel ezelőtt. Ezt felejtsd el, online, naprakész anyagokból tanulj, ne ilyen régi szarokból!
-
martonx
veterán
válasz
Alexios
#9715
üzenetére
Mac-en az egyetlen komolyan vehető C# IDE a Rider, igen ez jogos (windows-on a mellettem ülő kolléga Riderezik, én VS, hát egyelőre még a VS jobb, de a Rider se rossz, illetve van amiben a Rider messze jobb azért a pénzért pl. tesztek).
Mondjuk az ingyenes VS Code-al is konzol appok, minimal web api-k szintjén el lehet lenni. Xamarinról abszolút nincs tapasztalatom OSX-en, tegyük rögtön hozzá, hogy szvsz a Xamarin még windows-on is macerás Mac-en nem lepődnék meg, ha abszolút nem is működne a Xamarinos fejlesztés. -
martonx
veterán
válasz
ReSeTer
#9692
üzenetére
Az excelből adat kinyerés C#-al eléggé tiszta ügy, van ehhez csomó nuget package. Ami itt izgi tud lenni, az a word sablon file-ba berakás, formázás.
De szerintem ehhez is vannak nuget package-ek, amikkel word file-t tudsz generálni. Legvégső esetben pedig OpenXml egy szabvány, semmi nem gátol meg abban, hogy bármit összerakj OpenXml-ben (kivéve, hogy k...va bonyolult ). Ekkor egyedül arra kell odafigyelned, hogy amit csinálsz az valami régi Office verzióval legyen kompatibilis pl. Office 2007-tel, mert az új Office-ok mind fogják tudni kezelni a régi file-t, de ha új verzióra lősz, akkor azt nem fogják tudni kezelni a régi Office-ok. -
martonx
veterán
válasz
bandi0000
#9669
üzenetére
"Mi okozhat olyat, hogy egy sima tàblàba való beszúrásnál dead lockot kapok, elvileg más nem használja ezt a táblàt"
Itt jön be az elmélet és a gyakorlat különbsége
Viszont, ha már dead lockot kapsz, akkor az azt is jelentheti, hogy gyakorlatilag folyamatosan írva van a tábla, lehet hogy több szálon futva.
Én a helyedben erősen újra gondolnám a DB sémát, EF használatát (lehet bulk insert jobb lenne?), cachelési stratégiát, ilyesmiket. Illetve erősen javaslom (ha lehetséges) .Net 6 irányába tovább mozdulni az ősi .Net Framework helyett. Hidd el, az elmúlt 5 évben elég sok mindenen optimalizáltak. -
martonx
veterán
1. könyörgök jegyezd már meg a keretrendszerek nevét, vagy örökre ignorálni foglak trollkodásért. .Net 5.0 van most. Előtte pedig két ág létezett:
.Net Framework, ami 4.8-ig jutott el
.Net Core, ami 3.1-ig jutott el.
Olyan, hogy régi .Net nem mond semmit, mert nem értjük, hogy .Net Core-ra, vagy .Net Frameworkre gondolsz. Ahogy a .Net őskövület (oké, de melyik???, amelyik 2001-ben jelent meg vagy amelyik 2017-ben jelent meg?) kijelentés se árul el semmit, azon kívül, hogy megtudtuk, hogy fingod sincs, hogy miről beszélsz. Hagy ne kelljen minden egyes mondatodat interpretálni, és azon töprengeni, hogy mire gondolhatott a költő.2. nagyon csodálnám, ha ne lehetne ezt a fajta kókányolást (kényelmes tool használatot, ahogy te hívod) megoldani .Net 5.0-val.
-
martonx
veterán
-
martonx
veterán
Alexios megelőzött. Ez már évek óta így van, mondjuk a .Net Core 1.x még nagyon fapados volt, 2.x-től kezdve én már soha többé nem is használtam a régi .Net Frameworköt.
5.0-tól kezdve meg elhagyták a core-t a nevéből, és már csak .Net 5.0-nak hívják a zavarokat elkerülendő.És a .Net core 2.x óta tudsz olyan appokat írni, amikhez semmit nem kell telepíteni (se előtelepítve lennie a gépen, ellentétben a régi .Net Frameworkkel), egyik OS-en sem, mindent magába foglal. És simán fut Windows-on / linuxon / osx-en. Jó persze, ahogy feljebb írtuk, ezek GUI nélküli appok, azaz console appok / web appok.
Az idén év végén befutó 6.0 viszont már cross-platform GUI-t is fog tudni. -
martonx
veterán
Kevered a dolgokat. A .Net 5.0 nagyon nem egyenlő a régi .Net Framework-kel (ami 4.8-al ért véget).
A .Net 5.0 az a .Net Core-ra épül, viszont több mindent átemeltek a régi .Net Frameworkből, vehetjük úgy, hogy összeolvadtak.
És egyrészt igen, a .Net Core már cross platform. Másrészt a windows-os GUI elemek továbbra sem használhatóak linux-on. azaz a klasszikus winforms és wpf alkalmazások pont ilyenek, amik továbbra is csak windows only-k.
A .Net 6.0 idén év vége felé fog megjelenni, és az már abszolút cross-platform GUI-t is fog tartalmazni MAUI néven fut, jelenleg még csak preview.Addig is mindez áthidalható pl. AvaloniaUI-val(ami cross-platform jelenleg is) : Avalonia UI Framework
-
martonx
veterán
winget-cli pont erre van, kb. 1 éve elégedetten használom. Igaz, a mai napig sincs meg minden rajta 100%-ban, pontosabban az elmúlt 1 évben 1 olyan alkalmazás volt, amit csak a scoop-ból (ez is olyan, mint a winget) tudtam beszerezni.
microsoft/winget-cli: Windows Package Manager CLI (aka winget) (github.com)
winget-pkgs/manifests at master · microsoft/winget-pkgs (github.com) - ezek vannak most rajta, percről percre bővül a lista. Ha te ezt meg tudod számolni, akkor sok sikertDe a belinkelt chocolatey is tök jó.
Nem fog hamvába halni, mivel ha figyelemmel követed, MS nagyon tolja a console irányt (windows terminal).
-
martonx
veterán
válasz
pmonitor
#9506
üzenetére
Továbbra sem értek egyet. Kezdőkről, sőt ha az eredeti kérdést olvastad, ultrakezdőkről beszélünk.
Akik nem azért kotorásznak a designer.cs file-ban, mert tudatosan abban akarnak módosítani, hanem mert olyan szinten fingjuk sincs, hogy mit csinálnak, hogy találomra bökdösnek a boldogan megtalált .cs file-okra.Ergo őket nem félrevezetni kellene, meg összezavarni, és ne abból indulj ki, hogy minden kezdő egyébként istenadta programozózseni, csak még kevés a tapasztalata.
Hanem egyértelmű iránymutatásokkal terelgetni, és majd ha egyszer (valaha?) oda jut, hogy valamit elrontott a designer file-ok piszkálása nélkül, akkor jöhet az igazság minden részletének kibontása , hogy figyi vannak ezek a designer file-ok, amikről eddig azt mondtuk, hogy ezeket nem kellene piszkálni. No, de ezek nem poénból vannak ott, van olyan eset, amikor ezekben kell javítani a visual kódszerkesztő dolgait. Ilyenkor ezekbe tudatosan bele lehet, sőt kell is nyúlni.
Ettől még az ökölszabály, hogy ezeket nem kellene piszkálni, továbbra is áll.Egyébként meg kötözködés helyett, neked is szabad megválaszolnod kérdéseket, szabad a pálya.
Mindenki szabadidejében teszi, te is nyugodtan beleállhatsz, csak ne zavard össze, ne vidd félre szegény kezdőket -
#9482
martonx
veterán
Atomantiii
#9481
martonx
veterán
válasz
Atomantiii
#9481
üzenetére
Évtizedek óta nem winforms-oztam, de szvsz a *.designer.cs fileokat nem szabadna módosítani. Szóval rosszul álltál neki, rossz helyen módosítasz.
-
martonx
veterán
válasz
joysefke
#9435
üzenetére
Jaj, ne is mondd, most tárgyalok épp egy céggel, akikhez lehet átmennék, és mindenképpen laptopot akarnak adni, én pedig mindenképpen asztali gépet szeretnék (az nekem nem baj, ha adnak laptopot IS).
Itthonról Ryzen 5 3600-on dolgozok PCIe4-es SSD-vel, tuning ramokkal. Ezt a gépet összevetni a régi céges i7-6700, SATA SSD-vel, háááát ég és föld.
Nem értem miért kell a cégeknek úgy tenniük, mintha csak laptopról lehetne rugalmas (home office és irodai, mikor hogy) munkát végezni. -
-
martonx
veterán
válasz
kw3v865
#9416
üzenetére
Megjegyzés 1: nagyon gyorsan felejtsd el a magyar változó neveket. Sírni tudnék, ahányszor magyar/német/bármi ami nem angol változóneveket látok.
Megjegyzés 2: használd a LINQ-t. pl nem lista[0] hanem lista.First() máris sokkal szebb, olvashatóbb.
És valami ilyesmi fog neked kelleni:
var states = myList.First().Select(item => item.state);Ha ragaszkodsz az array kimenethez, akkor egy ToArray()-t is érdemes a végére csapni. -
martonx
veterán
-
martonx
veterán
válasz
Dexter74
#9390
üzenetére
Ezer éve preóbálkoztam utoljára winforms és classic EF-el.
Azt javaslom, próbáld meg esetleg .Net Core-al. PomeloFoundation/Pomelo.EntityFrameworkCore.MySql: Entity Framework Core provider for MySQL and MariaDB built on top of MySqlConnector (github.com) -
#9383
martonx
veterán
Dawide@axele
#9381
martonx
veterán
válasz
Dawide@axele
#9381
üzenetére
Segítek Visual Studio és C# fog hozzá kelleni
némi guglizást is javaslok a témában. -
martonx
veterán
Gyors Guglizás után a version keyword nem támogatott Microsoft.Data.Sqlite.Core alatt függetlenül az operációs rendszertől, más kérdés, hogy Linux alatt szerintem eleve helytelen útvonal az F:\chinook.db
Helyette Mode=ReadOnly kell a connectionstringbe? -
martonx
veterán
Ez már tényleg nagyon off, de manapság elindult egy trend, ahol frontend huszárok mindenhez is rögtön angulart, meg reactot typescripttel, rxjs-el, redux-al (izé most a recoil a menő), meg mittudomén mi mindennel rántanak elő. Aztán napokig dolgoznak egy egy oldalon, aminek a feladat annyi, hogy egy form van rajta, amin megadsz pár adatot, és gombnyomásra elpostolja a szervernek. Na, erre értettem, hogy a typescript overkill frontenden. Nyilván van olyan frontend eset, ahol tényleg hasznos tud lenni, viszont azt látom, hogy a typescript-es frontend projektek többségében, csak szimpla öncélú bonyolítás, mert a frontendes részleg meg akarja mutatni a backendnek, hogy igenis ők is tudnak sok n rétegben, interface-ekben, DI-ban, meg bonyolult kódokban gondolkozni, akkor is ha csak egy fos formot kell bekérni 4 adattal.
-
martonx
veterán
válasz
Froclee
#9276
üzenetére
Nálunk a cégnél mostanában kezdtek a C# mellé Pythonos Web Api-k bejönni. Egészen elképesztően kókány szarok a kódjaik (de legalább lassúak is), az Asp.Net Core-al összevetve.
Pedig én pl. a PHP-t kimondottan szeretem, Pythont is magamtól raktam a gépemre, hogy eljátsszak vele, azaz nem vagyok az a fanboy típus.
Szerintem mint nyelv, semmi gond nincs a gyengén típusossággal, tök jó a PHP, Python. Kis egyszerű konzol appokat, web api-kat összedobni bennük, data science-kedni (ami szintén nem programozás, maximum egy kis scriptelés), megtanulni programozni tök jók. Viszont komolyabb alkalmazásokat csak bolondok írnak ezekben.
Hiszen te magad kéred le a kódban, hogy létezik-e. Ha létezik, akkor propertynként update és csá.
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- T14s Gen4 14" FHD+ IPS i7-1365U 16GB 512GB NVMe magyar bill IR kam gar
- Gopro hero 7 black
- ThinkBook 16p Gen3 16" QHD+ IPS Ryzen 5 6600H RTX 3060 16GB 512GB NVMe ujjlolv gar
- ThinkBook 16p Gen3 16" QHD+ IPS Ryzen 5 6600H RTX 3060 16GB 512GB NVMe ujjlolv gar
- HP Probook 640 G2 (14FHD/i3-G6/8GB/256SSD/Magyar/Win11) - Szép!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Apple iPhone 14 256GB/ 86% Akkuval / 12 hónap jótállással!
- AKCIÓ! Gigabyte B85-HD3 B85 chipset alaplap garanciával hibátlan működéssel
- Telefon felvásárlás!! Samsung Galaxy A20e/Samsung Galaxy A40/Samsung Galaxy A04s/Samsung Galaxy A03s
- Intel Core 2 Quad Q9550 2.83GHz LGA775 Processzor
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest