You can only include references in one direction.
Usually, one would probably setup its dependencies like that :
Native C++
▲
C++/CLI wrapper
▲
C# assembly
It seems that you want to do it where the wrapper use both native C++ and managed C#. If so, then you need to use a callback mecanism. It might be an interface declared in native code but implemented by the wrapper (which can then call the C# code).
In any case, you cannot have circular references.
Depending on the complexity of the interactions, what technologies you master and your existing code, P/Invoke or COM might be possible alternatives. Each case is specific.
The only recommandation, I would have is to avoid multi-language application if it can be done in one language in a few extra days... as it make it harder to develop an application since debugging, refactoring and IntelliSense are not very smooth across language boundaries. If not possible, then at least try to minimize the number of dependencies with a language switch. In the past, I have done dependencies like C# ⬅ C++/CLI ⬅ C# ⬅ C++/CLI ⬅ C# but it has made the maintenance harder.
Thus, I would probably consider something like :
C# assembly ⬅ C# application
▲
C++/CLI ➡ C++ Native
where dependency injection would be used for C++/CLI code. That way, C++/CLI would implement some interface from C# code but the main application would not directly depends on it.
However, I never have refactor my application that way... but I have only converted part of the code from C++/CLI to C#. My problem was that at some point, some code need to be moved (as I was not using DI) and to avoid having even more transition between language, it was best to convert the code of a few files (usually, I have converted C++/CLI code to C# using mainly find and replace).