Projectreunion: Improve C++ tooling

[pjmlp]

As .NET developer that occasionally has to deal with C++ due to C++ only APIs not exposed to WinRT, like DirectX, the C++/CX tooling was kind of alright.

While not at same level as .NET Native, C++/CX was quite close.

With the replacement via C++/WinRT, I felt that we have moved backwards to the ATL days, old style COM with lots of manual boilerplate.

UWP with C++/CX was the proof that if Microsoft is willing to put the effort, having C++ Frameworks at the same developer friendliness like Qt/QtCreator and VCL/C++ Builder was possible within Microsoft own SDKs.

C++/WinRT feels backwards to this goal, and the multiple times I have referred this productivity lost, due to manually editing IDL files without tooling support, hunting for header files, outdate samples only with the C++/CX way, being forced to do Visual Studio work by copying generated files around just feels the C++/WinRT has definitly moved into the wrong direction.

Usually the answer to these remarks tends to be that those of us not happy with this situation should just put up with the situation, hope that ISO C++23 or ISO C++26 eventually adopt the language features for static reflection and metaclasses, so that a couple of years later Visual Studio can add back to C++/WinRT the tooling support that C++/CX enjoys today.

From my point of view if you really want to cater to C++ developers to WinUI instead of having them choose cross platform toolkits like Qt and FireMonkey, modern C++ tooling is a must have.

It shouldn't have to be harde than .NET, with lots of manual steps, just because it is C++.

Although this issue is for C++, the same reasoning applies to the upcoming Rust/WinRT.

[kennykerr]

As the creator of C++/WinRT, I agree that it is a step back having to use IDL, however the goal of C++/WinRT was and is to embrace modern and _standard_ C++ for better, and sometimes, for worse. Overwhelmingly I believe it has been for better, but I'm biased. 😉

I am optimistic that standard C++ will catch up and provide the necessary compile-time type information needed to make IDL a thing of the past before too long.

As for Rust/WinRT, the good news is that Rust already includes the necessary language support such that it will not require IDL at all.

[pjmlp]

Again the same answer as always, why do you guys ask for feedback?

So given that you are the creator of C++/WinRT, thank you very much for killing our productivity in name of some greater good, do you think that we are willing to deal with ATL like experience for the next 6 years assuming that ISO C++ actually adopts whatever you feel like pushing?

Or that we are willing to wait the same amount of time as concepts, modules have taken to come up?

This assuming that static reflection or metaclasses won't be removed at the 11th hour like it happened to contracts.

Then you act surprised that we (.NET devs) complain when being forced to use C++ APIs like we were back in the old VB 6 / C++ ATL days, or just adopt competing UI frameworks like Qt and Firemonkey when C++ use is unavoidable.

Your reply just made me realize it is a lost cause to expect that Visual C++ will ever live up to the _Visual_ part like other C++ developer environments or the comfort of .NET tooling.

C++/CX was a nice experience and you took it away from us.

[wjk]

While C++/WinRT is quite useful (and well-designed!) as-is, I agree that with @pjmlp that its VS support is horrible. The IDL editor is extremely primitive, featuring bad syntax coloring and no IntelliSense whatsoever. However, this can be solved if someone (inside or outside of MS) puts in the effort to create first-class editor bindings for this language. The thing about having to manually copy generated files around is also a problem, but this is more due to the fact that C++/WinRT has poor support in MSBuild, which can very much make this a more automated process, if enough work is done.

Since the C++/WinRT MSBuild code is open-source, if anyone has any _specific_ complaints about the MSBuild support, I would recommend submitting them as issues there; I or others may pick them up. @kennykerr has said in https://github.com/microsoft/cppwinrt/issues/452#issuecomment-567149744 that this code is maintained as a volunteer effort.

I would also like to point out — once again — that to take best advantage of C++/WinRT and WinUI 3 we badly need PackageReference support in vcxproj. Since so many C++ components are now being distributed as NuGet packages, having to continue to use packages.config really, really stinks. (This means that you still need to manually edit project files to fix errors if the project is moved around on disk; also, packages.config package references cannot restored from the command line by any means that I know of.) Unfortunately, this feature must be implemented by MS, as it needs support in the project system itself, which is closed-source and nonextensible. I and others have been requesting this feature for a long time, and have received no response. I am honestly quite disappointed that there was no news at Build about improvements to vcxproj.

[pjmlp]

@wjk Thanks for the remark.

Somehow, given the answers from @kennykerr and others at Build I have lost all hope with improved tooling.

Apparently C++/WinRT is considered being good enough for ATL/WTL developers and any kind of feedback is not welcomed, regardless what they state.

C++/WinRT will never be back at the same tooling as C++/CX, let alone what we can enjoy on Qt/QtCreator and C++ Builder.

We are supposed to wait several years with the hope that ISO C++ actually adopts whatever C++/WinRT team deems necessary, because using compiler attributes or extensions is no longer considered good enough.

I have been a long time advocate for WinRT since its introduction with Windows 8, my only pain point being lack of support for DirectX as Windows Runtime Component.

I was quite happy with C++/CX, but apparently that is not the kind of comfort that is desirable for any developer faced with the challenge to integrate C++ into their .NET applications.

[kennykerr]

Your feedback is always welcome and very much appreciated. That does not mean we can always respond or give the answers that you would like to hear or even the answers we wish we could offer.

Keep in mind that C++/CX is a technology owned and maintained by the Visual Studio team. Visual Studio does not directly support C++/WinRT at all, which is mostly why C++/CX continues to offer a superior experience in the Visual Studio IDE. This is the point @wjk was making. We are the Windows team and do not have any control over the compiler toolchain or IDE. You are however free to continue to use C++/CX. We do not use C++/CX in Windows much anymore as it has a number of undesirable properties, but the WinRT ABI is the same and continues to support both language projections as long as the Visual Studio compiler continues to support C++/CX.

And as @wjk mentioned, C++/WinRT is all open source. You are welcome to contribute improvements, as many have already done. This is not the case for C++/CX.

[wjk]

@kennykerr That's all well and good, but the WinUI 3 docs state that only C++/WinRT will be supported for use with the new framework, and that C++/CX support will be deprecated/removed soon. Is this accurate?

[kennykerr]

@MikeHillberg should be able to comment on WinUI plans. Also @Scottj1s who worked on the C++/WinRT tooling and has a particular interest in Xaml.

[pjmlp]

@kennykerr Well the public message from various Microsoft teams so far looks quite the opposite regarding C++/CX and C++/WinRT relation to each other, so naturally, those of us that are forced to only use C++ because Microsoft is unwilling to provide WinRT bindings to several COM APIs, or nano-COM as they now get called, aren't that happy with productivity loss in name of pure ISO C++.

C++/CLI and now C++/CX never bothered us, otherwise we would be in other platforms to start with.

Now if all of this is being pushed by several teams with different kinds of agendas, I have little hope for Project Reunion or WinUI to fare better than what UWP applications have done since Windows 8.

Then again maybe it is just me, and there is some survey at Microsoft telling management how they love C++/WinRT, and the ATL/WTL experience that it offers.

In any case, since my focus is .NET, there seems to be a wasted effort to keep asking for proper C++ tooling and always being told just to knock on other doors or wait and it will come, some day.