locked
warning LNK4248: unresolved typeref token (01000017) for '_TREEITEM'; image may not run RRS feed

  • Question

  • When compiling my program which is a windows app and not a DLL, I get this error message under Release mode but not in Debug.

    Furthermore I can get rid of the warning if I don't use managed extensions (remove \clr) in the project properties.

    Is there not some releases source code from Microsoft to allow the _TREEITEM and _IMAGELIST object to run in managed extensions?  I thought the goal from MS was to have us use the managed extensions and therefore I would think that this situation would have been resolved a long time ago.

    I've read the link where this exact same error is generated with a DLL but this is a standard windows app and therefore doesn't have a DLLMain code.

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=77508&SiteId=1

    The application seems to run just fine even though I've received the linker error.  What should I do?  Not use \CLR or use \CLR and ignore the warnings?

    Thanks Chris

    Friday, February 16, 2007 1:35 PM

Answers

  • What you get is a typical case of something like this:

    struct incomplete;
    typedef incomplete* handle;

    handle get_handle() { return 0; }

    int main()
    {
     get_handle();

    That´s perfectly valid C++. What the compiler does is to create a ValueType for each native type (it doesn't really emit members, however. Rather it just does its own binary layout - after all it must interface to its generated native code - and just inform the CLR about the alignment and size to reserve). Now, in this example the implementation of get_handle uses a reference to the value type incomplete to form a managed type signature. Apparently,  when the linker sees the input it will synthesize an definition for incomplete (this is require for a valid CLR image). And that is what the warning is about.

    I´m having a very hard time imagining a case where that would break real-world code. I think it´s perfectly safe to simply ignore the warning (since it is incomplete in C++ code, objects of that type cannot be accessed).

    Now, I´m not sure what _TREEITEM is but maybe it is just the underlying incomplete type for HTREEITEM used by the Tree Common Control. So when you use this type in a signature somewhere in your code (even as part of a header file - e.g. MFC or WTL headers have these in their wrappers) you´ll get the warning.

    So chances are you can simply ignore the warning. And yes, I believe the text of the diagnostic is poor as is the documentation, and it would certainly have been possible to emit additional information in the object file to signal the linker that the warning could be suppressed.

    -hg

    Saturday, February 17, 2007 4:52 PM

All replies

  • Furthermore I can get rid of the warning if I don't use managed extensions (remove \clr) in the project properties.

    That is so because the error means a type doesn't have a definition in the MSIL metadata. If you don't use C++/CLI, but unmanaged C++, there is no MSIL data.

    From MSDN:

    LNK4248 can occur when there is only a forward declaration for a type in an MSIL module (compiled with /clr), where the type is referenced in the MSIL module, and where the MSIL module is linked with a native module that has a definition for the type.

    In this situation, the linker will provide the native type definition in the MSIL metadata, and this may provide for the correct behavior.

    However, if a forward type declaration is a CLR type, then the linker's native type definition may not be correct

    For more information, see /clr (Common Language Runtime Compilation).

    Friday, February 16, 2007 1:53 PM
  • Marius,

    Your response, as you stated.  Is in the MSDN and I already read it.  Unfortunately it doesn't answer my question.

    My question is when is MICROSOFT going to compile their OWN CODE with clr option? 

    Why would MICROSOFT develop this option on thier compiler if they don't even compile their own code with managed extensions?  In case you are wondering the _TREEITEM and _IMAGELIST are both part of MFC and are not my code.  Yes I do link to the MFC libraries which is where the error is coming from.  Therefore the solution I'm looking for is how to get around a failure from MICROSOFT to follow their own documentation?

    If managed extensions for C++ is the "solution" proposed my MS then why is it that they can't compile their own code using these managed extensions, or failing that, wrap them in a seperate class like they did everything else.  If they have done this and that is availble in MFC then please let me know how to proceed.

    Taking an existing MFC app and converting it to C# (visual basic with C syntax) is not a solution.

    If the only solution is to simply compile without /clr then that is what I've done.

    Chris

     

     

    Friday, February 16, 2007 10:21 PM
  • What you get is a typical case of something like this:

    struct incomplete;
    typedef incomplete* handle;

    handle get_handle() { return 0; }

    int main()
    {
     get_handle();

    That´s perfectly valid C++. What the compiler does is to create a ValueType for each native type (it doesn't really emit members, however. Rather it just does its own binary layout - after all it must interface to its generated native code - and just inform the CLR about the alignment and size to reserve). Now, in this example the implementation of get_handle uses a reference to the value type incomplete to form a managed type signature. Apparently,  when the linker sees the input it will synthesize an definition for incomplete (this is require for a valid CLR image). And that is what the warning is about.

    I´m having a very hard time imagining a case where that would break real-world code. I think it´s perfectly safe to simply ignore the warning (since it is incomplete in C++ code, objects of that type cannot be accessed).

    Now, I´m not sure what _TREEITEM is but maybe it is just the underlying incomplete type for HTREEITEM used by the Tree Common Control. So when you use this type in a signature somewhere in your code (even as part of a header file - e.g. MFC or WTL headers have these in their wrappers) you´ll get the warning.

    So chances are you can simply ignore the warning. And yes, I believe the text of the diagnostic is poor as is the documentation, and it would certainly have been possible to emit additional information in the object file to signal the linker that the warning could be suppressed.

    -hg

    Saturday, February 17, 2007 4:52 PM
  • So chances are you can simply ignore the warning. And yes, I believe the text of the diagnostic is poor as is the documentation, and it would certainly have been possible to emit additional information in the object file to signal the linker that the warning could be suppressed.

    -hg


    Unfortunately, I work on a project where no warnings are tolerated.  It has been useless trying to point out that this is a *linker* warning and therefore cannot be disabled like compiler warnings, to no avail.

    We need to either:

    1) Eliminate this warning, as it seems to be harmless in 99% of situations OR
    2) Offer a mechanism to explicitly disable this linker warning

    Thursday, June 4, 2009 12:32 AM
  • I get the following when I added single instance support according to Microsoft's web page.

    http://support.microsoft.com/default.aspx/kb/243953

     warning LNK4248: unresolved typeref token (01000017) for 'AFX_CMDHANDLERINFO'; image may not run
     warning LNK4248: unresolved typeref token (01000010) for 'AFX_CMDHANDLERINFO'; image may not run
     warning LNK4248: unresolved typeref token (01000016) for 'IAccessibleProxy'; image may not run

    I had to add the following to make it compile/link:

    In the right pane, click to select Common Language Runtime Support, Old Syntax (/clr:oldSyntax) in the Common Language Runtime support project settings.

    They appear harmless, but these warnings should not occur in a "official" recommendation. (Obviously these did not occur before I added this single instance test).



    Friday, June 5, 2009 11:27 PM
  • I had the same problem.

    To resolve :
        -> Property Page -> Linker -> Optimization ->Reference set to Default   
        -> Property Page -> Linker -> Optimization ->Enable COMDAT Folding  set to Default

    No more linker warning and the app works fine...

    I hope it will help you.
    Thursday, June 25, 2009 9:34 AM
  • This really isn't a problem, its a compiler anomaly that users have no control over. A project manager who doesn't tolerate warnings, especially this one, is too anal-retentive and myopic. If you don't want to see this warning then don't use Microsoft's compiler (good luck finding something that compiles managed C++), or don't use managed code.

    By the way, the fix proposed above by BPG77 didn't work for me. The defaults for those settings are the settings you propose to fix the warning. After doing a little research I decided to ignore it. No choice. There is no fix, and it doesn't really break anything anyway. The result of being able to use a DataGridView using C++ Interop in my project's CDialog class are too beautiful for any meaningless warning to deny.
    Thursday, July 16, 2009 4:21 PM
  • Under Configuration Properties -> Linker -> Command Line -> Additional options, add "/ignore:4248" (without the quotes).

    That should supress any LNK4248 warnings (actually it does, I was looking for a solution for one of my own projects, and it did work).

    Another possibility would be to add a dummy-definition for the "missing" types. E.g. add a "LNK4248Workaround.cpp" File:

    #include <afx.h>
    
    struct _TREEITEM {};
    struct _IMAGELIST {};

    I haven't tried the latter, and I wouldn't do it if I didn't have to because I consider it to be an ugly hack, but I'm pretty sure it should work.
    • Proposed as answer by azzwin Wednesday, August 18, 2010 1:22 PM
    Thursday, January 7, 2010 7:57 PM
  • /ignore:4248 worked like a charm. Thanks!
    Tuesday, February 22, 2011 6:33 PM
  • The band-aid makes the warning go away - but this is not a safe solution.

    In my case, using /clr and including both afxcmn.h and afxwinforms.h so that I can include C# controls in MFC dialogs (as described by MSDN articles), I was getting the _TREEVIEW and _IMAGELIST warnings, which derive from the Microsoft CTreeCtrl support, but I was also getting the same warning message for one of my own enumerations.

    My program was crashing in strange ways until I fixed my problem.  If I had the /ignore on from the beginning, I would not have known about my problems and it would have been much more difficult to resolve the problem.

    This sequence started in 2007.  It is now 2014 and this problem is still present in Visual Studio 2013.  Isn't it about time for Microsoft to resolve the problem properly?

    Sunday, April 20, 2014 12:27 PM
  • "My program was crashing in strange ways until I fixed my problem." - would like to hear what you did to fix, as I am experiencing strange crash after adding /clr switch -- everything builds, but I do get the warning about _TREEITEM & "image may not run"
    Wednesday, October 15, 2014 5:15 PM
  • I have encountered the same problem, "warning LNK4248: 无法解析 typeref 标记(0100000F)(为“_TREEITEM”);映像可能无法运行".

    I am looking forward for your answer if you have resolved this problem.

    Thanks.

    Tuesday, March 7, 2017 6:19 AM