INTER_MAN: Jo, díky. To vypadá nadějně. Píše mi to teda během publishe, že to nepodporuje Compute Module 4, ale to snad bude otázka změny pár řádků kódu v tom extension, ten CM4 by měl být identickej jako Pi 4.

URZA: Problém není udělat jednotlivý ty kroky (build, publish, debug) jednotlivě, ale udělat je najednou a automaticky. Snad to řeší to co posílal INTER_MAN, zkusím si s tím trochu pohrát a dám vědět.

RORSCHACH: https://marketplace.visualstudio.com/items?itemName=neonFORGE-LLC.RaspberryDebugger - nezkoušel jsem, ale vypadá to nadějně.

RORSCHACH: tvl to je solidni abuse :-D

CERMI_FOX: Asi jsem špatně vysvětlil, co hledám. Já nemám problém to na tom Linuxu buildnout nebo spustit. Problém je to udělat nějak pohodlně přímo z Visual Studia. Prostě chci programovat v pohodlí Windows, ale spouštět to na Linuxu, kde mám na GPIO připojený hardware, který v tom .NETu ovládám. V C++ projektu to Visual Studio udělá všechno za mě. Stačí dát debug a všechno se stane automaticky na Linuxu (nahrajou se tam zdrojáky, buildnou se, spustí se ten projekt a připojí se k němu debugger, viz. obrázek). Pro .NET tuhle možnost nikde nevidím, což mi přijde docela divný. Čekal jsem, že situace bude lepší než u C++, když Microsoft .NET na Linuxu tak tlačí :)

RORSCHACH: pokud máš .net core, tak nic takového není třeba - při publishi si jde zvolit, jestli appka má být platform independent (tedy poběží na libovolném z podporovaných. raspi není problém, používám) nebo jestli se má publishnout přímo pro danou platformu.
Debugger jsem nezkoušel, nicméně zjevně to jde přes ssh https://docs.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019

Pokud jsi nucen jet na "klasika" .NET Frameworku, tak je to horší, ten ofiko na Linuxu nejede vůbec, existuje port Mono (sežere stejné binárky jako pro Windows, takže není potřeba speciální kompilace), ale bylo to takové smutné.

OK, díky.

Trošku mimo téma, ale třeba mě nasměrujete:

Potřebuju několik tisíckrát zopakovat akci v browseru typu "Jdi na stránku X" (ta je pokaždé stejná), "Najdi první odkaz za textem ABCD", "Klikni na tento odkaz (ať už zní jakkoliv)" atp. Je nějaký vhodný plugin, který by mi umožnil něco takového nahrát/naklikat jako makro a pak to spustit s pár tisíc opakováními (a nezbytnými pár sekundovými pauzami mezi tím)?

EMBI: koukal, podle toho jsem dottrace nastavil.
Co mi přinese ruční IAsyncStateMachine? Já vím, o který await (v mém kódu) jde, to jsem si našel stopwatchem, nicméně za tím awaitem je skrývá spousta 3rd party kódu, kde se pracuje se sítí, a vzniká tam spousta tasků; zajímá mě právě pohled dovnitř.
ANTS jsem zkoušel, ale padá mi na různé velmi deskriptivní chyby jako E_FAIL nebo obecnější "failed".

CERMI_FOX: Koukal jsi na https://www.jetbrains.com/help/profiler/Analyzing_Async_Calls.html ? Co prepsat async/await na IAsyncStateMachine (tj. bez klicovych slov) a pak zkusit profiler?

Redgate profiler ma 14 denni free trial https://www.red-gate.com/products/dotnet-development/ants-performance-profiler/

potřebuju nějaký profilovací nástroj pro async/awaity (.NET Framework klasický). Řeším problém, že rutina by měla trvat řádově desítky ms (pokud ji vyextrahuju mimo aplikaci do benchmarku, tak i tak trvá, takže problém bude nejspíš v kombinaci technologií v aplikaci, je to celkem velká aplikace), nicméně přes StopWatch hodně často trvá i desítky sekund, bez nějakého většího zatížení systému. CPU nevytěžuje. Potřebuju zjistit, na čem ta rutina tráví čas, velmi pravděpodobně awaití nějaký task z TCS. Potřeboval bych zjistit který a odkud se bere. Ta rutina rutina volá hlavně kód třetí strany (celkem velká knihovna), který je opensource, ale moc se v něm nevyznám, takže se nechci pouštět do velkých úprav.
Existuje nějaký nástroj, který by mi řekl, "tvoje metoda XY z 78% awaití task, který vznikl v NějakáClass.Metoda, 10% awaití jiný task, zbytek pak je CPU práce" ?
Zkoušel jsem dotTrace, ten mi řekne, že 99+% se tráví na awaitu a to je vše, neřekne mi, co to je za Task.
Zkoušel jsem Performance profiler z Visual Studia, ten bohužel vždy selže na chybě "Merging of ETL files has failed (0x8007007b)."
Nějaké nápady, co použít? Klidně placený soft, je to důležité a zároveň začínám být zoufalý

URZA: SAML2 je úplně v pohodě, sice není úplně módní, ale aspoň je k tomu určenej (na rozdíl od různých přibastlených protokolů nad Oauth2). Horší je, že to maj poněkud zprasený (to entity ID!!).

MORIARTY: Standard je přeci ohlásit, že změna nastala a vývojáři klientských SW posertese... Musím tedy uznat, že někdy se tyhlety změny ohlásí i 14 dní dopředu, než to přepnou. Sice se pak taky třeba stane, že ohlášená změna (API) je pak ve skutečnosti jiná, takže to stejně musí předělat, ale že se to podělá bylo ohlášeno dopředně :)
// no, zas taková sranda to není, když pak suplujeme support MZe

URZA: No, já teď navíc začínám programovat připojení k novýmu přihlašovacímu systému MŽP. Dělají to od začátku v SAML2, ten protokol si trochu ohýbají, takže kdoví, jestli ho to vůbec bude připomínat.
No a chtějí to spustit k 1.1.2022, takže aplikace třetích stran mají na úpravu přihlašování půl roku a většina z jejich vývojářů ještě ani neví, že se něco chystá :)

SHIGORBIRDMAN: Znamej ted servisuje stand-alone stanici napsanou v Turbo Pascalu a MS-DOS. Kdyz ma firma napsano neco stareho a stale to udrzuje, tak to povazuju spis za pozitivum. Takovych tech rapid update firem uz tu bylo...
Se senioritou a senilitou to asi nebude mit spolecneho tolik, jako s jejich naprostym kokotismem. Pardon my french.