1c-native-component

Build, package, and deliver 1C native external components on Windows with C++.

Updated May 18, 2025
One-click install
npx skills add https://github.com/VSydorenko/SimplyAddinConnect --skill 1c-native-component-vsydorenko
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: 1c-native-component
Source: https://github.com/VSydorenko/SimplyAddinConnect/tree/main/.claude/skills/1c-native-component
Command: npx skills add https://github.com/VSydorenko/SimplyAddinConnect --skill 1c-native-component-vsydorenko

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about 1c-native-component

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I package a 1C native external component for Windows?

Ship one ZIP containing MANIFEST.XML at the root plus one DLL per supported architecture. Each <component> element declares type="native", os="Windows", arch (i386 or x86_64), and the path to the DLL inside the archive.

Why does 1C keep loading the old version of my external component?

The ExtCompT cache identifies an installed component only by the filename in the manifest path attribute, ignoring content and date. Include a version number in the DLL filename so each new build forces a fresh extraction, or delete the cached file and its registry.xml entry.

Why can't my 1C component find its dependent DLLs after installation?

1C unpacks exactly one file from the ZIP into ExtCompT, so no dependencies sit next to your DLL, and implicit imports resolve relative to the 1cv8.exe host directory. Embed dependencies as RCDATA resources and extract them yourself to a private directory.

How do I get the path of my own DLL inside the 1C host process?

Call GetModuleHandleExW with GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS and the address of a function inside your module, then call GetModuleFileNameW on the returned handle. GetModuleFileName(NULL) returns the path to 1cv8.exe instead.

How should strings be returned to 1C from a native component?

Memory for VTYPE_PWSTR strings and VTYPE_BLOB data returned in a tVariant must be allocated through the IMemoryManager received in setMemManager, using AllocMemory. Memory from new or malloc will not be freed correctly by the platform.

Can extra files be delivered through MANIFEST.XML using a fake arch entry?

No. Adding a fictitious <component> with an unused arch such as ARM does not work, because 1C extracts exactly one file matching the actual OS and architecture of the host process. Use embedded resources or Binary data layouts in the configuration instead.