• ú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 --- ---
    TOOMIX: Na .NET 5 se těším. Moc jsem ještě nezkoumal co je vše nového, ale možnost používat nugety z F# skriptů mi přijde naprosto skvělé. To je něco co chybí už strašně dlouho.
    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.
    TOOMIX
    TOOMIX --- ---
    Zkoušel jste už někdo .NET 5 Preview 2? Nějaký zásadní změny oproti .NET Core 3.1?
    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.
    Kliknutím sem můžete změnit nastavení reklam