• ú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
    FONTAN
    FONTAN --- ---
    snazim se najit a prijit na to, proc/zda to nejde

    netusite nekdo?

    potreboval bych z c# aplikace na win 10 tuknout na namapovany drive tak, aby se pripojil - credentials jsou ulozeny - jakoze mam mapping R: -> //10.10.10.10/shared_folder - a potreboval bych zajistit, ze vim, ze bude dostupny v prubehu behu aplikace (lze to udelat az pote, co se uzivatel pripoji na VPNku) - jenze zatim vsechno mozne konci na vyjimce "Could not find a part of the path" a podobne

    jakmile drive rozkliknu v exploreru, tak se to samozrejme rozjede

    (a je mi jasny, ze to jit musi, protoze souborove managery - treba servant salamander - to umi/delaji)

    jen jsem asi google koste :(
    NECROMAN
    NECROMAN --- ---
    Před hodinkou začala Build konference online:
    https://mybuild.microsoft.com/
    NECROMAN
    NECROMAN --- ---
    TOOMIX
    TOOMIX --- ---
    Windows Task Dialog · Issue #146 · dotnet/winforms · GitHub
    https://github.com/dotnet/winforms/issues/146
    MORMEGIL
    MORMEGIL --- ---
    NECROMAN: Já na to mám už nevímjakdlouho nakonfigurovaný Redirector. Někdo ty moje pravidla dokonce vyexportoval: https://uloz.to/file/jvBOnhYlBFOk/redirector-json (disclaimer: není moje)
    NECROMAN
    NECROMAN --- ---
    Pokud také nemáte rádi to, že se vám samovolně přepínají MSDN stránky či jiné weby Microsoftu na češtinu, tak doporučuji tento doplněk, který automaticky přesměruje stránky zpět na angličtinu:
    FFS MSDN in English
    FFS MSDN in English - Internetový obchod Chrome
    https://chrome.google.com/...tail/ffs-msdn-in-english/ddaknggefjjgpnlhiejepbiplceedmfl/related?hl=cs
    SLUPKA
    SLUPKA --- ---
    MAIMONIDES: Tohle je na přechodu mezi nativním a managed otravné. Musíš dělat to samé i když voláš nativní funkce z managed a předáváš cokoliv pomocí pointeru. Jinak nemáš zaručeno, že ten pointer bude platný ani po celou dobu volání té funkce. Už i předávání stringu z managed do nativního je tím ovlivněné, případně jakékoliv struktury předávané jako reference nebo obsahující pointery.
    MAIMONIDES
    MAIMONIDES --- ---
    SLUPKA: Jojo, akorát v té syntaxi, v jaký to je, to vypadá, že si to drží sami. člověk musí ten delegát ručně vyrobit new delF(F) a držet/uvolnit.
    SLUPKA
    SLUPKA --- ---
    MAIMONIDES: Nechybí ti tam GCHandle.Alloc na ten delegate (a uvolnění na konci). Jinak nemáš zaručeno, že se ti ten callback nebude přesouvat v paměti. Nebo se pletu?

    How to: Marshal Callbacks and Delegates By Using C++ Interop | Microsoft Docs
    https://docs.microsoft.com/...w-to-marshal-callbacks-and-delegates-by-using-cpp-interop?view=vs-2019
    MAIMONIDES
    MAIMONIDES --- ---
    Tak se s váma podělímo o zkušenost..
    Jak jsem psal níže, fce z managed do native exportuju takhle..
    l.InstanceManagerInit = Marshal.GetFunctionPointerForDelegate<ExportList._dInstanceManagerInit>(ManagedInstanceManager.InstanceManagerInit);

    Funguje. Pokud v nějaký c# fci zavolam GC.Collect(10, GCCollectionMode.Forced, true); tak příští managovanej call naprosto kouzelně selže..
    Pokud alokaci předělám na
    testdel = new ExportList._dInstanceManagerInit(ManagedInstanceManager.InstanceManagerInit);
    l.InstanceManagerInit = Marshal.GetFunctionPointerForDelegate(testdel);

    tak to začne fungovat.. Kouzelný.

    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
    Kliknutím sem můžete změnit nastavení reklam