Discussion:
[cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)
Robert Dailey
2018-06-26 14:12:46 UTC
Permalink
Using 3.12.0-rc1, if I create a C# project, but use
`target_link_libraries` on it to pull in a dependency to a managed C++
target, the C# project turns into a "vcxproj" after generation,
whereas if I remove the "target_link_libraries()" call, it outputs as
a "csproj" as I expect.

Is this a known issue? Am I doing something wrong or is this a bug? I
plan to spend some time debugging this in CMake if I get a chance.
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Robert Dailey
2018-06-26 14:25:45 UTC
Permalink
To fix this issue for now I had to do this:

set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp )

I don't remember having to explicitly tell CMake that the project is
CSharp in the past; it was always able to deduce it before. Is this
considered a symptom of a bug? Or is this required behavior? To be
honest, I'm not sure what criteria is used by CMake to deduce the
linker language of targets, especially in the C# case. It appears that
introducing a link-level dependency from a C# project to a Managed C++
project, forces the parent project to be C++ as well.
Post by Robert Dailey
Using 3.12.0-rc1, if I create a C# project, but use
`target_link_libraries` on it to pull in a dependency to a managed C++
target, the C# project turns into a "vcxproj" after generation,
whereas if I remove the "target_link_libraries()" call, it outputs as
a "csproj" as I expect.
Is this a known issue? Am I doing something wrong or is this a bug? I
plan to spend some time debugging this in CMake if I get a chance.
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Brad King
2018-06-26 15:06:15 UTC
Permalink
Post by Robert Dailey
set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp )
I don't remember having to explicitly tell CMake that the project is
CSharp in the past; it was always able to deduce it before. Is this
considered a symptom of a bug? Or is this required behavior? To be
honest, I'm not sure what criteria is used by CMake to deduce the
linker language of targets, especially in the C# case. It appears that
introducing a link-level dependency from a C# project to a Managed C++
project, forces the parent project to be C++ as well.
Please open an issue for that.

Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Robert Dailey
2018-06-26 15:34:18 UTC
Permalink
I'm happy to do that. I assume you would require an MCVE for that bug?
If so it will take me considerably longer, as I don't have a lot of
time to build a reproducible example from scratch. I'll do my best,
though.
Post by Brad King
Post by Robert Dailey
set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp )
I don't remember having to explicitly tell CMake that the project is
CSharp in the past; it was always able to deduce it before. Is this
considered a symptom of a bug? Or is this required behavior? To be
honest, I'm not sure what criteria is used by CMake to deduce the
linker language of targets, especially in the C# case. It appears that
introducing a link-level dependency from a C# project to a Managed C++
project, forces the parent project to be C++ as well.
Please open an issue for that.
Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Brad King
2018-06-26 15:59:55 UTC
Permalink
Post by Robert Dailey
I'm happy to do that. I assume you would require an MCVE for that bug?
If so it will take me considerably longer, as I don't have a lot of
time to build a reproducible example from scratch. I'll do my best,
though.
Even without a MCVE it's worth filing. If you produce one later
and the issue hasn't been resolved then you can add it.

Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers
Stuermer, Michael SP/HZA-ZSEP
2018-06-27 05:30:09 UTC
Permalink
This is weird: there is a test case called CSharpLinkToCxx which should cover the
mentioned error.

@rcdailey: could you check if this example works for you?

best regards,
Michael
-----Ursprüngliche Nachricht-----
Dailey
Gesendet: Dienstag, 26. Juni 2018 17:34
An: Brad King
Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
Betreff: Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a
"vcxproj" (C++ project)
I'm happy to do that. I assume you would require an MCVE for that bug?
If so it will take me considerably longer, as I don't have a lot of time to build a
reproducible example from scratch. I'll do my best, though.
Post by Brad King
Post by Robert Dailey
set_property( TARGET ${project_name} PROPERTY
LINKER_LANGUAGE
Post by Brad King
Post by Robert Dailey
CSharp )
I don't remember having to explicitly tell CMake that the project is
CSharp in the past; it was always able to deduce it before. Is this
considered a symptom of a bug? Or is this required behavior? To be
honest, I'm not sure what criteria is used by CMake to deduce the
linker language of targets, especially in the C# case. It appears
that introducing a link-level dependency from a C# project to a
Managed C++ project, forces the parent project to be C++ as well.
Please open an issue for that.
Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/
Loading...