MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009742CMakeCMakepublic2009-10-20 11:502016-06-10 14:31
ReporterJuan Jesus Garcia de Soria 
Assigned ToBill Hoffman 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0009742: [w/PATCH] Enhance include_external_msproject so that it can use C# and VB.NET projects.
DescriptionCurrently it seems that CMake can include external pre-existing projects by using the command include_external_msproject().

It seems, however, restricted to .vcproj (C/C++ projects).

In my organization we are looking into using CMake for our building needs, but in Windows we tend to mix C++ with .NET via C++/CLI. This forces us to include .NET projects in our building scripts.

Currently the code has the following shortcomings:
 * Uses the same project type GUID (the one for .vcproj files) for all referenced external projects.
 * Fails to find the project instance GUID in .csproj and .vbproj files (the XML is substantially different from .vcproj files).
 * Fails to map solution configurations. These projects typically have only Debug/Release configurations, and usually use "Any CPU" as the platform, and not Win32/x64.

I've attached two patches (one for 2.6.4, another one for 2.8.0-rc3) that somehow fix the above shorcomings.

Configuration matching is pretty hardcoded:

 * Debug -> Debug.
 * Evertything Else -> Release.
 * Platform will be "Any CPU" always.

But it seems to work up to the point that our developers can edit and build solutions including the three kinds of projects (C/C++, C# and VB.NET).

It would be nice if these patches get applied :-)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filesdiff cmake_2.8.0-rc3_patch_for_dotnet.diff (12,932) 2009-10-20 11:50
https://public.kitware.com/Bug/file/2572/cmake_2.8.0-rc3_patch_for_dotnet.diff
diff cmake_2.6.4_patch_for_dotnet.diff (12,582) 2009-10-20 11:50
https://public.kitware.com/Bug/file/2573/cmake_2.6.4_patch_for_dotnet.diff
diff cmake_2.8.0_patch_for_dotnet_v2.diff (13,114) 2009-11-19 05:37
https://public.kitware.com/Bug/file/2664/cmake_2.8.0_patch_for_dotnet_v2.diff
diff cmake_2.8.0_patch_for_dotnet_v3.diff (13,204) 2009-11-20 10:10
https://public.kitware.com/Bug/file/2667/cmake_2.8.0_patch_for_dotnet_v3.diff
diff cmake_2.8.0_patch_for_dotnet_v4.diff (14,506) 2010-02-11 04:15
https://public.kitware.com/Bug/file/2855/cmake_2.8.0_patch_for_dotnet_v4.diff
diff managed_include_external_msproject.diff (3,107) 2011-03-02 02:58
https://public.kitware.com/Bug/file/3734/managed_include_external_msproject.diff
patch 0001-ms-external-project-.NET-project-support.patch (16,108) 2011-05-09 09:10
https://public.kitware.com/Bug/file/3858/0001-ms-external-project-.NET-project-support.patch
patch 0001-ms-external-project-.NET-project-support-GUID-fixed.patch (16,108) 2011-05-16 02:18
https://public.kitware.com/Bug/file/3874/0001-ms-external-project-.NET-project-support-GUID-fixed.patch
Issue History
Date ModifiedUsernameFieldChange
2009-10-20 11:50Juan Jesus Garcia de SoriaNew Issue
2009-10-20 11:50Juan Jesus Garcia de SoriaFile Added: cmake_2.8.0-rc3_patch_for_dotnet.diff
2009-10-20 11:50Juan Jesus Garcia de SoriaFile Added: cmake_2.6.4_patch_for_dotnet.diff
2009-11-19 05:37Juan Jesus Garcia de SoriaFile Added: cmake_2.8.0_patch_for_dotnet_v2.diff
2009-11-19 05:40Juan Jesus Garcia de SoriaNote Added: 0018486
2009-11-20 10:11Juan Jesus Garcia de SoriaFile Added: cmake_2.8.0_patch_for_dotnet_v3.diff
2009-11-20 10:11Juan Jesus Garcia de SoriaNote Added: 0018494
2010-02-11 04:15Juan Jesus Garcia de SoriaFile Added: cmake_2.8.0_patch_for_dotnet_v4.diff
2010-02-11 04:16Juan Jesus Garcia de SoriaNote Added: 0019508
2010-12-15 09:02David ColeStatusnew => assigned
2010-12-15 09:02David ColeAssigned To => Bill Hoffman
2011-03-02 02:58Jens FrederichFile Added: managed_include_external_msproject.diff
2011-03-02 03:00Jens FrederichNote Added: 0025618
2011-03-21 15:42Matt DeckardNote Added: 0025847
2011-03-22 04:42Jens FrederichNote Added: 0025860
2011-05-09 09:10Thomas BernardFile Added: 0001-ms-external-project-.NET-project-support.patch
2011-05-09 09:11Thomas BernardNote Added: 0026461
2011-05-09 09:12Thomas BernardNote Added: 0026462
2011-05-13 19:07Erik HasslmeyerNote Added: 0026502
2011-05-16 02:18Thomas BernardFile Added: 0001-ms-external-project-.NET-project-support-GUID-fixed.patch
2011-05-16 02:21Thomas BernardNote Added: 0026503
2011-05-16 03:18Jens FrederichNote Added: 0026504
2011-05-16 03:22Thomas BernardNote Added: 0026505
2011-05-16 03:50Jens FrederichNote Added: 0026506
2011-05-16 03:56Thomas BernardNote Added: 0026507
2011-05-16 04:00Jens FrederichNote Added: 0026508
2011-10-24 00:06YuriNote Added: 0027633
2011-10-24 09:38David ColeTarget Version => CMake 2.8.7
2011-12-13 19:27David ColeNote Added: 0027971
2011-12-13 19:27David ColeTarget VersionCMake 2.8.7 =>
2012-05-21 03:00YuriNote Added: 0029515
2012-05-21 10:30David ColeNote Edited: 0029515bug_revision_view_page.php?bugnote_id=29515#r656
2016-06-10 14:27Kitware RobotNote Added: 0041606
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0018486)
Juan Jesus Garcia de Soria   
2009-11-19 05:40   
I've just attached "cmake_2.8.0_patch_for_dotnet_v2.diff", rebased against the just released 2.8.0.

It also provides a new target property: "CLR_FLAG". This gets translated to a "ManagedExtensions" value in the outputted .vcproj file, so that you can enable CLR compatibility in a C++ project. For instance, setting CLR_FLAG=1 for a target is the same that compiling the target with the "/clr" flag.
(0018494)
Juan Jesus Garcia de Soria   
2009-11-20 10:11   
New version of the patch, that also sets ExceptionHandling=3 when CLR_FLAG is activated.
(0019508)
Juan Jesus Garcia de Soria   
2010-02-11 04:16   
New version (v4) of the patch. Now you have to set CLR_FLAG property (with a non-"0" value) for source files that you want to be compiled as /clr too. This means that you can control which files to compile as managed. It also means that by default all files will be compiled as native.
(0025618)
Jens Frederich   
2011-03-02 03:00   
Hello,

I've just attached "managed_include_external_msproject.diff", rebase against the just 2.8.4 release branch.

Please accept this patch, we needing the feature!
(0025847)
Matt Deckard   
2011-03-21 15:42   
Jens, your patch doesn't seem to include the changes to cmVS7XMLParser which I found were needed so that it would include the correct project instance GUIDs for .csproj files.
(0025860)
Jens Frederich   
2011-03-22 04:42   
Hello Matt. Mmmhhh, sorry I don't know what you mean with that. The correct GUID is set at cmGlobalVisualStudio7Generator::GetExternalProjectTypeGUID(...).

const char* cmGlobalVisualStudio7Generator::GetExternalProjectTypeGUID(const char* location) {
  const char* ext = this->GetExternalProjectExtension(location);

  if(strcmp(".vbproj", ext) == 0)
    {
    return "F184B08F-C81C-45F6-A57F-5ABD9991F28F";
    }
  else if(strcmp(".csproj", ext) == 0)
    {
    return "FAE04EC0-301F-11D3-BF4B-00C04F79EFBC";
    }
  else
    {
    return "8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942";
    }
}

That's the GUID's for VisualStudio 10 project files.
(0026461)
Thomas Bernard   
2011-05-09 09:11   
We would also really need this functionality !
I just added a patch which summurizes the previous patches posted previously. Should be a git compatible patch based on CMake 2.8.3
(0026462)
Thomas Bernard   
2011-05-09 09:12   
Sorry about that: the patch I posted is based on CMake 2.8.4 !
(0026502)
Erik Hasslmeyer   
2011-05-13 19:07   
Hello Thomas

I tested your patch "0001-ms-external-project-.NET-project-support.patch" and the .csproj and .vbproj GUIDs seem to be mixed up.

correct way (as posted by Jens Frederich):
vbproj -> F184B08F-C81C-45F6-A57F-5ABD9991F28F
csproj -> FAE04EC0-301F-11D3-BF4B-00C04F79EFBC

your way:
vbproj -> FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
csproj -> F184B08F-C81C-45F6-A57F-5ABD9991F28F

The rest of the patch seems to work for me. Would be nice if this feature is included in the next release.
(0026503)
Thomas Bernard   
2011-05-16 02:21   
Thanks Erik for the error report :)

I took what was contained in the other patches without checking the contents thouroughly enough.

I just uploaded an updated patch which should fix that issue.
(0026504)
Jens Frederich   
2011-05-16 03:18   
Hello Thomas,

a little hit. The project GUIDs:

vbproj -> F184B08F-C81C-45F6-A57F-5ABD9991F28F
csproj -> FAE04EC0-301F-11D3-BF4B-00C04F79EFBC

are MS Visual Studio 2010 Id's. I hope that is correct for you.
(0026505)
Thomas Bernard   
2011-05-16 03:22   
Didn't meen to hurt anybody.

Might have been my mistake in merging the patches...

The GUIDs you mention absolutly match the last patch update I send.
(0026506)
Jens Frederich   
2011-05-16 03:50   
No no, your patch is absolutely correct. I want point out it's only a MS VS 2010 patch. Visual Studio 2005/2008 vbproj/csproj projects have other GUIDs...
(0026507)
Thomas Bernard   
2011-05-16 03:56   
Just checked on my machine the GUIDs for VS2005 and VS2008. They are identical to the above mentioned GUIDs.

I tested the patch with VS2008 and it worked perfectly.
I expect it to work with VS2005, VS2008 and VS2010.
(0026508)
Jens Frederich   
2011-05-16 04:00   
Ah okay, I was mistaken. Sorry!
(0027633)
Yuri   
2011-10-24 00:06   
May be it's worh implementing GetExternalProjectTypeGUID via cmake scripts? In such a way it would be easier to add other types of projects, say vdproj or wixproj.
(0027971)
David Cole   
2011-12-13 19:27   
Unset target version field; too late for a fix to go into 2.8.7; deferred until a future version.
(0029515)
Yuri   
2012-05-21 03:00   
(edited on: 2012-05-21 10:30)
Fixed in terms of 0013120
(0041606)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.