Tag Archives: Build

WASM: AggregateException_ctor_DefaultMessage (Could not resolve type with token …)

Narazili jsme po instalaci .NET 9 SDK 9.0.204 (a nepomohl ani 9.0.300) na zajímavou chybu published Blazor WebAssembly front-endů (browser console výstup, front-end nenabíhá):

ManagedError: AggregateException_ctor_DefaultMessage (Could not resolve type with token 01000024 from typeref (expected class 'System.Reflection.Assembly' in assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'))
    at an (dotnet.runtime.5nhp1wfg9b.js:3:26894)
    at Kt.resolve_or_reject (dotnet.runtime.5nhp1wfg9b.js:3:26449)
    at dotnet.runtime.5nhp1wfg9b.js:3:172714
    at dotnet.runtime.5nhp1wfg9b.js:3:172778
    at fr (dotnet.runtime.5nhp1wfg9b.js:3:35046)
    at Fc (dotnet.runtime.5nhp1wfg9b.js:3:172361)
    at dotnet.native.swgexbmoy7.wasm:0x1f1a4
    at dotnet.native.swgexbmoy7.wasm:0x1c8ae
    at dotnet.native.swgexbmoy7.wasm:0xea19
    at dotnet.native.swgexbmoy7.wasm:0x1ec88

První podezření bylo na trimming, nicméně když to zkrátím, tak se ukázalo, že se jedná o klasický problém buildů po instalaci nového SDK – je potřeba vymazat pracovní složky build-agentů, pokud každý váš build neběží na úplně čistém prostředí, ale používáte nějakou formu inkrementálního uspořádání. Když to převedu do roviny lokálního vývoje s Visual Studiem, je potřeba udělat Clean solution a vymazat složky bin a obj.

Proč to vůbec píšu? Kdyby někoho potkala stejná chyba, při troše štěstí vygooglí tento post a ušetří si čas s diagnostikou. U nás už jsme si poměrně zvykli, že když po instalaci nové verze SDK padá build, je potřeba před dalším bádáním vymazat pracovní složky build-agentů. Poprvé v historii se nám však stalo, že build úspěšně prošel (nepadal), ale výsledek build byl „vadný“ způsobem, který se projevil až při spuštění Blazor WASM front-endu v browseru.

YAML Pipelines – Azure DevOps [Jiří Kanda, Vzdělávací okénko, 27.3.2025]

Zanechat odpověď

V tomto videu se dozvíte vše o našich nových YAML pipelines v Azure DevOps, které prezentuje Jiří Kanda. Jirka vysvětluje, proč jsme se rozhodli přejít na YAML pipelines a jaké výhody nám to přináší.

Specifika našich buildů a důvody pro změnu na YAML pipelines.
Výhody YAML pipelines, jako jsou lepší parametrizace a paralelizace.
Základní syntaxe YAML a struktura YAML pipelines.
Paralelní běh jobů a použití více agentů.
Volitelné parametry buildů a task scheduler.
Podpora pro integrační testy a automatické pull requesty.
Použití deduplication a reprodukovatelnost buildů.
Validace zranitelností nuget balíčků a definice pipeline v projektech.
Problémy s manuálním spuštěním buildů.

Záznam ze Vzdělávacího okénka HAVIT z 27. března 2025.

ASP.NET Core včera, dnes a zítra [Miroslav Holec, HAVIT Vzdělávací okénko 3.5.2018]

Zanechat odpověď

Záznam ze Vzdělávacího okénka HAVIT z 3. května 2018, kde Miroslav Holec prezentoval historii [ASP].NET Core a chystaných novinkách ve verzi 2.1. Nahrávka je publikována na našem HAVIT YouTube Channelu.

Textovou podobu informací najdete na Mirkovo blogu:

https://www.miroslavholec.cz/blog/cesta-k-aspnet-core-2-1-aspnet-core-runtime-a-shared-frameworks

TFS Build Process [Jiří Kanda, HAVIT Vzdělávací okénko 1.3.2018]

Zanechat odpověď

Záznam ze Vzdělávacího okénka HAVIT z 1. března 2018. Je publikován na našem HAVIT YouTube Channelu. Téma prezentoval Jiří Kanda.

Dotčená témata:

MSBuild
- csproj
- MSBuild command line
- build tools
- parametrizace
- nástroje
TFS Build
Publish

NPM as a build tool – záznam [Vít Heřman, HAVIT Vzdělávací okénko 27. 4. 2017]

Zanechat odpověď

Záznam z interního vzdělávacího okénka HAVIT z 27.4.2017 je publikován na našem HAVIT YouTube Channel. Téma prezentoval Vít Heřman:

Dotčená témata:

Grunt
Gulp
Webpack
NPN
NPN scripts
Pre a post skripty

TFS (XAML) Builds – Jak vytvořit lokální workspace

Zanechat odpověď

TFS (XAML) Build vytvoří workspace na build serveru, do něj stáhne zdrojové kódy a ty kompiluje. Workspace vytváří aktivita CreateWorkspace, která vytvoří serverový workspace a není způsob, jak této aktivitě říct, aby vytvořila workspace lokální. Aktivita CreateWorkspace navíc vrací instanci reprezentující založený workspace.

Když tedy nelze při říct, že založený workspace má být lokální, lze použít drobný workaround – založit workspace jako serverový a dodatečně jej přepnout na lokální. To lze provést zavoláním metody Update na instanci vrácené z CreateWorkspace. V rámci TFS (XAML) Buildu to můžeme udělat reflexí, tedy aktivitou InvokeMethod s těmito parametry:

Target Object: Workspace (resp. taková proměná, ve které máme vrácenou instanci z activity CreateWorkspace)
Method Name: Update
Parameters: In / Microsoft.TeamFoundation.VersionControl.Client.UpdateWorkspaceParameters / New UpdateWorkspaceParameters With { .Location = Microsoft.TeamFoundation.VersionControl.Common.WorkspaceLocation.Local }

O rozdílech mezi lokálním a serverovým workspacem si můžete přečíst tady nebo tady. Naše touha pro přechod ze serverového na lokální workspace byla vedena přiblížením prostředí buildu vývojářskému prostředí, zejména nenastavení read-only atributů na stažených souborech.

API restriction: The assembly “file:///…Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll‘ has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.

Zanechat odpověď

Pokud se s touto chybou potkáte ve Visual Studiu, nejspíš se vám podaří něco kolem toho vygooglit. Zákeřnější je tato chyba na TFS Build Serveru, kde jsou postupy nalezené k většinou VS irelevantní.

Obvyklou příčinou je, že se vám na Build serveru spouští při testech něco víc, než plánujete.

Například

patternu pro assemblies s unit-testy odpovídá i jiný projekt, v mém případě např. TestHelpers.dll se sdílenými pomůckami nečekaně spadl do výchozího patternu „*test*.dll“, který na konkrétním buiĺdu nebyl změněn za námi používanou konvenci „*Tests.dll“. Můj TestHelpers.dll referencuje také Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll a chyba byla na světe.
pattern pro assemblies s unit-testy najde vaše testy vícekrát v různých složkách. Pomoct by mělo změnit pattern z „**\*test*.dll“ na „*test*.dll“, aby se obešel folder-matching.