| Previous | Next |
| TYPE_E_AMBIGUOUSNAME | TYPE_E_UNKNOWNLCID |
TYPE_E_NAMECONFLICT
Name already exists in the type library
TYPE_E_NAMECONFLICT is HRESULT 2147647533 (0x8002802D) from winerror.h. AllStat describes it as “Name already exists in the library.” The value must be interpreted at type-library creation when adding a type, member, alias, or module symbol, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the proposed identifier conflicts with an existing identifier under OLE name-comparison rules. The operational record for this HRESULT needs the native value, symbolic constant, component build, and call phase; the message alone is insufficient.
Where the result appears
- This result belongs to type-library and metadata processing around type-library creation when adding a type, member, alias, or module symbol.
- identify the LIBID, major/minor version, LCID, SYSKIND, file path, resource ID, and the specific ITypeLib or ITypeInfo operation.
- Metadata consumers should treat this result as a contract-version or construction problem until file integrity, registry view, import dependencies, TYPEKIND, and builder phase are verified.
Separate caller state from runtime and server state first; otherwise cleanup and retry may target the wrong generation of the operation.
Typical causes and interpretation boundary
Common cause categories for this HRESULT are: duplicate source declarations; case-only differences; imported aliases collide; generated accessor names duplicate explicit methods. Each possible cause of this result predicts different outputs and recovery behavior, which should be verified explicitly.
The check that separates this result from nearby HRESULTs is: the proposed identifier conflicts with an existing identifier under OLE name-comparison rules. Without proof of the distinguishing condition for this HRESULT, the safest action is to preserve evidence and refrain from destructive cleanup.
Evidence and telemetry
- Record it with the type-library path and hash, LIBID and version, LCID, architecture, source package, and producer toolchain.
- capture new name; existing element; scope; LCID and case; MEMBERID; generator source symbol.
- Retain the exact type, member, field, name, MEMBERID, HREFTYPE, TYPEKIND, or registry path involved in it.
- When it is produced during generation, record construction order, imported libraries, layout/finalization state, and output TLB hash.
- After it, release TYPEATTR, FUNCDESC, VARDESC, BSTR, and interface resources using the matching API even when parsing or lookup fails.
A useful it event contains ownership and shape information, not raw documents, passwords, access tokens, or full Automation values.
Diagnostic sequence
- Capture it (0x8002802D) before a compiler, importer, or language runtime reduces it to a generic metadata error.
- Verify the exact type-library identity, file/resource loaded, registry view, architecture, and operation that returned it.
- Prove the decisive metadata condition for this HRESULT: the proposed identifier conflicts with an existing identifier under OLE name-comparison rules.
- Test the likely causes independently for this HRESULT: duplicate source declarations; case-only differences; imported aliases collide; generated accessor names duplicate explicit methods.
- For <code>it</code>, enumerate the relevant TYPEATTR, members, imports, names, IDs, locales, and builder state instead of assuming source declarations match deployed metadata.
- Rebuild or reload one corrected metadata generation and verify that it disappears without introducing a different identity or compatibility break.
Correct handling and recovery
The appropriate recovery is to choose a unique Automation-visible name, keep stable DISPIDs where compatibility matters, and regenerate all dependent bindings. Repeat the operation only after the failed condition has changed and the caller can distinguish a duplicate effect.
When it is returned, use the documented output contract and reconcile remote or persistent effects before replaying the request.
Practical scenario
A property named Count generates get_Count while a method already uses the same Automation name; the exporter renames the method explicitly.
An automated test for this HRESULT should verify raw HRESULT, output ownership, cleanup behavior, and the absence of an unsafe automatic retry.
Difference from related HRESULTs
TYPE_E_AMBIGUOUSNAME describes lookup among existing candidates; it prevents creating the duplicate.
The comparison matters operationally for this HRESULT: one result may permit fallback while the other requires repair, cancellation, or state reconciliation.
Developer and administrator guidance
Tools handling it should pin type-library identity and version, avoid caching raw indices across versions, and preserve stable GUIDs and DISPIDs for published contracts. Repair for <code>it</code> should be performed by the metadata producer or installer, not by ad hoc registry edits in the consuming process.
Administrators should compare installed files and registration against the product manifest, repair the matching package, and keep 32-bit and 64-bit registry views explicit. For <code>it</code>, copying a TLB from another machine can silence lookup while creating a more dangerous ABI mismatch.
References
Looking for a different code? Search another status or error code.