How to use multiple DLLs with the same name

Question

How to use multiple DLLs with the same name

Corey Fleig 185

Years ago I built web apps on my local box, and copied the ASP.NET files over to our web server. This included creating a bin directory, and placing the needed DLLs there. Everything runs great.

Now, years later, I'd like to add a new app, and use much newer 3rd party DLLs with the same name. However, these newer DLLs are not backwards-compatible. I can't overwrite the original DLLs in the bin directory, and I tried using <probing> but that didn't accomplish what I need.

Is there a way, for example, for app1 to use bin\some.DLL, and app2 to use some_other_dir\some.DLL, but not look to load from bin first?

Answer accepted by question author

2 additional answers

Your answer

Answer 1

Susmitha T (INFOSYS LIMITED) 1,640 Microsoft External Staff

Thank you for reaching out!

If you want two web apps to use two different DLLs with the same name, deploy them as two separates ASP.NET applications, each with its own /bin folder. ASP.NET loads DLLs per application: each app gets its own assembly cache and does not mix DLLs even if the names are identical.

In other words, Put some.dll (old version) in App1/bin, and some.dll (new version) in App2/bin. The apps will remain isolated and use their respective DLL versions.

Put Each App in its Own Application Directory:

If you have:

/App

/bin

some.dll (old version)

/App2

/bin

some.dll (new version)

ASP.NET will not mix these DLLs.

Each App loads only the DLLs inside its own /bin directory.

This requires:

App1 and App2 must be separate virtual apps in IIS (Not subfolders of the same app unless marked as apps)
Each app must have its own web.config and bin folder

What will not work:

Putting both DLLs in the same /bin folder
Using <Probing> to force different versions
Using shadow copying tricks

ASP.NET will always load from its own /bin before probing any additional paths, So you cannot override that inside one application.

Reference: https://learn.microsoft.com/en-us/previous-versions/aspnet/ff651860(v=orm.10)

Let me know if you need any further help with this. I will be happy to assist. If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Corey Fleig 185 Reputation points

2025-12-09T17:50:14.1333333+00:00
Thank you for your advice. This is my first time setting up additional web apps, so I'd like to ask you one more thing;

We have an application pool called "My Apps"

We also built a site called "My Apps"

All kinds of apps are inside the site, with a common top-level "bin" folder.

So all these apps share the bin DLLs. So are you saying it should be as easy as removing the top level "bin" folder, and making sure each app has it's own bin folder?

The other option is adding more pools. But I've never done that. I can create a new pool, but I don't know if I'm supposed to create a new site as well, or create a new pool inside and existing pool, or what.
Corey Fleig 185 Reputation points

2025-12-10T00:55:03.1866667+00:00

I tried placing a "bin" inside each app, and removed the top level "bin". The problem now is that each web.config blows up. So there's more to it than just isolating apps.
Susmitha T (INFOSYS LIMITED) 1,640 Reputation points Microsoft External Staff

2025-12-10T12:28:33.85+00:00
Thanks for reaching out!

You cannot simply delete the top-level bin unless each folder is turned into an independent IIS application with its own Application pool.

Right now, your folders are not separate apps, so IIS treats them as one single application, which is why they all share the parent /bin and why the web.config files break.

To Fix it:

Create a separate IIS Application for each app folder.

Give each app its own /bin folder (old DLLs in app1/bin, new DLLs in App2/bin)

You do not need to create a new site unless you want to -- just separate applications under the same site.

Why your web.configs fail right now:

Because IIS still thinks all folders belong to one application, so multiple web.config files conflict.

Once each folder is converted to its own application, each one gets:

Its own AppDomain

Its own bin folder

Its own assembly loading

Its own web.config

Then everything works.

Let me know if you need any further help with this. I will be happy to assist.
If you find this helpful, Kindly mark the provided solution as "Accept Answer", so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
Corey Fleig 185 Reputation points

2025-12-10T17:04:52.2333333+00:00
Okay - wow, this is helping out a lot. Now I'm understanding it better, so thank you! :) Right now my only site is installed with about 10 folders inside. So I right-clicked on the site name, and chose "Add Application." That makes sense now, but what happened was that the application I typed in, it replicated all 10 folders inside it:

BEFORE picture:

My Site/

Folder 1 Folder 2 etc.

AFTER picture:

My Site/

My New App1/ Folder 1 Folder 2 etc. Folder 1 Folder 2 etc.

So is there a way to simply create a new application with just one new folder? Or will I have to rebuild all the apps one at a time?

I ask only because we don't have a TEST IIS environment to monkey with. We only have production, and I'm nervous to try things out.
Corey Fleig 185 Reputation points

2025-12-10T22:42:18.64+00:00

thank you for helping me - I finally figured it all out! I just needed to click the right things in the right order, and it all came together. Again, thank you so much!
Susmitha T (INFOSYS LIMITED) 1,640 Reputation points Microsoft External Staff

2025-12-11T05:34:29.2566667+00:00

Thank you for your response. We will close this thread since the issue has been resolved. If you experience any more issues, please start a new thread and we will be happy to assist you.

Answer 2

To use multiple DLLs with the same name in different applications without causing conflicts, you can consider the following approaches:

Separate Application Pools: If you're hosting your applications on IIS, you can configure each application to run in its own application pool. This way, each application can have its own set of assemblies, and they won't interfere with one another.
Use Different Directories: Place the newer version of the DLL in a separate directory specific to the application that requires it. You can then modify the application's configuration file (e.g., web.config) to include a <probing> element that points to the specific directory where the newer DLL is located. However, as you mentioned that probing did not work for you, ensure that the path is correctly specified and that the application is configured to look in that directory first.
Assembly Binding Redirects: If you have control over the applications, you can use assembly binding redirects in the web.config file. This allows you to specify which version of the DLL to load at runtime, but this may not work if the newer DLL is not backwards-compatible.
Shadow Copying: Enable shadow copying for your applications. This allows the application to load assemblies from a temporary location rather than the bin directory, which can help avoid conflicts.
Use Strong Naming: If you have the ability to modify the newer DLLs, consider strong naming them. This creates a unique identity for the assembly, allowing you to have multiple versions of the same DLL in the GAC (Global Assembly Cache) or in different directories without conflict.

By implementing one or a combination of these strategies, you should be able to run multiple applications that require different versions of the same DLL without issues.

Answer 3

Bruce (SqlWork.com) 81,981 Volunteer Moderator

Typically you would rename one of the dlls and use an alias statement to change the namespace. This won’t work if the dll calls other duplicate dll’s.

If this is .net 4.* the you can but the the dll’s in their own folder and create an isolated app domain and load the dll’s into this app domain and use cross domain calls.

https://learn.microsoft.com/en-us/dotnet/framework/app-domains/use

a better approach is to just update the code to use the versions.

Share via

How to use multiple DLLs with the same name

2 additional answers

Your answer