You are probably misunderstanding the situation. The OP is using C++/CLI, the Microsoft C++ dialect used for gluing C and C++ code to the managed world. He is not using the usual native C++ projects, which are _very_ well supported by Boost.
Most of Boost (thread, asio, shared_ptr, heck - most of it) does not build or work cleanly under C++/CLI. I guess that it's implicitly assumed to be known that C++/CLI isn't C++, and shouldn't be expected to compile most of modern C++ code, particularly not something as workaround-happy as Boost. FWIW It's not quite as bad as you are painting.
The large Boost.Math library *does* compile, and compiles under managed C++/CLI to build a Boost.Math dll.
A .Net project in C# and using VS net framework links with the Boost.Math dll to provide the windows display feature for a Statistical Distribution Explorer Windows utility (so you can look up students_ts etc to your heart's content).
To my surprise, /CLI worked without any trouble at all did what it said on the tin.
But other Boost libraries may well not work at all with /CLI.
I would expect that most if not all Boost libraries should work just fine in a mixed-mode (a.k.a managed + native) C++/CLI application. The key thing is to have a clear separation between the managed functions and the native functions. If all of the Boost uses are within the native sections and only work with native types, there should be no issue whatsoever. You just have to be careful of not calling boost functions with manage types. That probably won't work. That being said, however, there is some STL support for managed types/code. It's quite possible that anything that is compatible with managed STL may be compatible with similar boost functions. The key word here is "maybe". But, like I said - Boost within native functions should be just fine regardless if the app is managed. -- Bill --