What problem does it solve? Developing a native external component for 1C:Enterprise involves undocumented runtime behavior: the platform unpacks only one DLL from the ZIP package, caches installed components by filename, and cannot load dependent DLLs placed next to your component. This Skill captures the official ITS manifest format plus empirically verified ExtCompT behavior so your component actually loads and stays current. ## Core Features & Use Cases - MANIFEST.XML and ZIP packaging: Correct <bundle>/<component> structure for Windows x86/x64, versioned DLL naming to defeat the ExtCompT cache, and build-script packaging guidance. - Native API implementation: The three exported functions (GetClassObject, DestroyObject, GetClassNames), IComponentBase lifecycle, tVariant handling, IMemoryManager allocation rules, and bilingual method/property registration. - Dependent-DLL problem: Locate your own module via GetModuleHandleExW with an in-module anchor, and embed dependencies as RCDATA resources self-extracted to a private directory. - Use Case: Your updated component still shows the old version in 1C — diagnose whether the cause is the ExtCompT filename cache or a stale source ZIP, then apply versioned DLL naming. ## Quick Start Ask the assistant to explain why my 1C native component does not load its dependent DLL after installation and how to fix the packaging.