Efficient use of unmanaged parallel caching in C++/CLI

How can Visual Studio Setup put Visual Studio's shared library in a place called side-by-side cache, and how do you use it effectively?

At the beginning of the article, let's look at an example. On the command line, create a C + + source file and enter the code in Example 1. (Although the C++/CLI syntax is used here, it doesn't matter if you're using C++/CLI, managed C + +, or local C + +, and it doesn't affect the topic you want to explain.) ）

Case 1:lib.cpp

using namespace System;
public ref class Test
{
　 public:
　　 void CallMe()
　　 {　
　　　 Console::WriteLine("called me");
　　 }
};

Compile it into a managed library assembly:

cl /clr /LD lib.cpp

Notice here that we are using mixed mode (/clr) to compile this code, and of course, if properly modified, it can be compiled with legacy managed C + + syntax (/clr:oldsyntax).

Next, create a C # program that calls this library (example 2), and of course you can use Visual Basic.NET, but C # is a little better. And then compile with the library:

Example 2:

using System;
class App
{
　 static void Main()
　 {
　　 Test test = new Test();
　　 test.CallMe();
　 }
}
csc app.cs /r:lib.dll

When you run this program, an exception is thrown:

Unhandled Exception:
System.IO.FileNotFoundException:
The specified module could not be found.
(Exception from HRESULT: 0x8007007E)
at App.Main()

How could that be? Open the directory where the program resides, and the library is there. The high word for HRESULT is 0x8007, which represents Facility_win32, that is, this is a Win32 error; the low word is in decimal notation 126, and its representative Error_mod_not_found is listed in the Winerror.h. If LoadLibrary cannot find a module, it returns this error result, so it is now very clear that this error indicates that an unmanaged DLL could not be traced.