Problems with calling unmanaged components in. net2.0 and their solutions.

There are still many bugs in vs2005... I found another one today.
Another article written todayArticle.. NET component... NET component. This component communicates with a DLL written in vc6 to facilitate. netProgramTo provide services, I actually wrote a console project for testing. The results were very good and there was no problem. So I released this component to the company for internal use, and the results were troublesome...

A colleague came to me and told me that the component could not be used, saying that the specified module could not be found. My first response was: the VC Runtime Library must have been copied.
The result shows an error message as follows:

The prompt says that the missing DLL is a DLL compiled under vc6, that is, it is not hosted. this is very strange, because I clearly put all the DLL files under the bin directory, how can I prompt that the DLL cannot be found? References between them are referenced by relative paths. I was wondering whether the vc6 Runtime library was a problem until I went back to my machine for debugging. I created a web project (my colleague is a web project with an error) and ran it. Hey, A real error occurred. It seems that it is not a problem with the running database. What is the problem? Question of reference? But the unmanaged DLL cannot be referenced. Intuition tells me that the problem may be here.
Start Google, oh, it seems that there are still a lot of this problem, but they are all foreign. Click a post of forums.asp.net (http://forums.asp.net/thread/1121085.aspx) to view. After reading it, mouseton opened.

PS: this problem may only occur in web projects. The reason is explained below.
This problem occurs most often when the thirdparty component is used. I also encountered this problem. The official solution of ASP. NET team is as follows:

First, you need to confirm which components you reference, which are hosted and which are not managed. it is easy to host and directly referenced by the user. for indirect use, you need to copy it to the bin directory. non-hosted processing will be troublesome. in fact, copying to the bin does not help, because the CLR will copy the file to a temporary directory and then run the Web, while the CLR will only copy the hosted file, this is why we obviously put the unmanaged DLL under the bin but still prompt that the module cannot be loaded.
The procedure is as follows:
First, create a directory somewhere on the server, for example, C: \ DLL.

Then, add the directory to the PATH variable in the environment variable.

Finally, copy all the unmanaged files to c: \ DLL.
OK. Run it. OK? (Note: restart vs before running. If IIS is used, restart IIS)

Well, in fact, this is not an official practice. In this case, we can only handle this problem. It is said that the bug has been submitted to the CLR team, we hope Microsoft can launch patches to address this issue as soon as possible.