MSBuild SDK support for C++/CLI

[mattaquinn]

My team has a large code base that has a mixture of C# and C++/CLI projects across multiple solutions. We are a windows only shop so the performance gains and unmanaged interoperability of C++/CLI are essential to us, while cross-platform operability is not.

Upon migrating our codebase from framework to core we are experiencing multiple pain points:

1. Multi-targeting builds requires copy/paste/modify of vcxproj files for each target framework. Then conditional references from referencing projects.
2. Central package management does not work for CLI
3. dotnet cli is not usable - which means the self-contained option is not available. If it were our deployment story could be greatly simplified.
4. Microsoft.Build requires any application using it to target framework for framework built project types (such as vcxproj). We use these libraries to analyze our code. This limitation is blocking us from targeting core exclusively in our codebase, which is our goal.

Thus we request that SDK support be added for vcxproj files.

Thanks!

[baronfel]

cc @olgaark for vcxproj related requests

[olgaark]

Hi, it is not clear to me what you mean by "SDK support in vcxproj" - can you elaborate?
C++/CLI projects targetting .NET (not Framework) already using .NET SDK props/targets.
#1 - Indeed, VC projects don't support managed multitargeting and currently there are no plans to support it. You should be able to use .vcxitems projects and reference them in the vcxprojs targeting .NET and .NET Framework to avoid duplication.
#2 - Nuget PackageReferenes are supported for C++/CLI .NET projects.
#3 - C++ builds require VS installed C++ tools, which are not part or dotnet (they are native platform specific tools and libs), so no, you cannot use dotnet CLI to build C++.
You should be able to use VS's msbuild to build any projects.
#4 - I am not sure I understand - vcxproj/props/targets are just xml files and you should be able to load them in any kind of exe. Or are you trying to build vcxproj inside a .NET core process and having an issue there loading cpp tasks dll which targets Framework? Can you use an external build for this?

[mattaquinn]

#1 - What I mean by SDK support is a project that use a Sdk attribute, like so:
<Project Sdk="Microsoft.NET.Sdk"> ... </Project>
It would support default includes and excludes (so we don't need to manually specify every .h, .cpp, etc. file).

We could multi target the build like so:
<PropertyGroup> <TargetFrameworks>netstandard2.0;net462</TargetFrameworks> </PropertyGroup>

We could customize the build for a range of projects using Directory.Build.props and Directory.Build.targets

Yes we could avoid duplication as you suggest, thank you, that helps for the vcxproj files, but for the other projects that reference the vcxproj and do support multi-target we need to have conditional references. As a user of this system, respectfully, its unwieldy. The SDK system is order of magnitudes better.

#2 PackageReferences may be supported but Central Package Management is not.

#3 Isn't this same windows platform only argument true for WinForms and WPF? I can build and run those just fine. The fact that C++ will not work with core based build tools is severely limiting. What is driving this decision? Sure I can build the project but I cant package it or publish it or run tests over my solution in the same manner if it was supported.

#4 Yes msbuild project files are XML but no they are not just xml. There is a system for defining variables, importing other files, etc. etc. etc. The topic is quite deep and there are host of libraries available to tap into the MSBuild API for examining projects and how are they are fully evaluated. I cannot from within a core based application use the MSBuild interface to evaluate a vcxproj see: here.

[marcpopMSFT]

For item 2, adding @jeffkl to comment on CPM support for c++/CLI and any potential plans there.
For item 3, we do not currently have plans to add c++ support to the .NET CLI. We have considered it but the feedback hasn't been strong enough yet to prioritize it as it would require significant changes (c++ build tools would have to be findable by dotnet and runnable in a .net core process which is harder than it sounds). We'll add your feedback to the existing feedback on this.

[EricScottSalem]

feedback hasn't been strong enough

Stronger feedback:
The argument that .NET CLI does not support C++ because C++ is not .NET is specious and besides the point. In the same manner that it does not support C++, .NET CLI does not support C++/CLI, which is .NET.
C++/CLI (nee Managed C++) has been (a powerful and necessary) part of the .NET ecosystem since day 1. The lack of firm support for C++/CLI in modern build tools is a painful drag on organizations who have built an enterprise based on Microsoft prescribed solutions for the past 22 years.

Please realize that as Microsoft announced end of life for .NET Framework, this lack of C++/CLI build support is a major catch-22 for long standing enterprise solutions.

Thank you.

[mattaquinn]

Thank you for considering this request @marcpopMSFT I truly appreciate it.

which is harder than it sounds

What is also harder than it sounds is migrating thousands of projects from framework to core. And then even harder the pill to swallow when sqlproj and vcxproj have really painful integrations. I appreciate the effort that must be involved to be multi-platform, but we have been a windows shop since .NET 1. It really feels like we are being left behind despite our efforts to stay current.

[marcpopMSFT]

I appreciate the feedback that two of you have provided and we'll include it in our discussions with the various teams involved in the future.

I believe most of our proposed ideas around getting dotnet build to support other targets still require installing VS (at least a build tools skus) as we don't have a good solution for acquiring the various props/targets/tasks that install with VS for supporting other project types. Would installing build tools be a problem (ie do we need to think through the props/targets acquisition problem as well)?

Unfortunately, c++/CLI while part of .NET relies on components from C++ that come from VS which is why it's in that similar bucket.

[mattaquinn]

Would installing build tools be a problem (ie do we need to think through the props/targets acquisition problem as well)?

Hi, thanks for the added color. We currently install "Build Tools for Visual Studio 2022" on our build servers and all of our developers have a Visual Studio Enterprise installation. So in my opinion that requirement is acceptable.