Initialization of mixed code in Visual C + + 2005

Initializing mixed DLLs in Visual Studio. NET 2003 is cumbersome and requires manual intervention. In Visual Studio 2005, however, the Visual C + + and CLR teams designed a new initialization model that is simpler and more automated.

The fundamental problem with Visual Studio. NET 2003 is that local code and managed code are placed together in a single "pool." This pool is not safe to run during DllMain, and managed code cannot run here at all.

The new model collects static initialization into two separate pools. One pool is responsible for the static initialization of the local, and the other is responsible for the initialization of managed code.

The first pool is initialized during DllMainCRTStartup, as is the case with local code. The second pool was initialized, and we added a new managed code initialization phase. When a module containing managed code is loaded into the application domain (AppDomain), the CLR will run a special. cctor function (which we call the "module constructor") before any managed code runs.

The managed C Runtime (msvcmrt.lib) contains a module constructor that is responsible for initializing the second pool. It also installs the Unload event of an application domain to run managed static destructors and exit functions.

This new model means that it will be easier to migrate to managed code or to add managed code to an existing application because no additional custom initialization entry points are required. During the migration, you may also encounter situations where local code invokes managed code. You need to solve this problem before you can reliably start and close your code. Otherwise, a R6031 error occurs for the C Run-time Library, or a CLR warning occurs when running under the debugger.

To resolve this issue in Visual Studio's Beta 2 or later version, use the call stack of the debugger to find this annoying function and either move the function to a header file or local original file to compile the cost code. You may have noticed the suggestion to solve such problems through #pragma managed. Try to avoid this, and it is very difficult to solve the problem in this way. This is especially true when you have your own DllMain or rawdllmain, and you must be sure to place this function in the local code set.

If you take the solution that Paul describes, migrating from Visual C + + 7.1 to 8.0 won't be too much trouble. When you recompile, you will see a dissatisfaction warning about using functions in _vcclrit.h. The reference to the file is deleted and manually initialized. In order to fully restore the use of the CRT, you should also remove the/zl from the compiler switch and remove the/noentry from the link switch.

This is one of the many changes in Visual Studio 2005 to facilitate the migration of C + + applications to managed code usage environments. With the latest build products, we've seen a large number of applications moving into the managed environment in a relatively short period of time. Visual Studio 2 After the release of the released to see, and the use of feedback to us.