Using CLR managed classes in unmanaged web applications

This is from MSDN.

Using CLR managed classes in unmanaged web applications
Like other win32 programs, IIS-based unmanaged (ASP or ISAPI) application can use classes from CLR (.Net) assemblies by referencing them through manifest element. You may wish to read the introduction to using CLR classes in win32 manifests before proceeding further.

While searching for win32 manifests in IIS-based applications is quite well thought out, as of Windows Server 2003 searching for CLR assemblies is deficient. The problem is that, unlike win32 manifest search, CLR class search uses the executable program's directory as the base of the search. Generally all web applications run in the context of the same executable - w3wp.exe - so all CLR assembly searching starts in C:\Windows\System32\inetsrv. This precludes isolating CLR assemblies by putting them in the web application folder. Microsoft is aware of this and we may see a change in the future.

Until then there are some workarounds that can be used:

Place your .Net DLLs in one of the default CLR folders (see table below).
This is the simplest solution, but does not allow side-by-side execution of the .Net code.
Create or change w3wp.exe.config file to configure CLR search.
To do this you need to strongly name the the .NET Assembly, give it a unique version number then use the element in w3wp.exe.config (read more...) . This solution is less manageable then the above (requires config changes as new versions are released) but allows using of multiple versions of CLR (.Net) assemblies. We recommend this approach until the general problem is solved by Microsoft.
Write your own front-end that will intercept the COM requests and instantiate CLR class as necessary.
This is the most flexible but also the most difficult solution. The proxy code would need to explicitly create an AppDomain, load the CLR DLL and pass the reference back to the caller. One can imagine other variations on this theme but they generally require some advanced code, most likely in mixed managed/unmanaged C++, to get the job done.
Win32 Manifest Search Order in IIS6
Directory Extension
C:\Windows\WinSxS\manifests\ .manifest
C:\Windows\assembly\GAC\ .DLL
(web application directory) .DLL
(web application directory) .MANIFEST
(web application directory)\(assembly directory) .DLL
(web application directory)\(assembly directory) .MANIFEST

The web application directory is the location of your web manifest (something like C:\inetpub\wwwroot\application.)

For more details on assembly search sequence read Assembly Searching Sequence on MSDN...

Default CLR Assembly Search Order in IIS6/IIS7
Directory Extension
C:\Windows\assembly\GAC\ .DLL
C:\Windows\System32\inetsrv .DLL
C:\Windows\System32\inetsrv\(assembly directory) .DLL
C:\Windows\System32\inetsrv .EXE
C:\Windows\System32\inetsrv\(assembly directory) .EXE

Note that there is no attempt to access the web application's directory while searching (probing) for the CLR assembly.