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.

Jo, díky :-)
Oni se ohánějí tím, že jsou to senior programátoři, ale očividně nejsou dost senior. Mimochodem server je napsanej v PHP a z .Net je to strašná pruda se k tomu připojit.
Souvisí to s tímhle postem ve vedlejším klubu: [MORIARTY @ db -1/0 @ slyším Alenky v říší <div>ů následovat stream do backdooru]

CERMI_FOX: no jasne - je to naprosta kokotina :)

MORIARTY: jiny NS urcite byt muze, ale teda smysl to moc nedava a je to, cituji, kikotina

Ahoj, měl bych jeden asi trapnej dotaz ohledně příbuzné technologie.
Konzumuju jednu webovou službu a mám s vývojářema serveru spor ohledně implementace. Jde mi to to, že ta služba má WSDL, které je jiné pro devel a test prostředí. Liší se atributem TargetNamespace:
https://autovraky.mzp.cz/autovrak/service/wsdl/v6 (xmlns:tns="https://autovraky.mzp.cz/autovrak/service/v6/")
https://autovraky-test.mzp.cz/autovrak/service/wsdl/v6 (xmlns:tns="https://autovraky-test.mzp.cz/autovrak/service/v6/")

Podle mě by se WSDL nemělo měnit v závislosti na prostředí, je to datový standard. Podle nich je hloupost, že by TargetNamespace byl stejný na dvou serverech.

No, výsledek je, že mi .Net neumí deserializovat XML z testu na devel WSDL a naopak a musím před deserializací injektovat do XML správný namespace. Oni tvrdí, že je to normální a že v Delphi a PHP jim to funguje bez problémů (není divu, když oba jazyky neumí používat namespace).

Mám pravdu já, že WDSL je neměnné, a nebo oni, že může být na každém serveru jiný TargetNamespace?

Děkuji za tip. Na to se ještě podívám. Teď mi to chodí přes Console.ReadKey, ale nejspíše jenom proto, že to běhá v popředí.

SLUPKA: Jo, je tam RaspberryPi OS. Nejsem linuxák, ale tolik vím, že by to nějak takto asi taky šlo. Ovšem raději bych to měl jako "managed" kód, relativně nezávislý na OS.

Včera jsem něco našel, tak to zkouším přepsat, jestli to bude fungovat přes Console.KeyAvailable a Console.ReadKey. Ale ono to bude asi fungovat jenom když bude aplikace v "popředí". No, ale v nouzi to tak holt bude. Vzhledem k tomu, že to je zadeklovaný bez jiných vstupů a výstupů...

PECA: A co používáš za operační systém? Raspbian? Tam by tu události měly být dostupné na něčem jako /dev/input/event0, ne? Nevím, jestli na to .NET Core má nějakou metodu, ale v nejhorším případě můžeš volat libc napřímo.

C#, dotnet core 3.1
Mám službu (daemona). Běží to, čte to data z 1Wire sběrnice (Id čipy). Teď potřebuji, aby to četlo i klávesnici a pokud to bude mít správný pattern, tak zpracovat. Technicky jde o vyhození původní 1Wire čtečky a nahrazení za USB čtečku, která simuluje klávesnici.
Běhá to na Raspberry Pi, není možné řešit hákem přes user32.dll - na což narážím na každém rohu. Můžete mě někdo popostrčit ke správnému řešení prosím?

VIRTUALVOID: proc? za me zatim rider plna spokojenost. jen jednou se mi zblaznil editor a zacalo to skakat sem a tam a musel jsem ho restartovat