Open mattaquinn opened 2 months ago
cc @olgaark for vcxproj related requests
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.
You should be able to use VS's msbuild to build any projects.
``
`` 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: ``
``
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.
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.
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.
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.
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.
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.
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:
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!