1

I have a Visual Studio linker error that popped up recently. I stumbled upon a workaround but it is driving me crazy that I can't figure out why it is happening in the first place. I need to learn how to better diagnose it.

So my question is not about how to fix it, but how to diagnose it better. In short what I'm trying to learn here is how to get the linker (or some other tool) to tell me more info about the problem. So this question is not about this particular enum or how I coded it exactly.

The project is a C++/CLI project I have a managed enum which I wanted to refer to in several other header files. So I tried to put a forward declaration of it in the shared file that I use for all my other forward declarations. That started giving me this error.

1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.

OK, fine. My forward declaration probably looks different to the linker than the definition. But I cannot see how the declarations are different in code. And technically, since the linker doesn't even bother to tell me exactly what type is involved I cannot even be 100% sure it's this enum.

So how do I determine following two things?

  1. Exactly what symbol is mismatching AND
  2. Exactly what is the difference (to the linker) between the two versions.

Obviously the first item I probably know. The second, not at all.

What I have tried so far

I've tried setting linker output to full verbosity but it doesn't tell me anything new. Here is the full linker output

1>------ Build started: Project: Core.Sdk, Configuration: Release x64 ------
1>Generating code
1>0 of 1470 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1>  0 functions were new in current compilation
1>  0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
1>LINK : fatal error LNK1255: link failed because of metadata errors
1>Done building project "corecli_v16.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 10 up-to-date, 0 skipped ==========

ILDasm Microsoft recommends trying to use ILDasm for this error but that doesn't work. When I tried using it from the command line as they described, it tells me I have to use it interactive mode. When I then try to use it in interactive mode and open up the .OBJ file in question, it wants an .EXE or DLL, not an .OBJ

MAP File I tried changing the linker settings to generate a MAP file but it never does. So I'm guessing thats not generated unless linking is successful.

Change Something, anything Sometimes the best way to figure out an obscure linker error is to make a change -- any change -- to force the linker to give you a different error so I tried changing the managed enum type to derive from System:UInt32 (a valid thing to do which I do with some of my other managed enums) just to see if I would get a different error. And I did get it to tell me that there were two different definitions of the enum in question, but not what they were. But aside from that, no extra information

But this still leads me to want to see the two definitions side-by-side. Not in code but as the linker sees them. How do I do that?

1201ProgramAlarm
  • 32,384
  • 7
  • 42
  • 56
Joe
  • 5,394
  • 3
  • 23
  • 54
  • 1
    The compiler doesn't know what would be the complete definition if the source code only has a forward declaration.Only at link time, things from differnt compilation units meet, and the linker will find inconsistency. I suggest you could refer to the link:https://stackoverflow.com/questions/12645105/lnk2022-duplicate-managed-types-have-different-visibilities-on-msvs-2012 – Jeaninez - MSFT Nov 21 '19 at 05:41
  • I did see the link you posted when I was searching and one of the workarounds in there is eventually what ended up working for me. But while I very much appreciate your attempt to help,that is really not my question. I'm trying to understand why the linker sees things differently. And *how* it sees them differently. That might help give me a clue as to how I might solve this without a workaround that (to be blunt) should not be necessary. – Joe Nov 21 '19 at 17:14
  • 1
    One scenario for this error is when you are setting a different [visibility](https://learn.microsoft.com/en-us/cpp/dotnet/how-to-define-and-consume-classes-and-structs-cpp-cli?view=vs-2019#BKMK_Type_visibility) for a native element and another include file has already set another visibility. So you will see the linker error "Repeated managed types have different visibility". I suggest we can use the [make_public pragma](https://learn.microsoft.com/en-us/cpp/preprocessor/make-public?view=vs-2019) to give public accessibility to a native type in a source code file that you can't modify. – Jeaninez - MSFT Nov 22 '19 at 03:10

0 Answers0