fatal error C1190: managed targeted code requires a '/clr' option

Answered fatal error C1190: managed targeted code requires a '/clr' option

  • Thursday, February 23, 2012 10:12 PM
     
     

    I am working on a legacy application that is in native C++.

    I need to add calls to a C# managed DLL (COTS).  I have been trying to follow the sample code in several examples that address native code calling of managed code.  I have created a mixed mode wrapper dll.  When I add #using of the wrapper dll I get the C1190 error.

    I have tried to isolate all managed code from the dll's class, but I have not gotten rid of the error.

    Is there a way to identify where the suspect managed code is that the native code is attempting to access?  The error message only identifies the cpp file that is using the dll, but not where in the mixed dll code the error is.

    Thanks.


    Writing software since 1969.

All Replies

  • Friday, February 24, 2012 4:13 AM
     
     

    Are you putting the #using into the legacy native application? If so then that is what is causing it.

    Any attempt at accessing a managed DLL in this way requires the entire application to be compiled as /clr.

    If you want to be able to do this then you will need to export C functions or C++ classes from the mixed mode DLL itself so that it generates an import library and then use that. IE, to get unmanaged code to access this DLL, it has to be in the unmanaged way, using unmanaged classes.


    This is a signature

    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.


    • Edited by Crescens2k Friday, February 24, 2012 4:18 AM
    •  
  • Friday, February 24, 2012 1:49 PM
     
     

    Thanks, but I beleive that is what I am doing.  I have the class declared as  __declspec

    (dllexport), and it is in #prama unmanaged, and in a separate area I have managed functions that do the calls to the managed classes in the COTS dll.  I have repeatedly gone through the code to see if any managed data types are being used, but I beleive that I have eliminated all.

    How do I get the DLL to generate an import library?


    Writing software since 1969.

  • Friday, February 24, 2012 1:54 PM
     
     

    My project is creating a .lib file.  But switching my native code to #using the .lib still causes the same error.


    Writing software since 1969.

  • Friday, February 24, 2012 5:44 PM
     
     

    Of course it would, that is because you don't want to use #using at all. #using is used exclusively with managed code, and just by using #using you are saying "this code is now managed".

    So you take the import library, go to Project Properties->Configuration Properties->Linker->Input and add this library to the Additional Dependencies. As I said, even if the DLL is mixed mode, as long as you do things the native way then it will work.


    This is a signature

    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

  • Friday, February 24, 2012 7:56 PM
     
     

    Ok, I already had the dll in the list of dll files, so I added the .lib to list of Additional Dependencies, and I removed the #using statement in the .cpp.

    This got rid of the C1190 error, but is now returning a

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(1039,59): error MSB4115: The "exists" function only accepts a scalar value, but its argument "%(Link.ImportLibrary)" evaluates to "DgxPOWrapper.lib; DgxPOWrapper.dll" which is not a scalar value.

    Not sure what this means, but investigating further. 


    Writing software since 1969.


    • Edited by Zeft Friday, February 24, 2012 8:33 PM
    •  
  • Friday, February 24, 2012 8:32 PM
     
     Answered

    Wow, I modified the Additional Dependencies to include whole pathname to the .lib file, and the Build now succeeds. 

    Thanks for the clues.

    Now, on to the debugging.

    So Long, and Thanks for All the Fish (HHGTOG)


    Writing software since 1969.

    • Marked As Answer by Zeft Friday, February 24, 2012 8:32 PM
    •  
  • Monday, November 12, 2012 2:15 AM
     
     

    I think you should configure you project properties with the following steps to support the \clr option in your complier:

    Project -->Properties-->Configuration Properties-->General-->Common Language Runtime Support.

    I hope it's useful for you.