The syntax and keywords for the C ++ / CX extension are very similar to the C ++ / CLI. But what, when the similarities end, they have nothing in common. C ++ / CX compiles directly to native code, as does native C ++. But C ++ / CLI is compiled for MSIL, the .NET intermediate language. Their syntax looks so similar because they both solve the same problem by linking C ++ to a foreign type system..NET in the case of C ++ / CLI, WinRT in the case of C ++ / CX.
What is the main reason you cannot use the System namespace, it is the .NET namespace. Instead, you use the std namespace with the Platform and Windows namespaces for specific WinRT types. The compiler cannot import .NET prefabricated assemblies with the / ZW compilation option, but only WinRT metadata files, those with the extension .winmd. Which is an extension of the file format of a library of type .tlb type, which you should have previously imported using the #import directive.
Which in itself is another major source of confusion, the .winmd internal file format was based on the .NET metadata format. Because of this, most .NET decompilers can show you the contents of a .winmd file. But again, just a superficial resemblance, it is completely unrelated to the .NET assembly. It can only contain ads, not a code. It is best to compare it with the .h file that you use in your own C ++ project. Or a .tlb file if you previously had contact with COM.
Knowing how COM works can be very helpful in understanding what it is. This is actually COM that underlies WinRT, the main reason why your C ++ / CX project can be easily used by a program written in a completely different language such as Javascript or VB.NET. The WinRT application is actually an out-of-process COM server. The WinRT class library or component is actually a COM server in the process. COM object objects work differently, the scope is limited to the files specified in the package manifest. C ++ / CX is part of the language projection that hides COM, as well as the C ++ libraries you link that implement Platform namespaces. WinRT would still be born if programmers had to write traditional client COM code. You can still use your own C ++, the WRL library hides little from plumbing.
WinRT easily supports code written in a managed language such as C # or VB.NET, language projection is built into the structure and is very invisible. But not C ++ / CLI, structural constraint. The Store / Phone / Universal application is for a subset of the .NET Framework named .NETCore. CoreCLR, the parts that were open, are better known these days. Which does not support module initializers critical for C ++ / CLI.
It is enough to enter and get the answer: no, you do not need to use C ++ / CLI code, and you have to rewrite it. You will have a decent snapshot when porting your own C ++ code, with which your C ++ / CLI fairing is associated, if it complies with api restrictions. You should always get started first, given that this is easy to do, and immediately tells you if your own C ++ code uses verboten api functions that drain the battery too quickly or violate sandbox restrictions.
However, ref class wrappers should be significantly modified. There is little reason to suppose that this will be a serious obstacle; it may be structurally similar. The biggest limitations are the lack of support for implementation inheritance, the restriction on COM, and the need to replace code using .NET Framework types with equivalent C ++ code. A typical hang is that there is usually a lot of it, the original author usually prefers very convenient .NET types over the standard C ++ library types. YMMV.