- Red Magic 10 Air - gaming telefon is lehet kecses
- iPhone topik
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Rekord vékony lesz a Z Flip7 is
- Samsung Galaxy Watch7 - kötelező kör
- Milyen okostelefont vegyek?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Magisk
- One mobilszolgáltatások
- Poco X6 Pro - ötös alá
Új hozzászólás Aktív témák
-
#9336
joysefke
veterán
DrojDtroll
#9334
joysefke
veterán
válasz
DrojDtroll
#9334
üzenetére
Igen, én is észrevettem, de szvsz nem a forrásadatokkal van a probléma, hanem a két metódusod nem ugyanazt a bytesorrendet használja, tehát a tömbök tartalma amelyeket visszaadnak sem ugyanaz lesz.
Amikor a második metódusban streamből beolvasol egy ulongot, akkor a ReadUInt64() figyelembe veszi az x86 bytesorrendjét: a változónak a kisebb helyiértékű byteja van alacsonyabb címen (little endian). Ha a streamed sorrendben ezeket a byteoket tartalmazza:
1, 0x01; 2, 0x02; 3; 0x03; 4, 0x04; 5; 0x05; 6, 0x06; 7, 0x07;8, 0x08;akkor a kiolvasott ulong értéke az 0x08'07'06'05'04'03'02'01 lesz, szemben azzal a sorrenddel amit a fileban látsz.
Ha ezt a részt fordított sorrendbe raknád, akkor pont ugyanazt a tömböt adná vissza a kettő metódusod.
result[++j, i] = (ushort)(r >> 48);result[++j, i] = (ushort)(r >> 32);result[++j, i] = (ushort)(r >> 16);result[++j, i] = (ushort)r; -
#9335
joysefke
veterán
DrojDtroll
#9331
joysefke
veterán
válasz
DrojDtroll
#9331
üzenetére
for (int i = 0; i < heigth; i++){for (int j = 0; j < width; j++){result[j, i] = reader.ReadUInt16();}}Itt van még egy olyan probléma (mindkét példádban), hogy úgy iterálsz át egy nagy többdimenziós tömbön, hogy a belső ciklusod nem a tömb legjobboldalibb dimenzióján iterál.
C#-ban a többdimenziós tömbök (A[,,,]) row-major ként vannak a memóriában, tehát a legjobb oldalibb dimenzió egymás melletti elemei a memóriában egymás mellett lesznek. az A[100, 50] elem mellett az A[100,51] elem van. Ezzel szemben az A[101,50] az teljesen máshol van, a te esetedben (2048) elemmel később mint az A[100,50], tehát mivel int tömbről van szó, 8KB-tal később van. Az hogy itt csak írsz és nem olvasol kb mindegy, mert nyilván egy egész cache line lesz írva/olvasva.
A helyzeten cache-line szempontből még (valószínűleg) tovább ront itt, hogy kettő hatványonként iterálsz. ilyen problémák nagy mátrixok szorzásánál vannak
-
joysefke
veterán
válasz
joysefke
#9332
üzenetére
Uhh az utolsó pontot visszavonom, látom, hogy a belső ciklus 4esével változik növeli a törzsön belül a ciklusváltozót. késő van na
Nyilván segít neki, hogy negyed annyi io van. De igazán jo szvsz akkor lesz ha nagy puffer mellett byte tömböt olvasol be addig amíg van mit olvasni. -
#9332
joysefke
veterán
DrojDtroll
#9331
joysefke
veterán
válasz
DrojDtroll
#9331
üzenetére
Nincs időm kipróbálni, de nekem egyáltalán nem szimpatikus egy ilyen nagy fájlnak a mini adagokban való szekvenciális olvasgatása.
1, Miért nem a sima stream Read metódussal olvasol azonnal byte[] tömbbe?
2, Én megpróbálnám a bufferméreteket manuálisan feljebb húzni. Alapból csak valami ici-pici bufferekkel dolgozik. (nekem pár 10KB rémlik)
3, Nem mintha itt számítania kellene de te itt ugye 4M elemen iterálsz át egy szoros for () ciklusban => ha nem fájlműveletet végeznél, akkor már ez is bizonyos helyzetekben indokolatlanul lassú (4M tömbhatár ellenőrzés az indexerekre+ ellenőrzés az iterátoron, szerk: mondjuk 4M az még nem túl sok..)
(4, miért int tömbben-ben tárolod a short értékeidet?)5, a két kód ránézésre nem ugyanazt csinálja. a második konkrétan elcseszettnek tűnik.
64bitenként olvasol és ugyanúgy 4M-szor mint amikor 16 bitenként olvastál???? -
joysefke
veterán
válasz
kiskornel
#9324
üzenetére
Vannak loggoló frameworkok, pld "Serilog". https://github.com/serilog/serilog/wiki/Getting-Started#example-application
Itt egy videó https://www.youtube.com/watch?v=ljZpWbuK68s
A loggolás pedig ennyi:
catch (Exception ex){Log.Error(ex, "Something went wrong. Részletek: {param1} {param2} {param3}", param1, param2, param3);}Ha nem teljesítmény kritikus az applikáció akkor a fenti séma jó is...
mindent átguglizok
abból semmit nem lehet tanúlni -
joysefke
veterán
válasz
kiskornel
#9319
üzenetére
szvsz:
-(A) vagy több overloadolt függvény dekalrációt használsz ugyanazzal a függvénynévvel, de különböző paramétertípusokkal , e.g.: void A (int, string, string); void A (int, object, object);
-(B) vagy egyszerűen object-ként deklarálod a különböző bemenő paramétereket és bent egy type-matching switch statementel eldöntöd a konkrét típust.-(C) gondolom tisztában vagy a generikus típus/metódusdeklaráció mikéntjével és nem erre lenne igazából szükséged:
pldpublic int Foo<T1,T2,T3>(int x, T1 p1, T2 p2, T3 p3){Console.WriteLine($"{p1.GetType()} {p2.GetType()} {p3.GetType()}");return x;} -
joysefke
veterán
Net api analyzer. Keress rá, rakd fel a VSre és futtasd le mindenféle net standard és net core targetekre, compatibility pack opcióval és anélkül.
Egyébként mit csináltál? Átraktad a target frameworkot 4.5 ről netcore 3.1 re és most futási időben kapsz hibát? Hogyan futtattad ezt eddig linuxon?
Amikor átállítottad a target frameworkot, akkor kellett compatibilitás csomagot feltenni?
-
joysefke
veterán
Mi az a fő indoka annak, hogy a(z elvileg még maintained) .Net xxx használata eretnekségnek minősül, és ami nincs Core alatt, az felejtős? Tehát mi az az ok, ami miatt a Core mindenképp használandó, más meg kerülendő?
Én inkább úgy fogalmaznék, hogy ha valami 3rd party packaget használsz, akkor ha az nincsen .Net Standard-re (lehetőleg max 2.0-ig) akkor az felejtős. Ha van, akkor az jó, mert egy esetleges net framework => net core át-targetelésnek nem fog útjában állni.Én semmilyen körülmények között nem használnék olyan 3rd party libet ahol nem látom azt, hogy az arra épülő kódomat át tudom változtatás nélkül emelni akkor is ha futtatókörnyezetet váltok alatta. (lépek frameworkről 4.X-ről Core-ra)
Ezzel párhuzamosan ha kódot írok próbálom úgy szervezni, hogy közvetlenül framework 4.x-et targetelő projekt(ekbe) minél kevesebb kerüljön és inkább átcsoportosítom olyan projektekbe amelyek netstandard2.0-át targetelnek.
-
joysefke
veterán
A Task-on már én is agyaltam, de amikor próbálkoztam, valahogy nem jött össze.
Tessék, ez így működik, gyakorlatilag semmit sem változtattam azon amit bemásoltál. (net framework 4.7.2 + ASP net core 2.1)
A Console.Readkey(). tartja életben a main thredet, az pedig közvetve a webservice-t. élesben nyilván a console.Readkey helyett valami olyan szerver metódusod lesz, ami sosem ér véget, ezáltal a backgroundban futó futó webservice is életben marad.
szerk (ne az IIS profillal futtasd)
public class Program{static Task _webService;public static async Task Main(string[] args){Debug.WriteLine("WebGUI Teszt");_webService = StartWebGui();Console.ReadKey();}static async Task StartWebGui(){var hostBuilder = new WebHostBuilder().UseKestrel().UseStartup<Startup>().UseUrls("http://localhost:808/").Build();await hostBuilder.RunAsync();}} -
joysefke
veterán
Mi lenne a proper way helyette?
Nem vagyok biztos benne (*).
De első körben én megnézném, hogy Program.cs.Main()-ben egy új meztelen Thread-et létrehozva és azon indítva a WebHost-ot, hogyan viselkedik a webserver. De én a Thredeket sem szeretem
* Ami miatt bizonytalan vagyok, az az, hogy hogyan akarjuk/tudjuk kezelni a webservice esetleges chrashét. (egyáltalán akarsz-e ezzel foglalkozni):
Ha a background thread (ami a webservert futtatja) crashel (kezeletlen exception jön belőle) akkor érdemes lenne ezt az exceptiont valamilyen szinten elkapni, loggolni és vagy újraindítani a szervert vagy inkább az egész alkalmazást leállítani. Ez az egész opcionális, de alapvetően nem egészséges megadni az esélyét hogy egy bármilyen threadben kezeletlen exception ragadjon.
Ahogy nézem a BackgroundWorkeren van egy erre használható event: "RunWorkerCompleted" , az eventargs pedig: "RunWorkerCompletedEventArgs" ennek pedig van egy Error propertyje ami az esetlegesen elkapott exceptiont tartalmazza...
Ha Threadben gondolkodsz akkor jó pár alternatív opciód van amit mérlegelhetsz.
De én valószínűleg Task-ként futtatnám a webservert. A te esetedben nyilván az volt a "baj", hogy a WebHost.RunAsync() metódus által visszaadott Task-ot azonnal awaitelni akartad a fő száladon, így a fő programszál nekiállt async várakozni a Task elkészültére, ami ugye egy szervernél amíg le nem állítják nem fog megtörténni.
Ha a fő programszálad amúgy sem lép ki magától akkor szerintem a a WebHost.RunAsync() által visszaadott Task-ot sem kell nekiállnod awaitelni benne (ha tudod, hogy exception történt akkor érdemes) ettől függetlenül a viszakapott Task refernciáját nyilván elmented, hiszen ezen keresztül mindig tudod ellenőrizni az állapotát és szükség szerint awaitelve ki is tudod belőle szedni az esetleges exceptiont.
A fenti példában például a Console.ReadKey() blokkolja a fő szálat. Amíg a fő szál nem ért véget, addig a background threadeket (beleértve amelyek Task-ba vannak csomagolva) a runtime nem zárja be addiíg amíg azok nem fejezik be maguktól a futást.
-
joysefke
veterán
és ezek a sriptek amelyek átmennek ezen a security checken, ezek digitálisan alá vannak írva és a futtatókörnyezet meg is tíltja a nem aláírt scriptek futtatását, vagy a managerek szerint minden ami sript az biztonságos, minden ami bináris az nem (akkor is ha a saját tool- fejlesztőik írták)?
-
joysefke
veterán
Szeretném használni a személyes fejlesztési keretemet könyvvásárlásra. (Pluralsightom már van)
-(1) ASP Netcore.
Itt a Pro asp net core 2-t olvastam Adam Freeman-től pár éve, az anno nekem nagyon hasznos volt, de ahogy néztem nem nagyon újítja fel a példaprojektjeit, tehát szeretnék mást, most valami advancedebbet.-(2) EF Core, Adatbázis, adatmodellezés témákhoz az aktuálisak közül melyek a legjobb könyvek?
-(3) Blazor / webassembly van már annyira stabil, hogy megérje kicsit beleásnom magam?
Ez utóbbi max érintőlegesen érdekel, de valamire el kell költeni a pénzt -
joysefke
veterán
válasz
martonx
#9248
üzenetére
Hát én a helyedben Asp.Net Core 2.1-el állnék neki
Végül az lesz.
Ugyanakkor nem értem, hogy miért erőlteted a netstandard2.0-át. .Net 4.7.2 netstandard 1.x-ig jó, én a meglévő komponensek esetében megelégednék netstandard 1.x-el, amit viszont zokszó nélkül tud használni a .Net Core 3.1 is.
A netstandard2.0-t a Core 3.1 és a net472 is ,egvalósítja. Semmit nem nyernénk, ha 2.0 alatti standardot próbálnánk targetelni, csak saját dolgunkat nehezítenénk meg.
A konvertálás úgy fog zajlani, hogy projektről projektre (levelekkel kezdve amelyeknek nincs dependenciája másik saját prokjekt felé) egyenként át lesz állítva a csproj formátum modernre (SDK style és package reference) a <TargetFramework> property pedig net472-től netstandard2.0-ra. Mivel a netstandard2.0 API szűkebb API mint a net472 ezért lesznek olyan hívások amit ki kell szervezni vagy ki kell vágni vagy helyettesíteni kell mással, mert nincsen standardes megfelelője. Minnél alacsonyabb standardet próbálnánk targetelni, annál nehezebb dolgunk lenne, mert annál több frameworkos API-nak nem lenne standarden megfelelője. Így is nehéz dolga lesz annak aki csinálni fogja, már volt egy nekifutás...
A saját új class library projekteknél pedig azért nincsen értelme netstandard2.0 alá targetelni, mert az összes futtatókörnyezet ami képben van (jelenleg a net472 és később meg valami core-latest) megvalósítja a standard2.0-t.
-
joysefke
veterán
El vagyok veszve az ASP verziók és szuboptimális lehetőségek között, segítség kéne
Egy új ASP Web API projektet kell írni (REST, json). A saját már létező komponensek amiket kikerülhetetlenül használni kell, targetje Net472. Jó pár ezek közül nem konvertálható egyszerűen netstandard2.0-ra, és ezen adott idő alatt nem tudunk segíteni, ez már eldölt.
Az új az ASP web-projekt mellé készülő library komponensek targetje Standard2.0 lesz, ez a stratégiai irány. A régi komponensek is előbb vagy utóbb átvándorolnak standard2.0-ra, de ez nem most lesz.
Az ötlet az, hogy használunk "valamilyen" .Net Framework 4.7.2+ -en futó ASP verziót, használjuk a meglévő saját frameworkos librarykat az újakat pedig standard2.0-ban gyártjuk. Aztán amikor alkalom adódik rá, az ASP projektet is migráljuk/lecseréljük a majdani legfrissebb ASP Net Core-ra.
Az ASP projekt alá jelenleg olyan kevés kód kerülne ami csak lehetséges, minden ami szükséges standard2.0-ás libraryba vándorolna, lehetőleg úgy hogy majd később asp net core alól változatlanul fel tudjuk használni.
=====
És akkor most tanácstalan vagyok, hogy nekem valami régebbi ASP NET Core-t kell nézni (ezek ha minden igaz 2.2-ig bezárólag tudtak futni Framework runtimen is, de erről csak olvastam) vagy valami legújabb ASP.NET 4.x -et Web API 2-vel??
Az ASP Net Core 2.x-ek ha minden igaz már end of life...
VS19 támogatásnak eléggé örülnék.
=====
Nézegettem a docs.mscom oldalt, de egyszerűen nem találtam jó táblázatokat...
-
joysefke
veterán
Nem értem hogy mi a probléma meg milyen token referenciáról beszélsz.
A token egy struct, ami tartalmazza az őt létrehozó CTS referenciáját. Te ezt nem látod, mivel a token structon a cts-re mutató referencia nem publikus. (pont ez a pattern lényege, hogy ne lehessen össze vissza cancellelni csupán a cts birtokában)
A cancel pedig kétféle módon propagálódik:
1, Te manuálisan a saját magad függvényében ellenőrzöd, hogy történt-e cancel:
bool token.IsCancellationRequested vagy
void token.ThrowIfCancellationRequested()2, Valamelyik framework API akinek Task létrehozásakor átadtad a tokent ellenőrzi a token állapotát és saját maga rakja az általa felügyelt Task állapotát Cancelled-re. A TaskFactory gondolom egy ilyen valami. (nem ismerem a TaskFactory-t)
-
joysefke
veterán
A TaskFactory-val van a problémád vagy magával a CancellationTokenSource => CancellationToken mechanizmussal?
A cts -token egy távirányítós bomba. A bomba a Token a távirányító pedig a CancellationTokenSource. a kliens kódnál a távirányító (CTS) és a távirányítóhoz tartozó bombát átadja a hívott metódusnak a Token formájában. Te mindig a CTS-t hozod létre konstruktorral, a Tokent a CTS propertijeként kapod meg.
Amikor megunod a várakozást, robbantod a bombát a távirányítóval.
A példakódot lefuttattam, ott ha AggregateException jött jelzi azt, hogy a CTS-en meg lett hívva a cancel.
-
joysefke
veterán
Úgy tűnik csak a topik halott, nem a .NET
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/
-
#9224
joysefke
veterán
Jokerpoker
#9222
joysefke
veterán
válasz
Jokerpoker
#9222
üzenetére
Ha a hosszra vagy kiváncsi (ami kódolástól függően nem feltétlenül egyenlő a karakterek számával)
https://docs.microsoft.com/en-us/dotnet/api/system.io.fileinfo.length?view=netcore-3.1 -
joysefke
veterán
Azure DevOps Pipeline vs Azure DevTest Lab custom VM-ek indítása leállítása pipelineból
Azure DevOpsban van egy projektem, ehhez tartozik egy Build Pipeline (YAML-formátumban). A build pipeline több stage-ből áll. Az első stage-ban egy standard Microsoft VM agent buildeli a kódot stb.
A következő stage már custom agenteket használ (funkcionális tesztek), ezeket a custom agenteket Azure DevTest Lab-ben hostolom és a DevOps-ban egy "Environment"-be vannak beregisztrálva. Ezeket a DevTest Lab-ben futó custom agenteket aztán a pipeleneból Deployment jobokkal managelem, osztok rájuk taskokat. (ez így szépen működik)
A kérdés az az, hogy hogyan tudnám a VM-eket a pipelineból powershell taskkal indítani leállítani.? Most nem nagyon érek rá kísérletezgetni, de tök jó lenne, ha ez is menne.
Gondolom maga az indítás leállítás valami Get-AzVM -Name *akármi* | Start-AzVM szerű dolog lesz, de az autoritzáció része nekem nem tiszta. Szóval csinált már valaki ilyet?
-
joysefke
veterán
ASP NET Core 3.1, WebAPI
RESTful projekt elején vagyok, előreláthatóan lesz jó pár kontroller/actionmethod, illetve már van url alapú verziózás is. A routing controller/action-method -attribútumokkal van vezérelve.
Szeretném unit-tesztekkel ellenőrizni, hogy egy adott request Uri-hoz a routing azt a kontrollert illetve annak azt az action metódusát hívja meg, amit én gondolok.
Erre van valami bevált egyszerű megoldás?
Előre is köszönöm a válaszokat
J. -
joysefke
veterán
válasz
petyus_
#9152
üzenetére
ha nyilvántartod a lezárt és nyitott éves-havi-heti-napi egyenlegeket, akkor egy esetleges visszamenőleges számlafelvétel kizárólag attól a dátumtól ahová beszúrtál tenné szükségessé a nyitott egyenlegek újraszámolását. 3 hétnél ez nem tűnik túl soknak.
egyébként egy lehetséges sebesség növekedést okozna, ha szegmensfa jellegű struktúrában tárolnád el a számlák intervallumokra levetített egyenlegeit. Ide O(logN) a beszúrás és O(logN) az összegzés költsége. Tehát lényegesen gyorsabb mint egy sima intervallum-összeg adott indexig típús adatstruktúra ahol egy közbenső beszúrás költsége ~logN
-
joysefke
veterán
válasz
martonx
#9104
üzenetére
Mert nem tudom, hogyan/milyen alapon oldjam meg az inter-processz kommunikációt ha a REST-szervíz külön processzbe kerülne. A REST szerviz nem írhatja/olvashatja közvetlenül az adatbázist/adatbázisokat az összes hozzáférésnek mindenképpen keresztül kell mennie a jelenlegi alkalmazás logikán, ez elvárás.
Illetve akárhogy is lenne ez, ehhez mindenképpen hozzá kell nyúlni az apphoz (mivel a legacy interfészt nem használhatom), ezért gondoltam, hogy ennyi erővel akár egyből az applikációba bele lehetne rakni a REST szervízt.
Egyébként nem hiszem, hogy késleltetés/throughput szempontjából a kommunikáció túlságosan kritikus lenne (ha az lenne, akkor már a külső REST interfész is problémás lenne).
Tehát ha útba tudsz igazítani, hogyan oldjam meg minimális invázióval, hogy az applikáció a külön processzben futó REST-szervizzel tudjon kommunikálni, annak örülnék
Meg minden ötletnek ami jobb mint a jelenlegi. -
joysefke
veterán
Sziasztok, szeretnék inputokat gyűjteni meg hátha segít ha leírom a gondolataimat.
Van egy nagy alkalmazás amelynek a fejlesztésébe (elsőként) belecsöppentem, további szerencsések majd csatlakoznak. Az én feladatom viszonylag beláthatónak tűnik: RESTful Api-t kell írni az alkalmazás által managelt objektumok lekérdezéséhez és módosításához. A távlati terv az, hogy ezzel a Rest-Apival kiváltsák a meglévő legacy interfészt amit a kliensek használnak.
A megvalósítandó REST-interfész Swagger szinten már kb definiálva van, nekem "csak megvalósítani" kell, vagy legalább érdemben elindulni az úton és kompetencia benyomását kelteni. A megvalósításhoz én minél kulcsrakészebb technológiát akarok használni, ahol minél több HTTP/REST/Auth dologhoz van gyári támogatás. Szóval ASP Core API projekt lebeg a szemem előtt. A fő kérdés az, hogy ezt hogyan fogom a jelenlegi monstrumba beleintegrálni anélkül, hogy közben újra fel kéne találnom a csillagrombolót vagy esetleg a kőbaltámmal tönkretenném az említett csillagromboló belső huzalozását miközben hozzápatkolok egy oldalkocsit.
Az alkalmazás kifejezetten sokat látott már és bonyolult, Microsoft technológiák és irányzatok állatkertje, a világon keresztülmigrált fejlesztéssel. Az alkalmazott technológiák többségéhez nem értek. Az alkalmazás számomra lényegi része .Net 4.7.2-n van jelenleg.
Az alkalmazás által nyilvántartott entitások adatmezőinek egy része csatlakoztatott MS-AD-ból származik, másik része pedig az alkalmazás saját SQL-szerveréből, amely kiegészíti az AD-ban tárolt adatmezőket (az AD-s sémát kiegészíti az SQL-ben tárolt séma). A kettőnek mindig együtt van értelmeKifejezetten nem cél és nem kívánatos, hogy a fejlesztendő REST szerviz közvetlenül a jelenlegi, alkalmazáslogikát megkerülve, hozzáférjen az adattárhoz (AD + SQL szerver) és onnan próbáljon meg adatokat visszaadni vagy oda írni.
A meglévő legacy interfész (amit ki akarnak váltani) használata, illetve hogy annak a funkcionalitását egy REST interfész mögé rejtsem nem kívánatos, hiszen így bebetonoznám a legacy interfészt (továbbra is karban kéne tartani).
Ha eltekintünk ettől a legacy interfésztől, akkor én úgy gondolom (nincs megerősítve, de erős a gyanúm), hogy nincsen az alkalmazásban másik interfész amihez a REST-szervízt külön processzként futtatva hálózaton (vagy localhoston) keresztül tudnék csatlakozni a Rest-szervíz leendő belső interfészével és onnan le tudnám kérdezni az adattárat. Tehát úgy gondolom, hogy mindenképpen hozzá kell nyúlnom az alkalmazáshoz és az alkalmazással azonos processzen belül -de külön threaden- kell fusson a REST-szervíz.
A leendő architektúrára a jelenlegi legjobb működőképesnek gondolt ötlet a következő:
Az alkalmazás két példányban fog futni:
-(1) Az első példány a jelenlegi REST nélküli verzió lesz aminek a legacy interfészére csatlakoznak a legacy kliensek. Ehhez nekem nem lenne közöm.
(2)A második példány az applikáció REST-szervizzel kiegészített változata lenne, ehhez a változathoz nem fognak csatlakozni legacy kliensek és a legacy interfésze nem lesz aktív használatban. Ez a második példány ugyanahhoz az AD-hez és ugyanahhoz a logikai SQL szerverhez fog csatlakozni mint az első példány.Egymással párhuzamosan írják/olvassák az adatbázisokat.
Ez már jelenleg is működik és nálam hozzáértőbb emberek úgy gondolják, hogy nem fognak összeakadni az egyes alkalmazáspéldányok (már ma is van HA konfiguráció közös replikált SQL adatbázissal és közös AD-vel).Ezt a második, REST-tel kiegészített példányt kellene most összehozni.
Az ötletem az, hogy a REST API egy ASP .NET Core 3.1 projekt lenne amelyhez tartozó ASP WebHost objektumot az applikációból (annak a belépési pontját megkeresve) egy külön Thread-en indítanám el, az pedig a megadott porton fogadná a kéréseket.
A REST-szervíz belső fele pedig az appnak azokat a (megtalálandó) .NET -es objektumait használná mint kliens ahová jelenleg a legacy interfész is csatlakozik. Hogy ez mennyire jól behatárolható azt még nem tudom. Gondolom ezekhez az objektumokhoz írni kéne majd valami wrappert ami ezeket mint ASP-kontrollerbe injektálható szervízt fogja átadni.
Valami észrevétel?
Előre is köszi!
J. -
#9072
joysefke
veterán
sz.balazs.95
#9071
joysefke
veterán
válasz
sz.balazs.95
#9071
üzenetére
A suliban elkezdtünk WindowsForms-szal foglalkozni
ha már valamire a szabadidődet fordítod, akkor miért nem inkább a WPF-re?
-
joysefke
veterán
EF Core vs Generikus repository/UoW + eager loading child-of-child property /.ThenInclude()/
Hogyan kell EF Core-val generikus repositoryt illetve UnitOfWorkot csinálni?
EF4-hez találtam jó tutorialt:
https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application#implement-a-generic-repository-and-a-unit-of-work-classItt a generikus repo lekérdező metódusai paraméterként elfogadnak egy stringet is, amely az eager-loaded property-k neveinek egymástól vesszővel elválasztott listáját tartalmazza. A lényegi rész itt van, ez éppen egy Get-metódus:
public virtual IEnumerable<TEntity> Get
(...,string includeProperties = "")
{ IQueryable<TEntity> query = dbSet; ... foreach (var includeProperty in includeProperties.Split (new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries)) { query = query.Include(includeProperty); }Többek között ezt szeretném EF-Core3-ra átportolni. A problémám az, hogy EF Core-ra (úgy általában) nem találtam megoldást, hogy a gyemek property-k gyermekeit (és esetleg azoknak a gyermekeit) is betöltsem a generikus lekérdező-metódusban anélkül, hogy a hívó félnek EFCore-dependenciát adnék.
Pld egy N-N táblarelációt hogyan kezeljek? EF Core-ban ugye több-több kapcsolathoz kell egy join table (EFC-ben join entitás). A MS-os pédánál maradva lesznek nekem Student, StudentCourse és Course entitásaim. Mi van ha én a Student entitáshoz nem csak a StudentCourse entitásokat, hanem a Course entitásokat is be szeretném tölteni?
Meg lehet ezt értelmesen oldani?
Workaroundként, ha csak a childokat csak első ízig töltöm be (vagy első ízig SEM), akkor ha a lekérdezéseim a kliensnek IQueryable<TEntity>-t adnak vissza, akkor a kliens kedvére LINQ-joinolhat és a JOIN/lekérdezés még mindig az SQL Serveren hajtódik végre.
Vélemény?
-
joysefke
veterán
válasz
t-shirt
#9050
üzenetére
Van egy "DB Browser for SQLite" nevű kis stand alone programocska, azzal tudsz belenézni a táblákba és módosítani őket.
Ha programból akarod lekérdezni az SQLite adatbázist, akkor Entity Framework Core-hoz van SQLite provider. Neten fogsz találni a kapcsolódáshoz/használathoz példákat.
Én anno mikor kb egy éve használtam SQLite-ot, azért voltak limitációi: Mindenféle dátumkezeléssel nagyon megszenvedtem.
-
joysefke
veterán
Regisztrálsz ingyen egy accot Azure -ra. Azt hiszem kapsz még valamennyi kreditet -talán 200$-t- amit 30 nap alatt lehasználhatsz. Kredittől függetlenül meg tudod nézni, ki tudod próbálni, hogy hogyan működik.
Nem teljesen értem, hogyan kapcsolódik a ASP.NET+web forms-hoz.
Web formssal nem próbáltam (Csak ASP NET Core appal). Alapvetően úgy működik, hogy mondjuk Visual Studioból feltöltöd az appodat egy Azure AppService konténerbe (ez egy opció) azt minimálisan bekonfigurálod és működik. Igen, ez az Azure valamelyik adatközpontjában fog futni.Kis időbefektetéssel el tudsz jutni egy olyan pontra, hogy lásd működik-e, és hogy mennyibe fog kerülni. Jobban jársz ha te magad próbálod ki, minthogy távolról próbálod megszakérteni.
-
joysefke
veterán
válasz
FurrierX
#8944
üzenetére
Ha ez a félévi házi, akkor megérdemelheti, hogy seggelj rajta 1-2 napot.
A három vonalnak vagy egyetlen közös állomása, vagy pedig az 1.-2.-nak és a 2.-3.-nak külön átszállási helye van
A feladatleírás segít: kétféle topológia lehetséges (nem mintha általánosan nem lehetne megoldani -Dijkstra-).
Az adatok alapján eldöntöd, hogy a kettő közül melyik a tényleges topológia. Innentől kezdve tied a döntés, hogy szép vagy favágó megoldást adsz a feladatra:
A szép megoldás az lenne, ha felépítenél egy gráfot amit a vonalakat modellezi majd ezen a cél és a kezdőállomás között megkeresnéd a legjobb (mivel a feladat szerint ez körmentes ezért egyetlen) utat, a szükséges plusz infókat (átszállás) pedig a gráfból útkeresés közben nyernéd ki...
A favágó megoldás pedig az, ha mindkét lehetséges topológiához (csillag és metsző) elkészíted a logikát (csomó if-else) ami a topológia, vonalak és állomásnevek ismeretében megmondja, hogy melyik vonalról melyik vonalra hol fogsz átszállni.
-
joysefke
veterán
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/
We’re excited to announce the release of .NET Core 3.0. It includes many improvements, including adding Windows Forms and WPF, adding new JSON APIs, support for ARM64 and improving performance across the board. C# 8 is also part of this release, which includes nullable, async streams, and more patterns. F# 4.7 is included, and focused on relaxing syntax and targeting .NET Standard 2.0.
.....
ASP.NET Core 3.0 and EF Core 3.0 are also releasing today.
Visual Studio 2019 16.3 and Visual Studio for Mac 8.3 were also released today and are required update to use .NET Core 3.0 with Visual Studio..NET Core 3.0 is part of these new Visual Studio versions. You can just get .NET Core by simply upgrading Visual Studio.
Sűrűek lehettek az utóbbi hetek Redmondban -
joysefke
veterán
válasz
sztanozs
#8902
üzenetére
Amiről beszélsz az egy extrém példa és azt feltételezi, hogy a munkafolyamatnak az adott "nem hivatalos" tool megkerülhetetlenül része lett, de szupport stb érdemben nem létezik rá. Tehát a valós munkafolyamat észrevétlenül(?) már annyira módosult, hogy a hivatalosan létező eszközökkel nem végezhető el (lol).
Nyilván elméletben idáig is el tudnak jutni a dolgok, de ehhez csoport szinten masszív vezetői hozzánemértés/elalvás kell. Ilyen szintű átalakulás nem egyik napról a másikra fog megtörténni. És ha megtörténik akkor ott már sokkal nagyobb bajok voltak, mint hogy egyszer Pisti aki összekendácsolta elment szabira. Pisti valószínűleg az évek alatt sokkal többet takarított meg a cégnek, mint amibe egy kis kiesés került. Csak ezt ugye hajlamosak vagyunk nem észrevenni.
Az extrém példával -ami valahol valamikor talán előfordul- szemben amit felhoztál viszont ott van a jelenlegi és egyébként mindennapos szituáció, hogy van valamilyen folyamat aminek lehetne érdemben növelni a hatékonyságát.
Ezt a lehetőséget pedig nyilván azok fogják először (és valószínűleg egyetlenként) észrevenni, akik benne dolgoznak, tehát nem a csapatvezető főnöke, nem is annak a főnöke, nem is a részleg vezetője, és nem a magyarországi helytartó, nem is a könyvelés, és nem is az IT, főleg nem ha ez Indiában van...
Tehát a kérdés az, hogy olyan vállalati struktúra és légkör van ami felkarolja az alulról jövő újításokat vagy legalábbis eszközöket és teret biztosít hozzá, hogy a csapatok megalkossák, módosításk a saját folyamataikat/eszközeiket. Vagy olyan a vállalati kultúra ami mindig csak fölfelé mutogat, panaszkodik de képtelen fejlődni és a kihívásokra megoldásokat szállítani.
Nekem meggyőződésem, hogy még ha van is fent akarat hatékonyabbá tenni a cég működését az alulról jövő kezdeményezések halmaza nélkül a fentieknek esélye sem lesz tudni, hogy lent igazából mire van szükség (vagy hogy egyáltalán mi történik a hierarchiában lejjebb)
-
joysefke
veterán
válasz
sztanozs
#8900
üzenetére
Ez a hozzáállás egész jó addig, míg be nem kopogtat az audit (vagy amíg el nem megy a "jóképességű" fejlesztő és a kollégák support nélkül maradnak).
Ezt nekik kell tudni. Ha mindig minden csapat arra várna, hogy majd fölülről biztosítanak/megoldanak mindent, és olyanoktól várná a segítséget akiknek egyébként fogalma sincsen az egyén vagy a csoport munkájáról, szükségleteiről, akkor a béka segge alatt lenne a termelékenység.
Ha a fejlesztő a csapat büdzséjéből kap órakeretet, hogy fejlessze a csapat toolingját, akkor értelmes elvárás az, hogy módosíthatóra, bővíthetőre csinálja -hosszabb életűre tervezi-, és ha elmegy, akkor valakinek aktívan átadja a fejlesztést. Ez a valaki nyilván ugyanabból a csapatból -az eszközt használóékból- kerül ki.
Ha a fejlesztő önszorgalomból csinálja, saját produktivitását növelendő (meg nyilván tanulni) akkor nyilván lesz amilyen lesz, működik ahogy működik, sok elvárás nem lehet vele szemben. Ha nagyon hiányos a tooling akkor ebből úgyis tanulópénz lesz majd valaki következő próbálkozáshoz...
Nekem jó tapasztalataim vannak azokkal a cégekkel ahol az IT nem belső ellenségként tekint a felhasználókra és csoportokra akiknek a jogkörét a szükséges abszolút minimumra kell csökkenteni.
-
joysefke
veterán
válasz
martonx
#8895
üzenetére
Úgy hogy már mindenki a böngészőből elérhető adatokhoz -kivéve office- szokott, kissé ósdinak tűnik egy weblink helyett egy file store elérést megosztani egy futtathatóhoz, ami nyilván minden alkalommal szépen letöltődik a user gépére hogy azon elinduljon.
Ha ezen túllépünk, akkor most hogy a Core framework új 3. verziójával elérhető lesz a self contained opció illetve jelentősen visszanyesik a self contained package méretét illetve a Core 3 már támogatni fogja a Windows desktop appokat, végül is nem olyan elvetemült opció ez:
Egy pár 10MB-os self contained app aminek nincsen dependenciája a futtató gépre installált .NET környezet felé az kb nem romlik el míg világ a világ, míg a másik oldalon a böngészők is változnak ez pedig elronthatja a felhasználói élményt.
-
joysefke
veterán
A poén az hogy mégis működik, kipróbáltam.
Lehet hogy a bejegyzés óta eltelt majd két évben meggondolták magukat...Sőt, egyelőre jobban működik mint a Choose/When -féle megoldás, mert ott a package upgrade csak a csomaghoz tartozó legelső verziószám bejegyzést módosítja, míg a másikban az egyetlen verziószám-bejegyzés szépen módosul.
-
joysefke
veterán
Köszi a tippet!
Lehet kipróbálom ezt is, de amikor keresgéltem, ráakadtam erre:
https://github.com/NuGet/Home/issues/5895itt meg azt írták, nem fogják megoldani, aztán valahol a hozzászólások között találtam azt a megoldást amit feljebb írtam is!
-
joysefke
veterán
válasz
joysefke
#8864
üzenetére
Lehet megoldódott
Úgy tűnik, csak le kell írni egy problémát és az jó eséllyel megoldódik, mielőtt jönne az első hsz. Egy csomót próbálkoztam VS-ben az ilyen olyan Android kapcsolókkal (amelyek ki tudja mit csinálnak), ehhez képest a megoldás igen kézzelfekvő:
1,
Minden kód ami a kérdéses komponensben van#if !GOOGLEPLAY
...
#endifközé került. Ezzel a GOOGLEPLAY szimbólumot tartalmazó build konfigok esetében semmilyen aktív kód nincsen ami használná a YoutubeExplode csomagot.
2,
Mivel a YoutubeExplode csomag bizonyos buildek esetében nincsen használatban, ezért el is lehet távolítani a csomag-referenciát, ehhez a .csproj fájlban a Choose/When/Otherwise konstrukciót lehet használni. Alább látszik, hogy a kettő Gplay-es konfigban (GooglePlayRelease és GooglePlayDebug) nincsen referencia a YoutubeExplode NuGet csomagra, a többi nem GPlay-es konfigban viszont lesz..És ez így fordul szépen, és ha ILspy-jal belenéze, tökéletesen semmi nyomát nem látom a YoutubeExplode-nak...
<Choose>
<When Condition=" '$(Configuration)'=='GooglePlayRelease' ">
<ItemGroup>
...
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='GooglePlayDebug' ">
<ItemGroup>
...
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
...
<PackageReference Include="YoutubeExplode" Version="4.7.9" />
</ItemGroup>
</Otherwise>
</Choose> -
joysefke
veterán
Xamarin.Forms - GooglePlay
Help kéne, sok időt beleöltem, nem boldogulok...
-(0)
Van egy Xamarin.Forms(Android) hobbiprojektem. Ez a projekt tartalmaz egy általam írt komponenst "YtExplodeVideoService" néven amely a YoutubeExplode nevű 3rd party NuGet parser libre épít. A YoutubeExplode működése okán nem GPlay policy kompatibilis, ennek megfelelően a "YtExplodeVideoService" komponens sem az.A XF projekt shared része egyetlen projektben, egyetlen assembyben van, ez tartalmazza az általam írt kód 99%-át.
Eddig minden szép és jó és működik is.
Most szeretném, ha fel tudnám rakni az appot a GPlay-re is, anélkül, hogy terminálnának engem, a családomat, a macskámat meg úgy mindenkit akihez közöm van.
Amit eddig csináltam:
-(1)
A "YtExplodeVideoService" mellé készítettem egy azzal interfész-kompatibilis komponenst "VanillaYtVideoService" néven. Ez megfelel a GPlay feltételeinek, ennek a használatáért nem fognak kivágni.-(2)
Készítettem az eddigi (ad hoc) Release solution-konfiguráció mellé egy GooglePlayRelease solution- konfigurációt. Ahol is a shared project konfigja tartalmaz egy compilation változót, ami megjelöli mint GPlay release.A videokomponens példányosításakor ellenőrzöm a változó értékét és annak függvényében választom ki a konkrét implementációt:
#if GOOGLEPLAY
VideoService = new VanillaYtVideoService(Settings, CachedSearchClient);
#else
VideoService = new YtExplodeVideoService(httpClient, Settings, CachedSearchClient);
#endifEz eddig szépen működik. ILSpy-jal belenézve a különböző build konfigurációkkal készített assemblikbe szépen látszik, hogy mindig a megfelelő komponens példányosodik.
A probléma:
Szeretném elérni, hogy
1, az elkészült GPlay-re szánt APK-ban, semmi esetre se legyen benne a YoutubeExplode.dll assembly, jelenleg, ha az APK-t kizippelem, akkor szépen ott van. Nem értem, hogy mit keres egyáltalán ott...2, A shared projektem assemblyjébe ha ILSpy-jal belenézek, akkor a references listában szépen látom a YoutubeExplode nevet. Ezt sem szeretném.
Szeretném, ha az elkészült projekt-assemblyben majd a végső APK-ban semmiféle ráutaló nyom nem lenne a YoutubeExplode-ra. Nem hiszem, hogy ez nagy kérés lenne, hiszen nem is használom a GPLay-re szánt releaseben.
És szeretnék biztosra menni, minél kevesebb mókolással.
3, Hogyan tudom biztosan ellenőrizni azt ami felkerül, hogy mindenben megfelelő?
Amivel eddig próbálkoztam:
1, A Linking opció Sdk Assemblies Only-ra van állítva. Ha egyel erősebbre rakom, akkor runtime hibáim vannak. (Első körben a Newtonsoft.Json-nal ütközik, de ha ezt kiküszöbölném lenne más)
Ha lehetséges nem bántanám ezt a beállítást, mert nem értek a linker konfigurálásához és félek, hogy olyan helyeken hozna be runtime hibákat, ahol nem is számítok rá.
2,
Játszottam a "Code shrinker" beállításokkal, nincs változás.3,
Próbálkoztam az ingyenes "Dotfuscator Community"-vel. Ez átnevezi a függvények paramétereit, de pld az assembliket magukat nem.4, Nekiálltam a YtExplodeVideoService-t kiszervezni egy külön assemblybe, de ezt elvetettem, ha csak egy mód van rá, nem szeretném szétbarmolni "Az Egy Assemblyt". (eleve legalább három felé kéne essen, ahol a harmadik, közös assemblybe mindenféle interfészeket, modelleket ki kéne szerveznem ÉS a hálózatos kódot)
-
joysefke
veterán
A neve "Named arguments" az utóbbi C# verziók folyamatosan csiszolták, a lényege, hogy már fgv-híváskor nem csak a pozíciója, hanem neve alapján lehet egy paramétert azonosítani.
Hasznos, hogy ha sokelemű a paraméterlista, akkor tudod, hogy mi micsoda, a másik pedig az, hogy át tudod rendezni az argumentumok sorrendjét a deklarációhoz képest.
Szerk: és ahogy feljebb írták, default értékkel rendelkező paraméterek esetén is jól jön.
-
joysefke
veterán
Nekem úgy tűnik, hogy
1,
te sessionöket és ezen keresztül szerver -> kliens irányú nyitott NAT-portokat akarsz fenntartani, hogy push üzeneteket küldhess (szerver-> kliens).2,
A két szervered közül gondolom az egyik az valami frontend a usereknek, a másik pedig a backend. A FE és a backend között (nyilván?) nem lesz NAT, és a backend szerver bármikor elérhető a frontended számára.Szerintem az 1,-hez valami külön real time framework kéne, ami kezeli a push üzeneteket. Kell legyen ilyen ASP-hez is.
A 2,-es feladat teljesen más, azt nem is mosnám össze az 1,-gyel.
-
joysefke
veterán
válasz
dudikpal
#8796
üzenetére
Freeman A. - Pro ASP.NET Core MVC 2 (2017)
A fentit kb 1/2-3/4 évvel ezelőtt rágtam át. Nem sok közöm volt előtte az MVC-hez, de a könyv jól felépített, logikus és általában nem éreztem azt hogy rabolná az időmet.
Viszonylag problémamentesen tudtam követni a példákat, az egyedüli komoly nehézség emlékeim szerint az Identity Management-tel foglalkozó fejezetek voltak, amit a könyv írása óta részben átdolgoztak, ezért nem tudod módosítás nélkül átemelni azt, ami példakód az érintett fejezetekben van.
A félkész webshop példa ami a könyvben van némi magyarázattal (és kevés screenshottal) kb 130 oldal. Ebben csak abszolút minimális kliens oldali kód van (Bootstrap + minimális custom JS). Egyébként sem tesz a könyv semmilyen erőfeszítést egy JS-gyorstalpalásra, én ezt előnyként éltem meg, arra nyilván van más anyag, a szerző csak minimálisan kalandozik el szerver oldalról.
Cserében ahogy végigvezeti a (félkész) webshop demót minden új funkcióhoz elkészíti a unit teszteket is.
Azóta sok víz lefojt a Dunán, de a könyv szerintem még mindig jól használható.
-
joysefke
veterán
Igen komoly munka folyhatott az utóbbi időben a .net csapatnál. Egy csomó minden gyorsul, van ami jelentősen.
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/
-
joysefke
veterán
Hali!
nem teljesen értem, mit szeretnél csinálni, vagy a kód amit beszúrtál mit csinál, de a következő észrevételeim lennének:
1,
if (holnap+1=1)ide szerintem == operátor kéne, nem értékadás. Egyáltalán miért nem kapsz itt hibát, hiszen az értékadás bal oldalán nem változó áll
2,
Az if( ) feltételeid egymást mind kölcsönösen kizárják, tehát nem fordulhat elő, hogy egyszerre kettő if-törzsbe belépsz.Sokkal átláthatóbb lenne a kód, ha
if(A) {..}
else if (B) {...}
else if (C) {...}
else {}konstrukciókat használnál.
Sőt, ilyen helyzetben én inkább egyből switch statementet használnék, ami a
holnapváltozódtól függően csinálna valamit (adna értéket a listaelemeidnek )3,
Ha ki akarod kerülni ezt a "hét napja" enum-aritmetikát /ami vonzza a hibákat mint a mágnes/, akkor az első dolog ami nekem eszembe jut (persze nyilván vannak más, akár jobb megoldások is) készíteni statikus extension methodokat, amelyek kényelmessé teszik az életedet:
Pld:
public static class DayHelper
{
public static int DaysToMonday()
{
var today = DateTime.Today.DayOfWeek;
var offset = DayOfWeek.Monday - today;
return offset >= 0 ? offset : 7 + offset;
}
public static int DaysToSunday()
{
var today = DateTime.Today.DayOfWeek;
var offset = DayOfWeek.Sunday - today;
return offset >= 0 ? offset : 7 + offset;
}
public static int DaysToMonday(this DateTime date)
{
var day = date.DayOfWeek;
var offset = DayOfWeek.Monday - day;
return offset >= 0 ? offset : 7 + offset;
}
Stb stb stb
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine(DayHelper.DaysToMonday());
Console.WriteLine(DayHelper.DaysToSunday());
Console.WriteLine(new DateTime(2019, 4, 20).DaysToMonday());
Console.WriteLine("Hello World!");
}
}Innentől kezdve, ha hívsz a kódodban egy ilyet hogy:
DayHelper.DaysToMonday()
akkor visszaadja a hétfőig hátralevő napok számát. Ezt nyilván meg tudod csinálni a hét összes napjára.Ha pedig van egy DateTime típusú változód, akkor azon meghívva a DaysToMonday()-t visszaadja az adott dátumtól a hétfőig visszalevő napok számát. Pld:
Console.WriteLine(new DateTime(2019, 4, 20).DaysToMonday());Visszaadja hogy 20-i dátumtól kezdve mennyit kell aludni hétfőig.
-
joysefke
veterán
C# In depth 4th edition
Ez nem rég jelent meg, és a korábbi kiadásokról jókat olvastam, bár nem forgattam őket sosem. Én a 7.0-val kezdtem, ezért a C# 7 in a nutshell könyvet forgatom olvasmányos referenciaként ami azért még elég aktuális.
Tehát volt már valakinek a kezében ez a C# in depth 4? Mit tud adni a C# 7 in a nutshellhez képest?
Egy picit utánaolvastam és a szerző azt ajánlja, hogy az olvasó szekvenciálisan haladjon, ami egy kicsit bosszant, mert a fejezetek alapján az érdekes részek a végén vannak...
Üdv
J. -
joysefke
veterán
válasz
Froclee
#8758
üzenetére
Az async void-dal egy csomó helyen meg van kötve az ember keze.
Event handlerek tipikusan void implementációt akarnak, ott csak az async void jöhet szóba.
Most egy xamarin projekt van előttem megnyitva:
tipikus event handler:
private async void Trending_Clicked(object sender, EventArgs e)
{
await Navigation.PushAsync(new TrendingPage());
}Ez meg egy lifecycle override az ősosztályon, csak async void-ot fogad el
protected override async void OnAppearing()
{
base.OnAppearing();
await something(...)
}szóval én kerülöm ezt az async void dolgot mint a pestist a saját metódusaimban, de amikor az interfész rákényszerít, akkor mit tudnék mást tenni?
-
joysefke
veterán
válasz
Froclee
#8758
üzenetére
Azt elfogadom, hogy az async void Dispose() nem működik úgy ahogyan én azt elvárnám
A compiler az IDisposable interfészre -és úgy általában minden void visszatérésű metódusra- figyelmeztetés nélkül elfogad egy async void implementációt.
Ez fordul és fut (C# 7.1+):
using System;
using System.Threading.Tasks;
public interface iface
{void func1(int delay);
Task func2(int delay);}
class Program : iface
{
static async Task Main(string[] args)
{
Program p = new Program();
Console.WriteLine($"starting {nameof(p.func1)}");
p.func1(3500);
Console.WriteLine($"{nameof(p.func1)} started");
Console.WriteLine($"starting and awaiting {nameof(p.func2)}");
await p.func2(2000);
await Task.Delay(3500-2000 + 500);
}
public async void func1(int delay)
{await Task.Delay(delay);
Console.WriteLine($"Hello from {nameof(func1)}");}
public async Task func2(int delay)
{await Task.Delay(delay);
Console.WriteLine($"Hello from {nameof(func2)}");}
}A
p.func1()hívás nem await-elhető, de működik raja az async keyword, a func1 implementációján belül a compiler kulcsszóvá alakítja az await-et és a func1-en belül awaithelhetőek lesznek az async metódusok. A példában a func1 törzsében a végrehajtás előbb bevárja a Task.Delay()-t és csak aztán ír a konzolra.Szóval ez az async void dolog minden hibájával együtt nagyjából működik.
Ezért nem értem, hogy az xUnit-ban egy async void Dispose hívásban a végrehajtás a Dispose metódus törzsében miért hagyja figyelmen kívül az await kulcsszót, elindítja a Task-ot amit kiadtam neki, de nem várja be
.. . -
joysefke
veterán
válasz
Froclee
#8750
üzenetére
async void-ot soha tobbe ne tegyel egy mondatba.
Ezzel tisztában vagyok, sokat olvastam már az async-ról, tudom, hogy ha van választási lehetőség akkor async Task visszatérést kell használni void helyett.
De egy csomó szituációban ahol egy interfész egy metódust void visszatéréssel deklarál nem tudsz Task visszatérést implementálni. Pld az IDisposable nem fogadja el a Task visszatérést.
A linket köszi, megnézem!!
-
joysefke
veterán
xUnit Dispose vs Async hogyan?
Sziasztok!
Nagyon új nekem ez az xUnit, tegnap kezdtem
és nem hiszem, hogy jól használom az Async metódusomatot a Dispose()-ban: működik, de nem teljesen azt csinálja a kód amit szeretnék/elvárnék...Az adott xUnit test class egy külső API interfészről történő lekérdezést tesztel.
Az xUnit osztály konstruktorában van a setup kódom, itt többek között kreálok egy
frisssessionId-t amitől a teszt végén mindenképpen meg kell szabadulnom.
A "megszabadulás" egy AsyncDeleteSession(string sessionId)hívás formájában kell megtörténjen, ezért ezt beraktam a teszt osztálypublic async void Dispose()metódusába.A problémám az, hogy a Dispose() metódusban a végrehajtás látszólag túljut az
await DeleteSession()-ön, ezt onnan látom, hogy a SessionId törlődik a külső rendszerből.
De a DeleteSession() utáni szinkron utasítások már nem hajtódnak végre.Itt a kód!
Osztály deklaráció, konstruktor és Dispose:
public class GetAccountDetailsTests : IDisposable
{
// Setup
public GetAccountDetailsTests(ITestOutputHelper output)
{
// csak a lényeg:
_getSession = hot task indul
}public async void Dispose()
{
// nem annak látszik, de ez SZINKRON, a Task már elkészült
var sessionId = (await await _getSession).SessionId;
_output.WriteLine($"Teardown: DeleteSession({sessionId}) called...");
// ez biztosan most indul és a külső szervizből látszólag
// törlődik a session tehát a lényegi dolgát elvégzi,
// NEM tud exceptiont dobni
// (elnyeli őket) kóddal jelzi ha hiba volt
var result = await _client.DeleteSession(sessionId);
// Ide nem jut el a végrehajtás, nem ír semmit az outputba
var code = result.HttpStatusCode.ToString();
_output.WriteLine($"Teardown: DeleteSession(...) returned with {code}");
}Teszt metódus belseje, try-catch-ben, hogy biztosan eljusson a Dispose-ig:
public async void WhenValidArguments_ReturnsAccountDetails()
{
// Arrange
var sessionId = (await await _getSession).SessionId;
// Act
var result = await _client.GetAccountDetails(sessionId);
AccountDetailsModel account = JsonConvert.DeserializeObject<AccountDetailsModel>(result.Json);
// Assert
Assert.True(result.HttpStatusCode == System.Net.HttpStatusCode.OK);
Assert.True(account.AccountName == _settings.AccountName);
}Nem tudom hogyan kéne értelmesen debuggolni a tesztet, hiába rakok a Dispose-ba breakpointot átugrik rajta amikor a VS "Debug selected test" opciójával indítom.
-
joysefke
veterán
Minimális programozás tudás nélkül ez nem fog menni...
Korábban egy betallózásról írtál. Feltételeztem, hogy a betallózott fájl útvonala van a pcpath változóban.
De neked még ilyen nevű változód sincsen. Nem értem honnan szedted
Első körben, hogy kiderüljön működik-e ez az egész, teszt jelleggel cseréld le a pcpath nevet egy létező nem túl nagy fájl útvonalára pld: @"\tmp\test.txt" . Ez lesz a PutFiles első argumentuma.
És ellenőrizd le, hogy ez a putfiles metódus ez fájl útvonalat is elfogad-e vagy mindenképpen mappa útvonal kell-e neki. Te betallózott fájlról írtál, de a példakódban az első arguáentum az könyvtár
-
joysefke
veterán
válasz
RedHarlow
#8707
üzenetére
Ha azt is kezelni akarod, ha a keresett szó esetleg többször előfordul a szöveg egy szavában (lalala - la, 3x)
akkor egészben a szövegen (beolvasod egy darab stringként) vagy soronként végigiterálsz és hívogatod astring.Substring(string, int, StringComparison)metódust amely mindig a keresett szó első előfordulásának indexét adja vissza. Minden egyes találat után növeled az offsetet (a második, egész szám paraméter) az előző előfordulás utánra addig amíg van találat. Az eredményeket számolod.Most hogy leírtam ez utóbbi nekem jobban tetszik mint a fenti.
-
joysefke
veterán
válasz
RedHarlow
#8707
üzenetére
én a következőképpen állnék neki:
-(1) Méretétől függően a fájlt beolvasod vagy egyben, vagy végigiterálsz rajta soronként.
-(2) Minden sort szétbontasz szavakra
string.Split(...)].A string.Split(...) -et úgy paraméterezed, hogy pontot-vesszőt-szóközt dobjon. (sokat nem számít, de gyorsítja a köv pontot)
-(3) Minden egyes szóra leellenőrzöd, hogy az adott szó tartalmazza-e a keresett szót:
string.Contains(string, string, StringComparision)Ha igen, növeled a számlálódat. Kisbetű-nagybetűt érdemes figyelmen kívül hagyni, illetve a regionális opciókkal is lehet esetleg játszani (nem tudom érdemes-e). Ehhez a StringComparison enum paramétert állítod be ahogy szeretnéd (ignore case legyen beállítva).
A módszer jól fog működni addig amíg nem akarod azt is nyilván tartani, ha a keresett szó többször szerepelt némely szóban. (lalala - la, 3x).
-
joysefke
veterán
válasz
martonx
#8687
üzenetére
A Petyus_ féle Usermanager.ChangePasswordAsync(...) tökéletesen működik, azt csinálja ami nekem kell. Nem értem, hogy kerülhette el a figyelmemet pont ez a metódus, amikor vS-ban böngésztem a UserManager interfészét...
8683 Petyus_
De a ChangePassword, amit írtam korábban, az belépett felhasználóra vonatkozik, oda csak egy oldPassword, newPassword kellKipróbáltam, nem szükséges feltétel, hogy belépve legyen a felhasználó akinek megváltoztatod a jelszavát.
-
-
joysefke
veterán
válasz
martonx
#8684
üzenetére
Mi a gyári default megoldás, mert én azt hittem, hogy az a default amit én csináltam...?
Egyébként nem a fórumra írogatással szoktam kezdeni8683:
Én is erre gondoltam. Startup-ban nincsen konfigurálva DI az IPasswordValidator-hoz, mégis visszaad egy valamilyen default validátor objektumot. Valószínűnek tartom, hogy ez a default validátor nem tartalmazza automatikusan a Startup.AddIdentity()-ben bekonfigurált pwd-requirementeket. Arra, hogy hogyan kéne csinálni viszont nem találtam példát (csak custom pwd-validátorra, azt viszont nem feltétlenül akarok) -
joysefke
veterán
válasz
petyus_
#8681
üzenetére
Nincs most vS a közelben, van bennem egy sör
1, egyetlen tranzakciót szeretnék, ha sikerül, akkor minden sikerüljön, ha nem sikerül, akkor semmi változás ne legyen. Attól függetlenül, hogy minden előre falidálva van
2, amit találtam fgv az valami email tokent kért paraméterként.
-
joysefke
veterán
.NET Core 2.1, ASP.NET Core 2.1 IPasswordValidator
Amikor kreálok egy usert, akkor a beállított password policy szépen alapján a kért jelszó erőssége szépen validálásra kerül,
azonban amikor meg akarom változtatni a beállított jelszót és a kért új jelszó erősségének validálásához a beépített default
IPasswordValidatorból (amit bár nem konfiguráltam DI-re, mégis valahogy működik a[FromServices]) kérek egy példányt és azzal próbálok validálni, akkor a validálás nem működik, bármilyen jelszó elfogadásra kerül.Startup.cs
services.AddIdentity<AppUser, IdentityRole>(
opts => {
opts.User.RequireUniqueEmail = true;
opts.Password.RequiredLength = 3;
opts.Password.RequireNonAlphanumeric = false;
opts.Password.RequireLowercase = false;
opts.Password.RequireUppercase = false;
opts.Password.RequireDigit = false;
})Kontroller
Usert így kreálom:AppUser newUser = new AppUser { UserName = model.Name, Email = model.Email };
IdentityResult result = await userManager.CreateAsync(newUser, model.Password);
if (result.Succeeded)
{
// safe to assume that the below operation will succeede
await userManager.AddToRoleAsync(newUser, "Admins");
return RedirectToAction(nameof(AdminUsers));
}És így szeretném megváltoztatni a passwordot:
Fügvény deklaráció, DI. Érdekes, hogy a Startup-ban én semmit nem rendeltem az IPasswordValidator-hoz
public async Task<IActionResult> Edit2(
[FromServices]IPasswordValidator<AppUser> passwordValidator,
[FromServices]IPasswordHasher<AppUser> passwordHasher,
EditModel model, string newPwd).....
Itt szeretném a jelszó erősségét validálni és ha megfelel megjelölöm, hogy updatelni akarom
IdentityResult passwordResult = await passwordValidator.ValidateAsync(userManager, userToEdit, model.Password);
if (!passwordResult.Succeeded)
foreach (var error in passwordResult.Errors)
ModelState.AddModelError("", error.Description);
else
passwordNeedsChange = true;Itt hajtom végre az IdentityUser updétjét:
if (ModelState.IsValid)
{
if (emailNeedsChange)
userToEdit.Email = model.Email;
if (passwordNeedsChange)
userToEdit.PasswordHash = passwordHasher.HashPassword(userToEdit, model.NewPassword);
var updateResult = await userManager.UpdateAsync(userToEdit);
....
}Előre is köszi!
#8679 Köszi!
-
joysefke
veterán
válasz
martonx
#8675
üzenetére
azzal illik tisztában lenni, hogy a futtató környezetek mindig kis lemaradásban vannak
Persze, a dolognak ez a része egyértelmű, és az ember nem is ugrik rá addig a legújabbra, amíg azzal nincsen tapasztalat. Jobb más kárán tanulni.
Ami nekem nem tiszta az, hogy ha az Azuron elérhető lesz egy újabb verziójú futtatókörnyezet, de az én projektem verzió lemaradásba került, akkor meddig tudom azt deployolni Azurra, illetve ha már van az Azuron egy nem utolsó stabil verziós futtatókörnyezetre támaszkodó appom, annak a függősége meddig lesz támogatva? Mikor húzzák ki a futó app alól a szőnyeget?
Különösen, ha "free tier" App Servicen vagyok, ahol nyilván shared VM-ek futtatják az appokat és gondolom nem fognak az én hobbi projektem miatt határozatlan ideig fenntartani egy kifutó futtatókörnyezetet.
Szóval, ha előbb utóbb szeretném békénhagyni a projektet és hagyni, hogy csak fusson magában, akkor nem jobb-e mégis csak "self hosted"-ként deployolni, még akkor is, ha egyébként tudnám közvetlenül futtatni?
üdv
J. -
joysefke
veterán
Sziasztok!
Van egy .NET Core 2.1 + ASP.NET CORE 2.1 Web app-om.
Nem túl nagy, én csináltam, és hozzá tudok/merek nyúlni. A célom az lenne, hogy1, egyrészt a legutolsó stable .NET Core + ASP.NET Core verzión tartsam, lehetőség szerint
2, lehetőség szerint mindig közvetlenül (ha lehet self contained opció nélkül) tudjam Azure App Service-ben futtatni.
Egy hónap után újra deployoltam az appot Azure-ra. Különböző okok miatt ezzel megint órákat sz**tam mire végül elindult Azuron. Az Azure hibaüzenetek számomra elég semmitmondóak. stb stb. A vége az lett, hogy most csak a self contained opcióval tudtam futásra bírni. Egy hónapja órák hosszat szívtam az Azure-val (ekkor láttam az Azure-t először) mire rájöttem, hogy ha a release targetet x86-ra állítom, akkor hajlandó lesz elindulni az app, itt még nem kellett neki a self contained opció
Azt lehet előre tudni, hogy a 2.1 -> 3.0 (stable) az egy közvetlen lépés lesz-e, vagy útba kell-e ejteni a .NET Core 2.2, ASP NET Core 2.2-t? Vagy bele kell nyúlni a kódba stb?
Elolvastam a 2.1->2.2 update instrukciókat és van benne rendesen manuális konfig fájl írás. Attól félek, hogy ha nekiállok a csomag verziókat kézzel editálgatni, akkor egy következő váltásnál megint szenvedéssel fogom Azuron működésre bírni.
Nyilván csinálhatok egy üres 2.2-es projektet és manuálisan átmásolhatok bele mindent, de az megint plusz munka.
.csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<UserSecretsId>9b4b6fbc-c156-49cb-9d78-15de78924438</UserSecretsId>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<Folder Include="Migrations\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="CsvHelper" Version="9.2.3" />
<PackageReference Include="FluentValidation" Version="8.1.1" />
<PackageReference Include="MailKit" Version="2.1.2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.2" PrivateAssets="All" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="2.1.4" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.1.8">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.1" />
</ItemGroup>
<ProjectExtensions><VisualStudio><UserProperties /></VisualStudio></ProjectExtensions>
</Project>Szerk:
Az sem tiszta, hogy a VS Installer miért nem ajánlja fel a 2.2-es SDK telepítését, miért kell azt VS-en kívülről telepíteni -
joysefke
veterán
Ahogy fent írtam, nem ismerem a SerialPortot, de ez a SerialPort.ReadLine() -a nevéből ítélve
- blokkol nem? Innentől kezdve a thread amihez hozzá van kötve IO-limitált.kódodnál nem azért nem fogja feleslegesen terhelni a CPU-t, mert áttetted a futását egy másik szálra
igen ezzel tisztában vagyok -
joysefke
veterán
válasz
t-shirt
#8656
üzenetére
Igen, az idő nagyobbik részében üresen pörög, okozhat ez gondot?
Az oprendszer nem tudja eldönteni, hogy egy programszál azért pörög maxon mert nem csinál semmit azon kívül, hogy egy üres ciklusban van, vagy azért mert tényleges dolga van. Pár ilyennel le lehet terhelni a gépet.Konzolos program esetében megoldható hogy várakozzon az eseményre anélkül hogy lefutna (kilépne)? Lásd pld. fent. ott a main thread bevárja a másikat mielőtt kilépne. Ha a main thread előbb végezne, akkor annak a kilépése a többi threadet is befejezné (konzol applikációban).
-
joysefke
veterán
válasz
t-shirt
#8654
üzenetére
Én úgy értettem a dolgot, hogy a gép kezdi az üzenetváltást, és a PC szemszögéből mindig
fogadás-írás-fogadás-írás stb a sorrend. Itt a PC a szerver és ha ezt a feladatot kiszervezed egy külön threadbe akkor nyugodtan lehet blokkolni azt a threadet a munkagépre történő várakozással. Persze ahogy fölöttem írták, nem ártana ide sem egy timeout...Ha blokkoló olvasással oldod meg a dolgot, akkor valahogy így nézhet ki a dolog.
(sosem volt serial portal dolgom és ezt amit válaszoltam sem tudom futtatni)Indítasz egy threadet amely minden munkacikus elején ellenőrzi, hogy szabad-e tovább futnia, ha nem, akkor rendezetten kilép. Olvas-ír-olvas-ír amíg el nem fogynak a fo_tomb-ből a parancsok.
A main() -thread nincsen blokkolva egészen a
serverThread.Join()-ig Ennél a pontnál bevárja a serverThread-et. ha a main()-en belül a serverThread befejezte előtt beállítod aserverAllowedToRun=false-ot, akkor az leállítja a soros-port threadjét.class Program
{
// dummy data
private static string[] fo_tomb = Enumerable.Range(0, 100).Select(x => "Machine command nr: " + x.ToString()).ToArray();
private static bool serverAllowedToRun = true;
public static void ComServer()
{
using (var port = new SerialPort("COM4"))
{
// ezek menjenek fgv-paraméterbe
port.BaudRate = 9600;
port.Parity = Parity.None;
port.StopBits = StopBits.One;
port.DataBits = 8;
port.Handshake = Handshake.None;
port.RtsEnable = true;
port.Open();
int n = fo_tomb.Length;
int i = 0;
while (serverAllowedToRun)
{
if (i >= n) break;
// ez a te 'mentes_valtozo' -d
// a PC olvasással kezd
// ez blokkol ameddig gép nem küld valamit amit a PC tud olvasni.
// nem pörgeti a gépet
string machineMessage = port.ReadLine();
// Ha a gép küldött üzenetet, akkor válaszolunk rá
port.WriteLine(fo_tomb[i]);
i++;
}
}
}
static void Main()
{
Thread serverThread = new Thread(ComServer);
// Érdemes lehet timeoutot megadni
// pld 10 perc: TimeSpan.FromMinutes(10);
serverThread.Join();
}
} -
joysefke
veterán
válasz
t-shirt
#8654
üzenetére
Amikor a
mentes_valtozo == nullakkor a main thread üresben pörög, teljes sebességgel. És nyilván ez a "normál" állapot, mert mind a soros port, mind a munkagép sebessége elmarad a processzorétól.Másrészt a mentes_valtozo statikus. Ha két thread is hozzáfér, akkor a hozzáféréseket szinkronizálni kell.
-
joysefke
veterán
Ehh, működik a reloadOnChange, és a dolog nyitja tényleg az volt, ami stackoverflow linken van.
Így már működik ez az egész felülírom a konfig-fájlt (egyetlen kis konfig fájlt, ami nem kritikus) és az abban tárolt konfiguráció újratöltődik dolog. nyilván nem adatbázisként érdemes használni.
Leírom hátha jó lesz valakinek. Én azóta már máshogy csináltam, de a példakód működik
config.json :
{
"config": {
"Name": "Bismarck",
"Registry": "NCC-1701",
"Class": "Constitution",
"Length": 500.0,
"Commissioned": true
}
}tartozik hozzá egy POCO modell class amibe beolvastatom a config.json-t.
public class Config
{
public string Name { get; set; }
public string Registry { get; set; }
public string Class { get; set; }
public decimal Length { get; set; }
public bool Commissioned { get; set; }
}Program.cs
WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.SetBasePath(Directory.GetCurrentDirectory());
config.AddJsonFile("config.json", optional: true, reloadOnChange: true);
})Ez a kritikus részlet:
Startup.cs
services.Configure<Config>(Configuration.GetSection("config"));Innentől kezdve működik nálam a reloadOnChange akár felülírom, akár csak egy value-t írok át benne kézzel.
Ha felül akarom írni, csinálok egy anonim típust amelynek az egyetlen property-je a megváltozott Config objektum. Ezzel a trükkel beírja az osztály nevét is a config.json-ba. (amire szükség van, mert key-ként használjuk)
var root = new
{
config = changedConfigObject
};
string newConfig = Newtonsoft.Json.JsonConvert.SerializeObject(root);
System.IO.File.WriteAllText("config.json", newConfig); -
joysefke
veterán
válasz
Froclee
#8643
üzenetére
Persze más kérdés, hogy ilyen célra valóban nem configot használunk, hanem valami adattároló repositoryt
Nem az appsettings-be hanem külön json-konfig fájlokba akartam rakni a változó (értsd tipikusan egyszer konfigurált) konfigurációs adatokat. Még ha valami hiba is kerülne bele, akkor sem történne semmi és nem rántaná magával az appot.
Az én esetemben az admin felületről beküldött a program által validált adat került volna bele ebbe a json-ba. Tehát attól nem kell félni, hogy valami hibás adat bekerül a konfigba, az app reloadolja és valami parsing exceptionnal elszáll valahol.
Konkrétan egy másik szerver-hez a kapcsolódási beállításokról van szó.
-
joysefke
veterán
válasz
martonx
#8641
üzenetére
Igen, én is arra jutottam, hogy nem működik és a legjobban akkor járok, ha SettingsModel <=Json=> settings.json alapon mentem le fájlba.
Ehhez képest a doksi azt mondja, hogy:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-2.1File Configuration Providers have the ability to reload configuration when an underlying settings file is changed after app startup. The File Configuration Provider is described later in this topic.
És ha megnézed, beállítottam a
reloadOnChangeflag-et.Mivel a Configuration nem tartalmaz olyan opciót, hogy mentse a file-ba a változásokat, ezért próbaképpen
felülírtam a konfig file-t:File.WriteAllText("MySettings.json", jsonString)Nem olvasta újra a konfigurációt a felülírt fájlból...
Más doksik is azt mondják, hogy a reloadOnChange "elméletileg" működik -
joysefke
veterán
ASP .NET Core 2.1 MVC - konfig file update
Kerestem, de nem találtam gyári megoldást...
Az appsettings.json file-t használom a statikus konfiguráció tárolására. A kontrollerből DI-jal elérem a konfigurációt és tudom olvasni, ez pedig nagyon szép és jó.
Ezen felül azt szeretném, hogy egy másik .json konfig-fájlban tárolt, az admin által az alkalmazáson belül konfigurálható beállításokat tudnám tárolni-updatelni.
Tehát updatelni szeretném a json konfig fájlban található beállításokat.
Valahogy így képzelem el (tutorialból összevágva)
Program.cspublic static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.SetBasePath(Directory.GetCurrentDirectory());
config.AddJsonFile("starship.json", optional: true, reloadOnChange: true);
})
.UseStartup<Startup>();Kontrollerben kiolvasom a config-sectiont, feltöltök vele egy modell osztályt, ami a UI-n keresztül updatelve lesz. Ezt a változást szeretném kommittálni a konfig-fájlba.
var starship = new Starship();
configuration.GetSection("starship").Bind(starship);
....
starship.Name = "Bismarck";Van erre valami gyári megoldás, ami nem igényli azt, hogy nekem kelljen írásra megnyitni és updatelni a konfig fájlt? Végül is ez is egy opció lehetne, mert a felhasználás kizárja, hogy egyszerre több helyről próbálják írni a konfigurációt...
-
joysefke
veterán
válasz
martonx
#8630
üzenetére
igen-igen, azóta már tudatosult bennem, hogy ezeknek a "participantoknak" nincsen szüksége ugyanazokra az identity szolgáltatásokra mint az admin accountoknak.
csak mivel az admin részt implementáltam először, aztán mivel emiatt "benne voltam" az Identity-témában, így "adta magát", hogy az IdentityUser táblát használjam a participantok személyes adatainak kezelésére is (ezek külső importból jönnek). már tényleg inkább külön táblába raknám a participantokat. Most egy darabig ott maradnak...
-
joysefke
veterán
kutkut: nem tudom
Szeretnék egy lépésben egy Http-requestet kiszolgálni és egy View-t visszaküldeni úgy, hogy a válaszban átírom a böngészőben megjelenő URL-t. Tehát nem a szerveren szeretném a Requestet egy másik címre a kliens elől rejtve átirányítani (url rewrite), illetve a klienset sem szeretném egy redirect-tel átküldeni egy másik címre, hanem egy lépésben szeretném a dolgot megtenni. Van erre lehetőség?
Amit konkrétan csinálni szeretnék:
http-get, URL : myawsomesite.cheapdomain.com/XYZ
XYZ alapján azonosítom a user-t, (ez a userName változóval bindol az URL szegmensből) a böngészéshez tartozó sessionbe beírom a user id-ját. Ez után azt szeretném, ha a user nem küldözgetné többet az XYZ azonosítót, azt le szeretném csípni az URL-ből.Jelenleg ezt Redirect-tel oldom meg. (A ResponseModel egy egyszerű form amit megjelenítek a usernek)
public async Task<IActionResult> Index(string userName)
{
ResponseModel model = null;
if (!string.IsNullOrEmpty(userName))
{
AppUser user = await GetUserSetSessionIfFound(userName);
return RedirectToAction(nameof(Index));
}
else
{
AppUser user = await GetUserFromSession();
model = (user?.Response == null) ? null : new ResponseModel(user.Response);
return View(model);
}
} -
joysefke
veterán
válasz
sztanozs
#8622
üzenetére
Hmmm
Megérte az időt hogy leírtam, így én is tisztábban látom a problémát.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Mivel az adminoknak már eleve kell autentikáció, és az Account kontrollertől kapott login-formon jelentkeznek be stb, és mivel ez egészen más mint a userek auto-loginja, ezért sokkal jobban járok, ha a kettőt külön kezelem, az egyedi route-szegmens pedig validálás (létezik-e olyan user) után egyszerűen megy a Session-be...
-
joysefke
veterán
válasz
sztanozs
#8622
üzenetére
Nem.
Az admin account(ok) természetesen védve vannak, nem közös pwd-t használnak.
Az egyedi linkek mindössze arra szolgálnak, hogy az egyes userek vissza tudjanak jelezni, hogy részt vesznek-e egy eseményen vagy sem, illetve hányan jönnek. A linkek élettartama véget ér az esemény lezárulásával.
Lehetne erősebb az autentikáció, de akkor kb senki nem használná (szerintem). Így nem kell accountot regisztrálni meg pwd-t megjegyezni. Kapsz egy linket emailben, rákattintasz, visszajelzel egy formban aztán kész.
-
joysefke
veterán
A föntire még visszatérünk
ASP Identity, Authentication
Sziasztok!
Az oldal látogatói rendelkezni fognak egy-egy egyedi linkkel:
www.myawsomesite.cheapdomain.com/[B]fw8o7i[/B]A vastagon szedett szegmens azonosítja a usert, userenként egyedi.
Minden userhez tartozik az ASP Identity DB-ben egy account, melyhez a "User" role van rendelve.
Az elgondolás az, hogy amikor a user lehívja a saját egyedi linkjét, akkor azonosításra kerül és az alkalmazás automatikusan bejelentkezteti a usert egy közös, az alkalmazás konfigjában levő passwordal. A usernek sem usernevet sem passwordot nem kell ehhez ismernie, számára a folyamat nem látható.
A problémám az, hogy nem tudom hogyan irányítsam át automatikusan a még nem autentikált userek kéréseit a bejelentkezéseket kezelő kontrollerre úgy, hogy a userenként egyedi (fent vastagon szedett) szegmens is továbbküldésre kerüljön ami ugye szükséges a user azonosításához.
Én eddig csak ennyit láttam/találtam:
-(1) A ConfigureServices-ben lehet állítani a LoginPath-ot, de nem látom, hogy hogyan lehetne neki átadni paramétert. Anélkül pedig az auto-login nem fog menni. Erről van szó:services.ConfigureApplicationCookie(options =>
{
....
options.LoginPath = "/Identity/Account/Login";
options.AccessDeniedPath = "/Identity/Account/AccessDenied";
....
});-(2) A főoldal action-methodját publikusnak hagyom és minden alkalommal manuálisan ellenőrzöm a Httpcontext-ből, hogy található-e bejelentkezett user (ha nem, akkor átirányítás az account controllerre ,ott auto login, majd visszairányítás)
-Esetleg a (2)-es pontnál jobb ötlet?
-Kell-e nekem (a usereknek) ehhez egyáltalán autentikáció, vagy elég lenne a sessionben követni, hogy milyen egyedi linkkel (route segmenssel) jöttek be a userek és ez alapján végül is követhető lenne a dolog...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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!
- BESZÁMÍTÁS! ASRock B250 i5 6600 16GB DDR4 256 SSD 500GB HDD GTX 1050 2GB Zalman Z1 Njoy 550W
- BESZÁMÍTÁS! Gigabyte H610M i5 13400F 16GB DDR4 512GB SSD RX 6700XT 12GB DeepCool MATREXX 40 650W
- Apple iPhone 14 128Gb Kártyafüggetlen, 1Év Garanciával
- Azonnali készpénzes AMD Radeon RX 5000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- BESZÁMÍTÁS! Intel Core i7 8700K 6 mag 12 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged