MIDL 3.0 (for WinRT/WinUI/XamlIslands) and MIDL 1 (classic COM) in a single project #8107
-
I am currently experimenting with XAML islands to update an existing MFC/C++ application. First tests with a simple experimental application looked quite promising. However, my real application also acts as a classic COM server. The COM interfaces and classes are defined in a MIDL (1.0) file. Unfortunately, after adding the Microsoft.Windows.Cpp.WinRT NuGet package to the project, it does not compile any more. MSBuild seems to treat the existing MIDL file as a MIDL 3.0 file, which of course ends up right against the wall. I have tried to reset all options in the MIDL property page to the original ones, but it still does not work. There are many warnings and finally a fatal error while processing a range of winmd files, which I assume should not be processed at all. What I think is required is to process the existing midl file as before adding WinRT. Any WinRT/WinUI related stuff would go to a new additional midl file to be processed like in a standard WinUI application. Am I on the right path and can someone help with details on how to make this happen? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
It actually gets worse. Due to the macros defined in them, the MFC headers actually cause compiler errors in the Windows Runtime headers. I guess you could try to avoid this somewhat if you disable precompiled headers for certain source files, but honestly, it is easier to just put all of the Xaml Island functionality into a separate DLL. This deals with all of the issues at once without requiring you to do anything weird. The C++/WinRT project modifications are only for a project, not all projects in a solution after all. |
Beta Was this translation helpful? Give feedback.
It actually gets worse. Due to the macros defined in them, the MFC headers actually cause compiler errors in the Windows Runtime headers.
The one that I can recall off of the top of my head is the exception handling stuff in MFC uses a TRY macro. Windows.Globalization.CurrencyIdentifiers has TRY for the Turkish Lira. Including Windows.UI.Xaml.Controls.h forces Windows.Globalization.h to be included too, this means that using Xaml Islands just naturally gets you into this situation. You also can't include Windows.UI.Xaml.Controls.h before the MFC headers because these headers eventually include Windows.h.
I guess you could try to avoid this somewhat if you disable precompiled headers for c…