• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    TENCOKACISTROMYProgramovani v C#, F# a dalsich jazycich pro .NET, Mono a ostatni CLI implementace
    SLUPKA
    SLUPKA --- ---
    MAIMONIDES: Asi jsem se nevyjádřil správně - tím, že v .NET Core jsou aktuálně spíš bety jsem myslel, že jsou spíše beta verze řešení tohoto problému. Samotný .NET Core rozhodně za betu nepovažuji.

    C++/CLI je peklo, ale funguje ve výsledku dobře. Nicméně, neustále se měnilo, jestli to podporované je nebo není a podle toho byla podpora ve VS. Netuším, jestli vůbec jde zkompilovat pro .NET Core.

    To Mono byla (v době kdy jsem to zkoušel) jediná varianta pro to, aby i ten .NET kód byl zkompilovaný nativně. Výsledkem byla nativní knihovna, která šla používat přes C-API a nevyžadovala od systému takřka nic. Nebyl tam velký rozdíl od knihovny napsané nativně, fungovalo to docela svižně a dobře. Akorát člověk nemohl používat úplně vše, co bylo dostupné v .NETu. Nicméně, člověk co chtěl používat tu knihovnu vůbec nemusel řešit, že to je napsané v .NETu, byla to klasická nativní knihovna.

    Z mého pohledu bude ideální nativní kompilace .NETu, ale k tomu je hádám ještě daleká cesta.
    MAIMONIDES
    MAIMONIDES --- ---
    SLUPKA: Dík za pohled. Úplně teda nesouhlasím..
    .NET 3.1 je označenej za tříletý lts, což je v kontextu c# docela doba.
    Nativní net kompilace je explicitně označení za betu, čili tam ne.
    C++/CLI jsem zvažoval, ale nějak v tom nevidím tu radost. Je to o dost víc (mechanicky generovanýho) kódu a vpodstatě musíš řešit pořád totéž. Z hlediska rychlosti je to asi neutrální a doufám, že by to kompilátor kompletně pozřel.
    Interopy mám vygenerovaný a api je navrhovaný tak, aby to nebyl problém.. Tahat do toho Mono mi přijde taky dost rizikový.
    Pro předchozí řešení jsem použil 3f/dllexport řešení, který mělo bugy, ale jelo. .NET core to nepotřebuje a po troše práce je zfleku v release asi 2* rychlejší, akorát netušim jak se má pořádně optimalizovat jeho konfigurace ohledně gc, vláken a co jsou problémy nebo bugy. Nejsem sám:)
    SLUPKA
    SLUPKA --- ---
    MAIMONIDES: Řekl bych, že v .NET Core jsou aktuálně spíš bety. Když jsem to dělal naposledy, tak jsem buď udělal C++/CLI mezi vrstvu a nebo jsem využil Mono, které jsem zkompiloval do nativního s API volatelným z C/C++. Pokud se nepletu, tak dneska k tomu míří dva projekty - jeden je automaticky generovaný interop layer (součást Xamarin projektu) a nebo nativní kompilace .NET Core. Ale vzhledem k tomu, jak dlouho to nesleduji, tak netuším v jakém jsou stavu.
    JANFROG
    JANFROG --- ---
    MAIMONIDES: framework
    MAIMONIDES
    MAIMONIDES --- ---
    JANFROG: core nebo framework?
    JANFROG
    JANFROG --- ---
    MAIMONIDES: Jo, tohle jaks taks pujde, hezke to nebude.

    Ja delal genericky interop, aby sli delat callbacky (peknej a nedokumentovanej humus) pripadne chytat CLR vyjimky v tom unmanaged kodu pomoci idiomatickych konstrukci unmanaged jazyka (unmanaged = non-CLR) - taky dobra hnuj, zvlaste v kombinaci s callbackama (delegatama)

    V zasade jsem stravil rok zivota reverse-engineeringem CLR (MS .NET) a muj zaver je, ze z poliickych duvodu MS nechce, aby .NET nekdo pouzival timhle zpusobem a aktivne tomu brani.
    MAIMONIDES
    MAIMONIDES --- ---
    JANFROG: Dík. Ten tvůj pozadavek na dynamičnost omezení já nemám. Je to 'statická' integrace. Zavolám jednu c# fci hnusnym způsobem a ta mi vrátí tunu pointerů na sve sestřičky.
    No jistota tam moc neni:)
    Sranda např je, že ten prevod funkce na handle chce delegata a ten nesmí bejt generickej - nedá se udělat reflexí.
    JANFROG
    JANFROG --- ---
    MAIMONIDES: Kdysi jsem resil neco podobneho. Zaver byl - pokud chces neco slozitejsiho nez trivialni, tak je to hodne komplikovane a nehezke (a hezky to udelat ani nejde). Uz to nechci nikdy v zivote videt.

    Tohle muze pomoci (mozna):

    PROPOSAL: Reintroduce ICorRuntimeHost::DefaultDomain()-sort-of API on Windows · Issue #7107 · dotnet/runtime · GitHub
    https://github.com/dotnet/runtime/issues/7107#issuecomment-610672120
    EUCHRID
    EUCHRID --- ---
    MORMEGIL: Nebudu dělat ani jedno a použiji ten parametrický konstruktor. Máte pravdu, asi to zbytečně komplikuju. Nemám ještě takovou praxi, tak jsem se raději zeptal.
    MAIMONIDES
    MAIMONIDES --- ---
    TOOMIX: Klasickej úkol je pouštět nějaký obskurní starý nativní c++ v zbrusu novém c# gui. To je samozřejmě nuda, kterou umí každej zpaměti.

    Opačnej úkol je mít např c++ síťovej server a business logiku v c#. Čili c++ musí být ten driver a c# je potom volanej z c++ částí.
    Příklad jak to dělat je zde: https://github.com/dotnet/docs/blob/master/docs/core/tutorials/netcore-hosting.md
    Ve frameworku 4.7.2 to mam hotový a funguje to hezky a jednoduchý to neni. V .net core je to trochu složitější a způsobů jak to dělat je víc a chtěl bych vědět, jestli na to jdu dobře a tak..
    TOOMIX
    TOOMIX --- ---
    MAIMONIDES: jak to myslíš, v nativním procesu? Pustit v konzoli jako exe nebo jako windows service?
    MORMEGIL
    MORMEGIL --- ---
    EUCHRID: Jenže ta třída by IMHO měla dávat smysl sama o sobě, neměl bys mít třídu, která jde zkonstruovat jen reflexí. Ale samozřejmě to můžeš vyřešit vhodnými přístupovými právy: třeba ten konstruktor udělat internal, jestli to máš v jednom assembly s tím, kdo to vyrábí. Anebo si z toho udělat interface a mít privátní implementace. Ale je to všechno IMHO zbytečný oser jen proto, abys někomu zakázal vyrábět instance, což taky nechápu, proč se tak bráníš.

    Anebo místo reflexi na callera dej jako jeden z parametrů toho konstruktoru instanci nějaké třídy, jejíž instanci umí vyrobit jen ta databázová třída (public sealed třída s privátním konstruktorem, uvnitř té databázové třídy), tím zajistíš, že ti to nikdo jiný nevyrobí. Ale jak píše MAIMONIDES, je to celé úplně zbytečný fašismus.
    MAIMONIDES
    MAIMONIDES --- ---
    (vím, že to jde, mám sample.. jen bych to chtěl mít trochu příčetněji strukturovaný a pochopitelnější)
    MAIMONIDES
    MAIMONIDES --- ---
    Hostoval jste někdy někdo netcoreapp3+ v nativním procesu?
    MAIMONIDES
    MAIMONIDES --- ---
    EUCHRID: Tak si do veřejného constructoru dej reflexi na callera, která zjistí kdo to volá a řádně to prokádruje ( a když to neni dapper, smaže se z disku ať to uživatel příště ani nezkouší.
    Miluju, když si nižší vrstvy api hrajou na totalitu) .
    EUCHRID
    EUCHRID --- ---
    Jde o to, že nechci, aby ve vyšších vrstvách s některými vlastnostmi někdo manipuloval, ale chci mu umožnit je číst. Veřejný konstruktor s takovými parametry bych dělal jen kvůli db, nikde jinde bych ho ale nechtěl dovolit použít (a tohle by řešilo problém).
    Když udělám parametrický konstruktor, a někdo mi ve vyšších vrstvách vytvoří ten objekt, tak do těch parametrů dá co chce, a tomu se potřebuji vyhnout. Neměl by tyhle položky mít možnost nijak měnit.
    Pokud je tohle to řešení, budu muset nakonec použít parametrický konstruktor, a potom děkuji za radu.
    MORMEGIL
    MORMEGIL --- ---
    EUCHRID: No dobře, ale ten odkazovaný příklad má vedle bezparametrického privátního konstruktoru i normální parametrický, který vše nastaví zcela legálně. Má ho ta tvoje třída? (Tak proč ho nepoužiješ?) Nemá ho? (Proč? Jak si představuješ, že mají legálně vzniknout její instance?)
    EUCHRID
    EUCHRID --- ---
    MORMEGIL: Ony se mají nastavovat jen, když vytahuju objekt z db, nikde jinde. Jak píšu, běžně to dělá i microsoftí EF (https://thedatafarm.com/data-access/entity-framework-private-constructors-and-private-setters/) a s Dapperem to v jiné třídě normálně funguje.
    MORMEGIL
    MORMEGIL --- ---
    EUCHRID: Nechápu, jak se tedy ty hodnoty toho objektu mají nastavovat, když má privátní settery. To je tam nějaká metoda, která jich nastavuje víc najednou, nebo se nastavují jenom v parametrickém konstruktoru nebo jak? (Pokud ten objekt tu vlastnost nastavovat vůbec nedovoluje, tak máš prostě smůlu a _chceš_ ho znásilňovat a prasárna to bude vždycky…)
    EUCHRID
    EUCHRID --- ---
    Zdravím všechny, po mnohahodinovém pátrání se obracím zde, zdali by mi někdo neporadil, nebo nenavedl správným směrem.
    V práci nemůžu používat EF, jen Dapper. Mám objekt, který má některé settery propert privátní, ale jejich hodnoty potřebuji dostat z db do toho objektu. EF to umí (jak to dělá se mi nepodařilo najít, ale nějak vyžívá privátní konstruktor), Dapper také, ale musí se shodovat názvy sloupců v db s názvy propert v objektu. Toho ale nemůžu využít, protože Dapper vyžaduje bezparametrický konstruktor a ten objekt parametry má, takže to v datové vrstvě musím sestavovat pomocí non-generic api, jak to mají popsané v dokumentaci (MojeVlastnost = row.MojeVlastnost). Což mě vrací k problému, že samozřejmě nejde vložit hodnotu z db do property s privátním setterem. Řešení, která jsem našel se mi moc nelíbí: buď to znásilnit pomocí reflexe, nebo mezi db a daný objekt vložit další třídu a slepit to v nějaké továrně (to by šlo, ale zase se musím starat o nějakou mezitřídu). Nebo to vyřešit tím, že se objekt bude umět sám uložit a načíst z db a potom je problém s přístupem vyřešen, ale byl bych raději, kdyby se o databázi starala nějaká třída k tomu určená.
    Nerad bych udělal nějakou prasárnu a fakt si tady nevím rady, ale možná se jenom špatně ptám googlu...
    Nesetkal se někdo s něčím podobným? Mohlo by mě navést i to, jak se to řeší v ado.netu?
    SUBVERSION
    SUBVERSION --- ---
    [ OFFERING WORKNABÍZÍM PRÁCI: junior C++ Software Engineer / Prague / 60000 CZK ] shanime absolventa nebo proste C++ juniora, nevite o nekom? posta pls
    Kliknutím sem můžete změnit nastavení reklam