Új hozzászólás Aktív témák
-
coco2
őstag
Sziasztok!
Van egy winforms alkalmazásom (c#), amit másik alkalmazásból indítok el _wsystem() winapival. El is indul, de megjelenik mellette egy extra shell ablak (üres konzol). Jó lenne, ha az nem lenne. Ha valaki találkozott már a problémával, valami bölcsesség jól jönne.
Előre is köszönöm
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
leslie23
tag
Sziasztok!
ASP-guruk tanácsára lenne szükségem, bár inkább általános jellegű a kérdés. Egy viszonylag egyszerű webappon dolgozok (.NET6 Razor Pages és néhány controller, amiket AJAX-hívásokkal használok) és N-tier architecture-t próbálok kialakítani.
Van egy Data rétegem, amibe csak a domain model class-okat rakom, van egy DataAccess, amibe a Repository és UnitOfWork pattern dolgai és az EF Core-specifikus dolgok kerülnek, illetve van egy Presentation project, ami maga a webapp.Az első kérdésem, hogy a ViewModel-eket hogyan lenne célszerű elhelyezni? Jelenleg a Data projectben van egy ViewModels mappám, de logikailag ezeknek lehet a Presentation layerben lenne inkább a helye. A scaffolded Identity lapok tartalma alapján azt látom, hogy a MS fejlesztői a ViewModeleket magukba a RazorPage-ek PageModel-jébe rakják, minden laphoz tartozó .cshtml.cs fájlban van egy InputModel class, és ennek egy példányára alkalmazzák az adatkötést a [BindProperty] attribútummal. Ez a megoldás olyan szempontból is tetszik, hogy így a Data layerben nincs data annotation használat (Required és ErrorMessage stb.), hiszen ezek a dolgok logikailag gondolom inkább a Presentation layerhez tartoznak.
Viszont ha innen közelítem meg a dolgot, akkor minden esetben szükségem van Model - ViewModel mappingre, ami manuálisan nyilván sok-sok favágó kód írásával járna, AutoMapperről pedig azt olvasom, hogy nem igazán jó megoldás, ha oda-vissza adatátadás történik. Mi ilyenkor a bevett megoldás, vagy mi számít itt gold standardnek? Egyáltalán helyes a megközelítésem? Köszi előre is!
[ Szerkesztve ]
-
válasz leslie23 #9705 üzenetére
Én sem vagyok guru
N-tier architecture-t próbálok kialakítani
tankönyvekben jól működik....van egy DataAccess, amibe a Repository és UnitOfWork pattern dolgai és az EF Core-specifikus dolgok kerülnek...
Az én személyes nem feltétlenül objektív véleményem erről az EF+UoW/Repository a témáról.
Az Ef DbContext osztálya az már önmagában egy UnitOfWork, benne a DbSet<T> pedig egy Repository megvalósítás.
1,
Ezt becsomagolni egy másik UoW/Repository abszrakcióba csupán azért hogy legyen egy repositorid vagy UoW-öd önmagában semmi értelme.2,
Ha azért csomagolnád be a DbContext-et egy abszrakt, generikus UoW / Repository petternbe, hogy az EFCore egy absztrakció mögé kerüljön, és a felsőbb réteg ne dependáljon közvetlenül az EF felé, akkor ez nemes és jó indok, de saját tapasztalatom alapján nem működik jól.Itt van pld a docs.microsoft.com oldalán egy Generikus Repository UoW sablon ami absztrakció mögé helyezi a Repo/UoW pattern konkrét megvalósítását, az EfCore DbContext-et: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10) | Microsoft Docs
Nekem ezt az absztrakciót mentésre (C/U) a legprimitívebb esetektől eltekintve nem sikerült érdemben használni. Orrán száján ereszt. A relációs adatbázis FK constraintjei illetve hogy az EF change tracker éppen melyik rigojáját alkalmazza fogják meghatározni, hogy egy Update az éppen működik vagy sem. Az relációs constrainttel nincs gondom, de a másik az nekem komoly probléma.
...Jelenleg a Data projectben van egy ViewModels mappám, de logikailag ezeknek lehet a Presentation layerben lenne inkább a helye....
N-layerben az egyes layerek csak lefele dependálnak és ha egy mód van rá, akkor csupán a közvetlenül alattuk levő réteg felé. A ViewModel az prezentációs réteg (az ASP-kontrollerrel együtt).
...tetszik, hogy így a Data layerben nincs data annotation használat (Required és ErrorMessage stb.), hiszen ezek a dolgok logikailag gondolom inkább a Presentation layerhez tartoznak...
Optikailag nem néz ki jól, ha egy több projekt által használt model osztályon olyan speciális attributumok vannak definiálva aminek semmi köze az adott assembly céljához, DE a Te esetedben a "System.ComponentModel.DataAnnotations" az ugye része a Core frameworknek és része lesz a jövőben is és a visszafele kompatibilitás adott lesz. Ezért ez egy "nem-volátilis dependencia", reálisan soha nem lesz útban, soha nem romlik el, max a szemedet fogja szúrni. Szemben mondjuk az EF Core-ral, ami egy "volátilis dependencia": 1-2 évente újraírják és minden verzióugrás tele van funkció-törő változtatással.
Ráadásul ugye a "System.ComponentModel.DataAnnotations" használata vagy nem használata semennyiben nem fogja a tesztelhetőséget befolyásolni, míg a DAL tesztelése vagy tesztekben való kiváltása az egy téma amivel majd foglalkozni kell, szóval a DataAnnotations elhelyezése -szerintem- az utolsó prioritás amin töprengened kell.
szükségem van ... mappingre, ami manuálisan nyilván sok-sok favágó kód írásával járna, AutoMapperről pedig azt olvasom, hogy nem igazán jó megoldás, ha oda-vissza adatátadás történik.
Én is csak ezeket ismerem. Hogy két irányú mappelésnél mi lenne a probléma, azt nem tudom. N-layer esetén mivel a felső réteg ismeri/hívja az alsót, ezért logikusan a felsőbb rétegnek kell hívnia a mappelést is. (mivel az alsóbb réteg nem ismeri a felsőbb rétegben definiált modellt (fordítva viszont igen), hiszen nincsen oda dependenciája (projekt referálása)). A mappelés az logikailag infrastruktúra kód "plumbing". Minden réteg használhatja (dependálhat felé), ennek megfelelően be lesz betonozva a projektbe.
Egyáltalán helyes a megközelítésem? Köszi előre is!
Ha maradsz az N-layernél, akkor az, hogy minden réteg (ami nem valamilyen mindent átható infrastruktúra (mapper/logging)) az csak lefelé dependál. Ha az EF-Core-DAL-t reálisan ki akarod váltani vagy szeretnéd, ha egy EF Core 6 DAL => EF Core 7 DAL váltás sima legyen, akkor lehet hogy jó ötlet lenne az applikációs logikát a DAL-tól egy DAL interfész segítségével elválasztani, ami a saját önnálló assembly-jében van. Ez a stairway pattern. A DAL megvalósítás interfészen keresztül (amely külön assemblyben van) le van választva a használójától és a megvalósításától is. Ennek van egy pozitív hozadéka: Le tudod fordítani a solutiont működő DAL megvalósítás nélkül is. => És ez visszafele is igaz. Enélkül ha nem fordul a DAL projekt, akkor semmi sem fordul.Ahogy én állnék neki (és ez szubjektív és nem feltétlenül helyes megközelítés):
Dobnám az N-layert publikus generikus repositorival meg UoW-kel együtt.Lenne egy prezentációs projekted (ASP), lenne egy külön konkrét EF-Data access megvalósítás projekted meg lenne egy olyan projekted ami sem a prezentációs sem a data access projektet nem referálja. Ez tartalmazná az entitások modell osztályát is , illetve az összes interfészt amelyeken keresztül mondjuk a perzisztenciát akarja vezérelni. Az interfész pontosan azt és csak azt deklarálná amire a központi projektednek szüksége van. Meg tartalmazná az összes tiszta domain-logika kódot. A lényeg, hogy ez a központi projekted kifelé nem dependálhat volátilis dependenciák (EF Core, Adatbázis) irányába. Dependenciák invertálva vannak befelé.
A cél itt az, hogy volatilis dependenciák hiányában a központi projekted könnyedén unit tesztelhető legyen. Az emlegetett mappelgetés is sokkal kisebb probléma.Üdv
J.[ Szerkesztve ]
-
Alexios
veterán
válasz joysefke #9706 üzenetére
2,
Ha azért csomagolnád be a DbContext-et egy abszrakt, generikus UoW / Repository petternbe, hogy az EFCore egy absztrakció mögé kerüljön, és a felsőbb réteg ne dependáljon közvetlenül az EF felé, akkor ez nemes és jó indok, de saját tapasztalatom alapján nem működik jól.
Én ezzel szintén saját tapasztalat alapján nem értek egyet, nálunk pl. nagyon jól működött mikor legacy appot migráltunk ef6-ról ef core-ra, majd szintén mikor bizonyos részeket dapperre. A kliens kód oldaláról lényegében semmi változás nem történt csak az interfészek mögötti implementációk -
válasz Alexios #9707 üzenetére
Nekem ezzel és ehhez hasonló generikus repositorikkal: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10) | Microsoft Docs
Az a bajom, hogy az ilyen metódusok mint Update<T>(T entity) , esetleg Save<T> (vagy Upsert<T>), Delete() elhitetik a hívó oldalon, hogy ennyire egyszerű a perzisztencia, hogy meghívod őket utána a UoW-ön egy Save()-t és kész. És hogy ez mindenre működik amit típus paraméterként át tudnak adni.
Holott
-nem feltétlenül értelmezhető/működik minden lehetséges T entitás típuson az összes művelet,
-nem hívhatsz egymástól függetlenül mindenféle Repository metódust egy UoW tranzakción belül,
-illetve lehet hogy mondjuk az Update<T>(T entity) működik, de mondjuk az adott konkrét entitásra nem a mindenkire érvényes implementáció-t akarná a kliens kód hajtani.
-Az is lehet hogy van egy entitásod ami már trackelve van, mivel az egyik repository metódus impliciten előkerítette, majd a másik ráhív egy attach-ot a már trackelt entitásra. => exception, holott amit a kliens el akar érni annak van értelme és meg is valósítható lenne egy tranzakción belül (DB engedné egy megfelelő SP-vel, illetve engedné az EF is, ha ügyesen lenne megcsinálva).Ami nekem sokkal szimpatikusabb:
Kliens kód kap egy interfészt amin azok a perzisztencia műveletek vannak amelyekre a kliensnek konkrétan szüksége van.
Az interfészt megvalósító osztály EF-függő, az adott metódusa pedig közvetlenül indít EF dbcontext-et (lehetőleg DI-on keresztül szerez ehhez egy DbContextFactoryt vagy azzal egyenértékű opciót amiből Contextet lehet előállítani), közvetlenül attach-csolhat entitást és állít EntityState-t, illetve menti a tranzakciót. Tehát kihasználja az EF tényleges tudását és azt biztosítja a hívónak amire annak szüksége van, lehetőleg egyetlen hívásból.
[ Szerkesztve ]
-
leslie23
tag
válasz joysefke #9708 üzenetére
Igen, az mindenképpen cél, hogy a presentation layernek ne legyen EF Core dependenciája és ahogy Alexios is írta, ha éppen arra van szükség, gond nélkül cserélhető legyen a DataAccess layer akár Dapperre, sima ADO.NET-re, bármire.
Mivel saját hobbiprojektről van szó, így erre soha nem fog sor kerülni, de most valahol pont az elmélet érdekelne, hogy hogyan lehet és kell ezt jól megcsinálni. Olvastam a hivatkozott MS-os leírást is egyébként.„Ami nekem sokkal szimpatikusabb...”
Huhh, lehet, hogy valami nagyon hasonlóról beszélünk egyébként, próbálom értelmezni. Neten található projektek alapján most úgy legoztam össze, hogy a presentation layer egyIUnitOfWork
interfészt lát a DataAccessből, és aProgram.cs
-ben bele van rakva egy példánya aUnitOfWork
-nek DI konténerbe.IUnitOfWork
szintén interfészeket tartalmaz mint property-k (IPersonRepository
,IProductRepository
, stb.).
A generikus Repo-nak is van egy generikus interfésze (IRepository<T>
), ebben nincs pl. Update metódus, csak Add, Remove, GetAll, GetFirst.IProductRepository
örökölIRepository<Product>
interfésztől, illetve tartalmazhat specifikus metódusokat, mondjuk épp egy ilyet hogy:void Update(Product product)
.
A konkrét implementációk pedig pl.:ProductRepository : Repository<Product>, IProductRepository
,
vagyis öröklik a generikus repo metódusait, és implementálják az entitás-specifikus metódusokat, annak számít most mondjuk egy Update is.Ha jól értelmezem az általad írottakat, valami hasonlóra gondolsz, csak az interfészeket szerencsésebb lenne kiszervezni egy külön assembly-be, ami amúgy logikusan is hangzik.
Mondjuk ha jó a sejtésem, az EF Core-t teljesen nem lehet „száműzni” a presentation layerből, mert a DI miatt a kell a builder.Services.AddDbContext...Automapper témában sajnos csak másra tudok mutogatni, jómagam még nem kísérleteztem vele, így nem tudom mennyire validak az itt leírt ellenérvek...
[ Szerkesztve ]
-
válasz leslie23 #9709 üzenetére
Két párhozamos dologról volt szó amelyek egymástól valamennyire függetlenek:
A fontosabb döntés:
1,
1a, N layer (Te nyilván háromban gondolkodsz) vs 1b Hexagonal (vagy ahogyan hívni szeretnéd) arch.másodjára
2,
2a, Generikus Repo/UoW mögé rejtett EF DbContext vs 2b Domain specifikus perzisztencia interfészek (nem tudom a nevüket bocsi)Én azt sugalltam, hogy ne próbálj meg tankönyvi N-layert csinálni.
Ezen felül nekem fenntartásaim vannak azzal kapcsolatban, hogy az DbContext-et bezárjuk egy generikus Repo/UoW mögé és majd az "applikációs réteg" használja a az Insert/Update/ etc metódusokat (az eredeti írásodból azt olvastam ki, hogy erre készülsz) .
Szóval anélkül, hogy tudnám, hogy egyáltalán mit akarsz csinálni, nekem az alap hozzáállásom egy újabb kis hobbiprojektemhez amiben van ASP meg DB a következő lenne (a nevek szabadon variálhatóak, csak próbáltam beszédes neveket varázsolni):
MyProjekt.ASP => MyProjekt.Core <= MyProjekt.Ef
Nincsenek rétegek és nincsen sem teteje sem alja, viszont van közepe meg vannak a többiek. A nyilak a dependencia irányokat mutatják.
Mindenki a közepét referálja, a közepe viszont nem referál olyan dolgokat amelyektől nem akar függeni. Nem referálja sem a saját EF vagy ASP függő projektjeidet sem magát az ASP vagy EF frameworkot
Amikor a közepe valamit akar a "széllétől", akkor azt egy saját magában definiált interfészt használva teszi meg
Ennek két hatása van:
-a közepe mindenki nélkül, önmagában is fordul, ez megteremti a lehetőségét, hogy könnyedén unit teszteld
-a közepe a függőségeket (pld EfPerzisztencia) DI formájában (leginkább konstruktoron keresztül) kapja meg, ez pedig megint erősíti a közepének a unit tesztelhetőségétAhhoz, hogy ez megvalósuljon, a dependenciák invertálva vannak:
Ha ez egy N-layer arch lenne, akkor az "Application layer" referálná a DAL-t (vagy közvetlenül, vagy interfészen keresztül, de az interfész is logikailag a DAL-ban lenne).
De itt nem, itt ez fordítva van. Itt amit a DAL (ábrán MyProject.Ef)-tól a Core használni akar, az interfész formájában definiálva van, és ez az interfész a "Core" része és a DAL valósítja meg.Másrészt a "Core"-ban lévő dolgoknak amelyek valamit akarnak a széllétől (pld perzisztálni) nyilván szükségük van olyan objektumokra amelyek ez meg is tudják csinálni (megvalósítják azt az interfészt amit a "Core" adott osztálya éppen használni akar). Ezek az objektumok DI-jal kerülnek be leginkább mint konstruktor paraméter. A DI konténert a te esetedben az ASP-s template ConfigureServices-ban tudod konfigurálni (ez gyak. az applikáció belépési pontjánál van).
Visszatérve a konkrét kérdéseidhez:
-Az ASP-s Controllerek, View-k Modell-ek (azok amelyek a Html-be szállítják az adatot) azok mind az ASP-s projektedbe kerülnek.-A Core-ba kerül minden "domain model" (első körben az entitásaid is mindenképpen akár van annotáció rajtuk akár nincs) meg mindenféle logika ami ezeket érinti.
-A "Core"-ból mindenféle frameworkos stabil osztály felé mehet dependencia, pld a DataAnnotation-t amit korábban felvetettél reálisan nem fog problémát okozni és a tesztelést sem nehezíti meg.
-Mehet külső dolgok irányába is, ha azok nem nehezítik a tesztelést meg nem akarod őket soha lecserélni. pld Newtonsoft.Json.
-A "Core" specifikálja interfészekkel, hogy mit kell tudjon a perzisztencia (meg egyéb függőségek amelyektől akar valamit) és ezek az interfészek a core-ban vannak.
-A külső projektekben lévő függőségek pedig megvalósítják a Core-ban azt/azokat az interfészeket amelyek miatt nekik egyáltalán helyük van a szolutionben.
Tehát ha maradsz a generikus repositorinál, "2a" akkor a Te általad tervezett ...
IPersonRepository
,IProductRepository
, ...IRepository<T>
...IProductRepository
...IRepository<Product>
interfészeid is mind a "Core" ba mennek,egy a lényeg, a Core-ba nem kerülhet be EF függőség (tehát az interfészeid metódusainaknak sem lehet EF ben deklarált paramétere, visszatérési értéke). A Repository interfészed konkért megvalósítása viszont az Ef-projektbe kerül.
Vagy dobod a generikus repository-t ez a "2b" és ekkor a Core-ban nem a fenti teljesen álltalános perzisztencia interfészek lesznek mint hogy az IPersonRepository-n lesz mondjuk egy void Save(Person person), hanem lesz mondjuk egy (csak a példa kedvéért)
IPersonCommands
{
void SetProfileImage(int personId, Picture picture);
}
ugyanúgy a "Core"-ban, ezt meg mondjuk megvalósítja egy EfPersonCommands az Ef projektben. Szintén csak a példa kedvéért:EfPersonCommands: IPersonCommands
{
IDbContextFactory<PersonContext> _factory
// vagy Optionst injektálsz (az a preferált ebből szintén elő tudsz állítani Contextet amikor kell) vagy factoryt, mindkét opció tiszta lesz DI-jal,
EfPersonCommands(IDbContextFactory<PersonContext> factory)
{
_factory = factory // throw if null..
}
void SetProfileImage(int personId, Picture picture)
{
using var context = _factory.Create();
//csinálsz valamit
context.Save() <= tranzakció
} <= dbcontext dispose
}
A kliens pontosan azt kapja amire szüksége van (cserébe potenciálisan több metódusod lesz), a megvalósításba már bele van csomagolva a tranzakció.
2a vs 2b az részletkérdés (könnyen tudsz változtatni bármelyik irányban), 1a vs 1b viszont egyáltalán nem.[ Szerkesztve ]
-
válasz joysefke #9711 üzenetére
lemaradt:
Mivel DI-t és teszteket szeretnél használni (hogy az egész 1b arch egyáltalán értelmet nyerjen) ezért valahol össze kell állítanod a DI konténert (ez a composition root, a te esetedben a ConfigureServices metódus az ASP templétben).Magának az ASP projektnek értelemszerűen nem kéne sőtt nem szabadna dependenciája legyen mondjuk az Ef projekthez, de a composition rootnak (ConfigureServices metódusnak) szüksége van rá, mivel ez alapvetően a solutionben lévő összes függőséget referálja. Ez ezen az egy ponton rendben van. Ha zavar, akkor a DI-konténer összerakását kiszervezheted egy másik csproj-ba.
[ Szerkesztve ]
-
kkdesign
senior tag
Sziasztok!
Szeretnék segítséget kérni abban, hogy nemrég tértem át MAC-re, feltettem a Visual Studiot, C#ban szeretnék Xamarinban próbálkozni, tanulgatni, majd valami appot készíteni. Viszont már az elején az emulátornál elakadok. Próbáltam utánanézni neten, de Windowsos megoldást láttam csak, hogy szolgáltatásokban engedélyezzem a Hyper V egyes részeit. Ezt MACen elég nehéz megvalósítani, viszont lövésem sincs, hogy mi alapján tudnám ezt megoldani. Volt valaki hasonló cipellőben? Van ötletetek rá? Android studio is fent van, azért is, hogy hátha az sdk-val lett vna gond, de nem. Köszönöm előre is
-
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.[ Szerkesztve ]
Én kérek elnézést!
-
Alexios
veterán
válasz martonx #9716 üzenetére
Biztos mennie kell macen is, eleve a Xamarin Studiot nevezték át anno vs for mac-re, ios fejlesztésnél kell mac eleve hozzá a buildhez, bár hobbi projekthez én is vagy maui-t(mondjuk ebből még mindig csak previewk vannak..) vagy react nativeot kezdenék inkább tanulgatni már.
Hogy a témához is hozzászóljak, milyen macről van szó?
[link] Itt ugyan erről a hibáról írnak, esetleg erre rá lehet nézni[ Szerkesztve ]
-
leslie23
tag
válasz joysefke #9711 üzenetére
Többször is átolvastam, emésztem az infókat, de érteni vélem az érveidet és logikusan is hangzik az általad felvázolt koncepció, szóval nagyon köszönöm az idődet és a segítséget!
GitHubon és demo tutorialokban főleg egyszerű, néhány oldalas CRUD appokat látok mindig, szóval nehéz olyan realworld cuccost találni, ami komplex, mégis jól átgondolt, és követ valamiféle helyes gyakorlatot. Lassan, de kezd tisztulni a kép, köszi még egyszer! -
ReSeTer
senior tag
Helló!
Kicsit egyszerűsödött problémám, a Word dokumentumba való beillesztéssel kapcsolatban.
Elég lenne, ha a végfelhasználó egy gomb megnyomása után a vágólapjára másolódna egy formázott dokumentum képekkel is, és megnyitna manuálisan a felhasználó egy Word-ot, majd ctrl+v és beilleszti.Hogyan kellene ezt a feladatot megközelíteni? Először mondjuk valami köztes formátumban létrehozni a dokumentumot, vagy közvetlenül lehet "írni" a vágólapra? A dokumentumban táblázatnak is lennie kell, és adatok is vannak benne.
Így megtudnám kerülni az Office verzió problémákat, meg az open XML agyonbonyolított hülyeséget.
-
ReSeTer
senior tag
-
Konfigurációs adatként szeretnék viselkedést definiálni az applikáció számára.
Az éppen járt megközelítés, hogy a konfigurációs adat némi forráskód lenne, amit szükség esetén futási időben fordít az applikáció és a továbbiakban a fordítás eredményét használja fel mint konkrét implementáció.
.Net 472 illetve PowerShell 5.1 áll rendelkezésre, ennél újabb nem. Az
Add-Type -ReferencedAssemblies $assemblies -TypeDefinition $sourceCode
commandlettel szemezek. Ez fordít C#-ot, az elkészülő Type -ot pedig az applikáció fel tudja használni.Találkozott valaki ezzel a feladattal? Van az adott platform-verzióra ennél jobb ötlet, kiszámíthatóbb, modernebb compiler dobozból? Van az "Add-Type"-pal tapasztalat? Alkalmanként egyetlen osztályt akarok fordítani, de az nem feltétlenül "Hello world"...
-
dqdb
nagyúr
válasz joysefke #9726 üzenetére
Ha C# scriptelést szeretnél, akkor arra ott van a Roslyn, a .NET C#-ban írt C# fordítója, amelyet megfelelő objektummodellel ellátva be tudsz ágyazni saját projektekbe is.
Ez itt egy gyors bevezetés, ez pedig egy minimálisan mélyebb példa annak átlátására, hogy mit is lehet elérni Roslyn segítségével elérni.
Aztán hajrá a C# szintaktikájú saját DSL létrehozásához. Ha nem magadnak írod a cuccot, akkor szerintem érdemes a DSL-nek fluent felületet definiálni, az talán közelebb áll az átlagemberekhez.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
-
cigam
félisten
public static void LoadDocument(Stream fileStream, FlowDocument document, string dataFormat)
{
try
{
TextRange range = new TextRange(document.ContentStart, document.ContentEnd);
range.Load(fileStream, dataFormat);
}
catch (ArgumentException ex)
{
MessageBox.Show("Nem támogatott fájl típus.");
}
}
A fenti kód az rtf fáj betöltés gomb kódja. Hogyan tudnám az összes szín beállítást resetelni?
A cél az lenne, hogy minden betű szín infója tűnjön el, és egy mezei fekete/fehér szöveget kapjak.Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
Eddig csak az első linket néztem meg (azt is egyelőre csak NET6-tal), de szerintem nekem pontosan erre (Roslynra) lesz szükségem.
Valamiért az volt bennem, hogy csak modern platformra van, ezért nem is néztem utána. Az "Add-Type" valami régi fordítót használ, régi C# verió támogatással és a hibaüzenetei borzalmasak.
Aztán hajrá a C# szintaktikájú saját DSL létrehozásához.
Annál azért egyszerűbbnek 'tűnik':
Http szolgáltatás daemon-kliens oldalára szeretnék a kliens HttpMessageHandler pipelinejába beépülő nem-interaktív autentikációs komponsenst (pld OAuth2 Client credentials flow) ami a lehető legszabadabban konfigurálható.A szabad konfigurálhatóság biztosítaná, hogy az autentikáció pontosan úgy történjen, ahogy az autentikációs végpont (token url) diktálja illetve a Http üzenetbe a token -vagy ami az autentikáció meglétét jelképezi -abban a formában kerüljön bele, ahogyan a szerver oldal szeretné.
Az tűnik a kiindulási állapotnak, hogy a jövőben több féle (standardtől kicsit eltérő) lehetőség lesz, mintsem hogy azt statikus konfigurációval le tudjuk fedni.
J.
[ Szerkesztve ]
-
dqdb
nagyúr
válasz joysefke #9730 üzenetére
Az "Add-Type" valami régi fordítót használ, régi C# verió támogatással és a hibaüzenetei borzalmasak.
A Roslyn előtt azt lehetett kihasználni, hogy a .NET Framework része a csc.exe. A futtatni kívánt snippetből generáltál egy teljes .cs fájlt, ahol a generált kódban #pragma line használatával el tudtad érni, hogy az eredeti fájl nevével és a megfelelő sorszámmal dobja a hibát a fordító, futtattad és parse-oltad az eredményt. Működött ugyan, de eléggé meh, a Roslyn ilyen téren megváltás volt a rugalmasságával.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Roslyn-nal sikerült működésre bírnom a dolgot, (kb end-to-end megy fordítástól, az authentikációig és sikeres API hívásig )
De a fordítás csak úgy működik, ha CSharpScript-et használok, ez az opció ahogy látom impliciten felhasználja a runtime betöltött assembliket referenciaként a fordításhoz /ami nincs betöltve csak azt kell referálni/.
CSharpCompilation-nal ugyanaz a fordítás nem működik. Itt nekem kéne expliciten megadni az assembly referencákat, amit természetesen hiánytalanul meg is tesztek. Aztán kapok egy undorító, Google által jól ismert fordítási hibát ami arra panaszkodik hogy a System.Net.Http.dll verzió mismatch van, az assembly ahonnal dinamikusan fordítom a kódot (és ahová interfész miatt függősége van a fordított kódnak) 4.2.0.0-t val lett fordítva, a Roslyn pedig 4.0.0.0-t akarna használni. Hogy a 4.2.0.0 honnan jött, azt nem tudom, de kézzel nem tudom betölteni. Hogy CSharpScript-tel ez miért és hogyan működik azt persze nem tudom.
Majdnem biztos vagyok benne, hogy a hibának semmi köze nincsen a Roslynhoz magához vagy akár a kódomhoz, egyszerűen nem azt a verziót kapom DLL-ből amit szeretnék.
Akik nálam jobban értenek a fordításhoz biztos meg tudnák oldani, meg lesz ez nálam is oldva, hogy "CSharpCompilation"-nel is működjön, de ez így egyáltalán nem bizalomgerjesztő...
Félek, hogy ami az én gépemen dinamikusan fordul, produktív gépen majd esetleg nem fog. Egy halom DLL-t pedig nyilván nem akarok betenni a repoba és nuget helyett azokat referálgatni vagy hasonló okosság.
===
Szóval most a pluginok kerültek fel az asztalra:
Talán ahelyett, hogy konfigból (encryptált DB-ből) on the fly fordítjuk a konkrét megvalósítás kódját, jobb ötlet lenne szükség esetén egy újabb plugin-dll-t berakni egy plugin könyvtárba aztán onnan betölteni a konkrét megvalósítást.Ilyen önműködő plugin megvalósításhoz van net 472-re ennél jobb cucc?
Managed Extensibility Framework (MEF) - .NET Framework | Microsoft DocsHasználta ezt már valaki?
[ Szerkesztve ]
-
daninet
veterán
Sziasztok!
Valaki validálná nekem, hogy az alábbi kód helyes? Azt akarom, ha ez a loop eléri az auto9.g sorszámot ugorjon vissza nullára (vagyis a számlálóban 1-re amiből kivonunk egyet).
Ezek a fájlok majdnem 6 óráig futnak ezért szeretném tudni a hosszú teszt előtt, hogy amit belekontárkodtam működikvoid CardReader::autofile_begin() {
autofile_index = 1;
(void)autofile_check();
}
bool CardReader::autofile_check() {
if (!autofile_index) return false;
if (!isMounted())
mount();
else if (ENABLED(SDCARD_EEPROM_EMULATION))
settings.first_load();
// Don't run auto#.g when a PLR file exists
if (isMounted() && TERN1(POWER_LOSS_RECOVERY, !recovery.valid())) {
char autoname[10];
sprintf_P(autoname, PSTR("/auto%c.g"), '0' + autofile_index - 1);
if (fileExists(autoname)) {
cdroot();
openAndPrintFile(autoname);
if (autofile_index = 10)
autofile_index = 1;
else if (autofile_index < 10)
autofile_index++;
return true;
}
}
autofile_cancel();
return false;
}
Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>
-
cigam
félisten
válasz quailstorm #9738 üzenetére
Bocs! A lényeg lemaradt: Ha elindítom a programot, akkor működik a letöltés gomb, be is tölti kiválasztott szöveget. Csak nem találom a programban ezt a rész! Nem én írtam, Githubról töltöttem le és próbálom átírni magyarra.
robotjatek
Köszi! Ööö... Erre hogyan tudok rákeresni?[ Szerkesztve ]
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
quailstorm
nagyúr
válasz robotjatek #9739 üzenetére
Ja igen, így már értem én is, hogy mit nem látott. Pedig észrevettem a commandot elsőre is...
A Binding (ICommand implementáció) amit néznie kell és F12-vel nyomkodnia. A Click handlert lehet hogy valaki véletlen hozzáadta, de az nem csinál semmit most, inkább törölni kellene.
Ha paraméter kell a Command-hoz, akkor a CommandParameter attribútummal megteheti.#9740 cigam
ICommand WPF MVVM[ Szerkesztve ]
-
cigam
félisten
Köszi az útmutatást!
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
ReSeTer
senior tag
Helló!
Ha a szabadidőmben tanulni szeretnék C#-t akkor tudtok ajánlani roadmapet? Eddig udemy-n található ingyenes anyagon vagyok túl. Hogyan tovább?
Ha esetleg konkrét anyagot tudtok ajánlani az még jobb. A lényeg, hogy feltételezze az anyag, hogy nincs előéletem programozásban. Nagyon tudom utálni, amikor túl bonyolítják a példákat, amikor csak a szemléltetés a cél. -
sztanozs
veterán
válasz ReSeTer #9743 üzenetére
Próbálj meg tesztfeladatokat megoldani.
https://www.codewars.com/ például.JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Sziasztok!
Nem tud valaki egy jó tutorialt/könyvet accdb kezeléshez?
Hogy tudom megjeleníteni egy tábla tartalmát, esetleg módosítani?
Odaáig ment, hogy hozzáadtam a forms application-höz az access fájlt (1 tábla van benne egyelőre), tudok is a táblába új adatokat felvenni űrlapról (textboxokkal).#ReSeTer: viktortaylor.eu Ott vannak kezdő szoftverfejlesztőknek szánt anyagok.
[ Szerkesztve ]
Eladó Lego: 42139 All terrain vehicle
-
quailstorm
nagyúr
válasz ReSeTer #9743 üzenetére
Van egy magyar könyv, Evosoft alkalmazott írta. Szerintem ez elég jó alap.
#9745 Victoryus : megjelenítés rétegben mindegy milyen DB van alatta, szóval inkább általános adatbáziskezelős tutorialokat nézz, meg az accdb driver API kézikönyvét.
[ Szerkesztve ]
-
Flashback
addikt
Sziasztok
Két applikációm között kellene adatokat megosztanom.
Mi a legegyszerűbb/legtisztább implementáció mondjuk egy objektum átpasszolására?
WCF-et néztem szimpatikusnak tűnik a leírás alapján de csak egy 12éves példát találtam.
Csinált valaki ilyet? Hogy induljak el? Van egyszerűbb mód?Bocs nincs hosszú ö, ü és néha az á is ä :)
-
Találtam végül entity framework-höz jegyzetet: [link]
Johanyák Zsolt: Vizuális Programozás jegyzete.
Eddig kb. 10x futottam neki, de egyszer sem ment különféle okokból. Most 11x tötöltem ki az egészet és írtam újra. Odáig ok, hogy megvan a 3 tábla, látja őket, lehet mindháromba adatot beírni. De amikor megírom a konzol app-ot, akkor az hibaüzenetet dob: System.Data.Entity.Core.EntityException: 'The underlying provider failed on Open.'
SqlException: An attempt to attach an auto-named database for file F:\teszt\c#_feladatok_kész\GRAFIKUS felület\Telefonszamok_Konzol\bin\Debug\Telefonszamok.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
Az elérési út jó amit ír, ott van az mdf fájl.Egyéb kérdés: eredetileg a munkahelyi gépen írtam, hazahoztam, nem ment, elérési út hiba. Tehát ha egyszer netalán működne is, akkor mindig át kell írni az elérési útját az adatbázis fájlnak? Nem nagyon fogadta el a relatív hivatkozást. Ez ennyire körülményesen működik?
Én anno Delphin tanultam sql kezelést, de nem rémlik hogy ennyit szenvedtünk volna, mint ezzel.Eladó Lego: 42139 All terrain vehicle
-
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!
Én kérek elnézést!
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Krómozott előlapos Jura Z5 automata kávéfőző beépített profi cappuccino fejjel
- Eladó teljesen új, bontatlan Nespresso Essenza mini piros színben
- Motorola Razr 40 - 8GB 256GB DualSIM Sage Green - Bontatlan - Garanciális
- Canon Ixus 285 HS
- Új! Bontatlan! Samsung 8TB 2.5 SSD eladó! Országos Szállítással