[RESOLVED] Linker error LNK2022 driving me crazy!

After some code changes introducing an STL/CLR vector member in a class (where it isn't even a member, it's just being passed internally between some member functions) I started getting this bunch of linker errors that I can't for the life of me get rid of:

Code:

---

Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (80131188) : Duplizierte Typen wurden gefunden, aber die Felddeklarationen sind nicht konsistent (Typen: cliext.impl.vector_impl<Kalender::HolidayDescriptor ^,0>; Felder: _Myarray): (0x04000036).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (80131188) : Duplizierte Typen wurden gefunden, aber die Felddeklarationen sind nicht konsistent (Typen: cliext.impl.vector_impl<Kalender::HolidayDescriptor ^,0>; Felder: _Mysize): (0x04000037).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (80131188) : Duplizierte Typen wurden gefunden, aber die Felddeklarationen sind nicht konsistent (Typen: cliext.impl.vector_impl<Kalender::HolidayDescriptor ^,0>; Felder: _Mygen): (0x04000038).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (801311D7) : Unterschiedliche Anzahl von Feldern in duplizierten Typen (cliext.impl.vector_impl<Kalender::HolidayDescriptor ^,0>): (0x02000035).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118B) : Duplizierte Typen wurden gefunden, aber die implementierten Schnittstellen sind nicht konsistent (Typen: cliext.impl.vector_impl<Kalender::HolidayDescriptor ^,0>; Schnittstellen: System.Runtime.CompilerServices.IsConst): (0x0900000b).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118B) : Duplizierte Typen wurden gefunden, aber die implementierten Schnittstellen sind nicht konsistent (Typen: cliext.impl.vector_impl<Kalender::HolidayDescriptor ^,0>; Schnittstellen: System.IDisposable): (0x0900000c).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118B) : Duplizierte Typen wurden gefunden, aber die implementierten Schnittstellen sind nicht konsistent (Typen: cliext.impl.vector_base<Kalender::HolidayDescriptor ^,0>; Schnittstellen: System.ValueType): (0x0900000d).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118B) : Duplizierte Typen wurden gefunden, aber die implementierten Schnittstellen sind nicht konsistent (Typen: cliext.impl.vector_base<Kalender::HolidayDescriptor ^,0>; Schnittstellen: System.Object): (0x0900000e).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118B) : Duplizierte Typen wurden gefunden, aber die implementierten Schnittstellen sind nicht konsistent (Typen: cliext.impl.vector_base<Kalender::HolidayDescriptor ^,0>; Schnittstellen: System.Runtime.CompilerServices.IsImplicitlyDereferenced): (0x0900000f).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118D) : Duplizierte Typen (cliext._Dehandle<Kalender::HolidayDescriptor ^>) wurden gefunden, aber die Typenlayoutinformationen sind nicht konsistent: (0x02000033).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (8013118D) : Duplizierte Typen (cliext.is_handle<Kalender::HolidayDescriptor ^>) wurden gefunden, aber die Typenlayoutinformationen sind nicht konsistent: (0x02000034).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (80131195) : Die benutzerdefinierten Attribute sind nicht konsistent: (0x0c00002d).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (80131195) : Die benutzerdefinierten Attribute sind nicht konsistent: (0x0c00002e).
Holidays.obj : error LNK2022: Fehler bei Metadatenoperation (80131195) : Die benutzerdefinierten Attribute sind nicht konsistent: (0x0c000031).
LINK : fatal error LNK1255: Fehler bei Verknüpfung aufgrund von Metadatenfehlern.

---

Sorry for the German messages. I hope the error numbers and type names are explanation enough. :o

This is the .h file involved:

Code:

---

// Holidays.h

#pragma once

#include <cliext/set>
#include <cliext/map>
#include <cliext/vector>

namespace Kalender {

using namespace System;
using namespace System::Windows::Forms;
using namespace cliext;

typedef map<DateTime,String ^> HolidayMap_t;

[Flags]
public enum class FedState
{
  BadenWuerttemberg = 0x0001,
  Bayern = 0x0002,
  Berlin = 0x0004,
  Brandenburg = 0x0008,
  Bremen = 0x0010,
  Hamburg = 0x0020,
  Hessen = 0x0040,
  MecklenburgVorpommern = 0x0080,
  Niedersachsen = 0x0100,
  NordrheinWestfalen = 0x0200,
  RheinlandPfalz = 0x0400,
  Saarland = 0x0800,
  Sachsen = 0x1000,
  SachsenAnhalt = 0x2000,
  SchleswigHolstein = 0x4000,
  Thueringen = 0x8000,
  All = 0xFFFF,
  None = 0x0000
};

public ref class HolidayDescriptor // : public IComparable
{
public:
  HolidayDescriptor(DateTime ctDate,String ^ctName) : Date(ctDate), Name(ctName), StateMask(FedState::All)
  {}

  HolidayDescriptor(DateTime ctDate,String ^ctName,FedState ctState) : Date(ctDate), Name(ctName), StateMask(ctState)
  {}

/*
  virtual int CompareTo(Object ^other)
  {
    HolidayDescriptor ^temp = dynamic_cast<HolidayDescriptor ^>(other);
    return Date.CompareTo(temp->Date);
  }
*/

  DateTime Date;
  String ^Name;
  FedState StateMask;
};

typedef vector<HolidayDescriptor ^> HolidayVector_t;

public ref class Holidays
{
public:
  Holidays(MonthCalendar ^calNew) : cal(calNew), StateMask(FedState::All)
  {
    AddRegularHolidays();
    AddMovingHolidays(cal->SelectionStart.Year);
  }

  void AddMovingHolidays(int nYear);
  String ^HolidayName(DateTime dat);
  void ResetHolidays(FedState NewStateMask);
  array<HolidayDescriptor ^> ^GetHolidayArray(int nYear);

private:
  MonthCalendar ^cal;
  set<int> YearsCovered;
  HolidayMap_t HolidayMap;
  FedState StateMask;

  static DateTime EasterSunday(int nYear);

  void AddHolidayArray(array<HolidayDescriptor ^> ^aHol);
  void AddRegularHolidays();
  HolidayVector_t ^GetMovingHolidayVector(int nYear);
  HolidayVector_t ^GetRegularHolidayVector();
};

}

---

I omit the Holidays.cpp file for brevity, but of course I may post it too later if it should be of interest.

As mentioned above, the vector is only used internally to the Hollidays class. (Actually, I think I couldn't even expose it if I wanted: I tried and got a compiler error, so I stepped back to expose only arrays.) The HolidayDescriptor is only used internally as well, at least until now. The Holidays class itself is instantiated only once in the entire project, as a member of the main form class.

I typedefed the vector to avoid possible ambiguities caused by typos. I also commented out the IComparable implementation in the HolidayDescriptor class that is yet unused anyway. Both to no avail.

The DateTime and String ^ members in the HolidayDescriptor are CTS types and the FedState is an enum, which IMO essentially is nothing more than an integer and some constants. So I don't see what could be suspected of being of unstable size in there. :ehh:

The MSDN page on that error recommends to do an ildasm -tokens on the object files in questions and compare the results. Unfortunately, my ildasm (version 4.0.30319.1) refuses to process .obj files at all... :(

I also did a forum search (10 threads hit) and a Google search, both of which brought up several pages that looked promising, but none of them seemed to apply to my case here. The most common scenario for that error seems to be a combination of managed and unmanaged code in the same project. But I didn't even use the type in question in more than one managed module... :confused:

So my conclusion is... nothing at all. I'm completely out of ideas yet again. Any advice anyone?

TIA

Use managed collections instead of STL. Managed replacement for STL map is Dictionary:
http://msdn.microsoft.com/en-us/library/xfhwa508.aspx

Thanks for pointing me to the System::Collections::Generic namespace. :) I had already seen it's there, but didn't take a closer look inside.

But the map is not causing the problem, as well as the set. And I found a replacement for the map in System::Collections::Generic, and I think for the set as well, but I haven't seen one that matches the vector, and this is the one causing the problem. Or is it actually there and just has a name under which I didn't recognize it?

The set, map and vector I used are not the STL containers, however, they are STL/CLR containers:

Quote:

---

Originally Posted by MSDN

The STL/CLR Library is a packaging of the Standard Template Library (STL), a subset of the Standard C++ Library, for use with C++ and the .NET Framework common language runtime (CLR). With STL/CLR, you can use all the containers, iterators, and algorithms of STL in a managed environment.

---

And if they shouldn't be used, then why are they there? :ehh:

In the meantime I tried something of which I wasn't even sure if it was allowed at all when it came to mind: make the HolidayVector_t typedef private to the class. I found out that it actually is allowed (I had to qualify all references to it with Holidays:: when used as a function return type for Holidays member functions in Holidays.cpp, though). But this didn't cure the linker errors either. :(

You can use List class instead of STL vector. Regarding STL/CLR containers, I don't have experience using them, and really don't know why they are there... Possibly to give the same syntax for C++ developers familiar with STL. I don't think that many delelopers use it, because using .NET collections is the way compatible with other .NET languages.

Quote:

---

Originally Posted by Alex F

You can use List class instead of STL vector.

---

Thanks, looks good. :) I didn't consider that one on first sight because I confused it with the STL list. Think I'll give it a try later this day.

Do I interpret the docs ritgt that I'll have to implement both IComparable and IEquatable interfaces for the element type, even if I don't use the List methods that rely on them? (And is it correct that there is no non-templated version of IEquatable, as opposed to IComparable?)

I won't touch the STL/CLR set and map members for now, because they work. This will leave me with an inconsistent design, though, at least as an intermediate step. If someone would come around and tell me how I could finally get the STL/CLR vector working, I would be grateful because I could get around finally reworking the set and map parts as well that way. :)

Quote:

---

I [...] really don't know why they are there... Possibly to give the same syntax for C++ developers familiar with STL.

---

Yes, I think exactly this is the reason. :)

There are no any requirements for list<T> element type.

Thanks again for your assistance, Alex F! The CTS List class works like a charm. :)

And it wasn't even that big a deal to change the code: I could do the major part using search & replace. (I did, however only change the faulty code involving the vector yet. Changing the code that uses the other STL/CLR classes is still on the to-do list...)

I'll leave the thread unresolved, though, for a few more days. Maybe someone comes along and tells me what was wrong with my usage of the vector...