They decided to use that style for Managed C++ and C++/CLI (only the automatic designer does that though). I reckon they wanted to be similar to C# (where there is just one file, no separate declaration and definition files).
That said you can choose to keep them in separate files if that suites your needs better.
[Edit]
~~~~~~~~
In response to your comment about inlining, I will add this here in case anyone else has the same question:
In managed code it does not matter (unlike in native code). All methods are generated as MSIL (there is no inlining during compilation). Any inlining is done at runtime by the JIT compiler.
[Edit]
~~~~~~~~~
SA commented that it's a bad idea to keep declaration/implementation in separate h/cpp files in C++/CLI (managed code). But this is not true for C++/CLI, and I will give reasons for that below.
In summary, when you are doing C++/CLI it is still a good practice to keep your declarations and implementations in separate header and cpp files.
- The C++ compiler will not directly compile header files, so even if you put your entire class in a header file, you still need to include it in a cpp file for it to compile.
- Every time you change code in any method or property, if you have it all in a header file, then every cpp file that #include-s this header file will need to be re-compiled. For large projects this can be a nightmare.
- The core C++ idea of keeping declaration and definition separate has been ingrained into the C++ coding culture for decades. It's a good idea to continue that practice, specially since the vast majority of C++/CLI projects will be mixed mode and thus you don't want to have two different styles in the same project.
- Every time you #include a file, the compiler has to unnecessarily recompile the entire code if they are inline. If you keep them separate the actual compilation only happens once.
- C++ compiler front-ends are optimized to handle separate cpp/h files, so that's yet another reason to use them.