2

I work with a live asp.net web application. I would like to copy a .dll file into its bin folder on the server where it is deployed (not add it to the application solution in VS). This .dll file would not be used/referenced by any part of the live asp.net application (i.e. the namespace of the class library that this .dll contains is not used by any part of the existing application, nor would it be invoked by reflection).

It is a requirement that this .dll be located in the bin directory with all the other .dlls that the asp.net application requires.

It can be garenteed that the .dll does not share the same name as an existing .dll in the bin directory nor will it ever so there should be no risk of overwriting an existing file.

My understanding is that copying this .dll (or any other file type for that matter) into the bin folder would do nothing and come with no consequences, it would just sit there causing no harm and not interfering in any way with the existing application. Is this an entirely safe thing to do (assuming no naming conflicts) or are there any risks that I may have overlooked that could in any way harm the existing application or affect its working temporarily or otherwise?

mark_h
  • 5,233
  • 4
  • 36
  • 52
  • 1
    `"My understanding is that copying this .dll (or any other file type for that matter) into the bin folder would do nothing and come with no consequences, it would just sit there causing no harm and not interfering in any way with the existing application."` - That's my understanding as well. Have you tested this and found something different? – David Jun 06 '17 at 10:12
  • I'm sure that if you replace a `.dll` in the bin folder it can force the app pool to recycle. – Dave Becker Jun 06 '17 at 10:16
  • @David thanks for the response. No I have found nothing to suggest otherwise and local testing has confirmed this however the damage caused by breaking the application would be so great that I must be certain that nothing will happen. – mark_h Jun 06 '17 at 10:17
  • @DaveBecker, I would not be replacing a .dll that was a dependency of the original application. It simply has to be in the bin directory – mark_h Jun 06 '17 at 10:20
  • 1
    Just done a bit of a search and apparently ANY change to the bin folder will cause a recycle. https://stackoverflow.com/questions/9802812/does-any-change-in-any-file-inside-bin-folder-cause-application-recycle-in-asp-n (post is getting a bit old now though) – Dave Becker Jun 06 '17 at 10:24
  • 1
    I think this will at least cause application pool to restart . – Evk Jun 06 '17 at 10:25

1 Answers1

2

The answer here should be split into what's possible and what's likely.

Likely

Your application will, during its runtime, try to find the DLLs it expects to find. This means that the application is only concerned with the DLL files it knows about.

You can add as many other files to that folder as you want. Barring any name conflicts (which you already guarantee to not occur), the additional files do not matter to the application as it will never try to look up any of these files.

Possible

The above is simply default behavior. It is possible that the application actually looks inside the bin folder and iterates over its files (maybe only DLL files, maybe all files).

An example for why this would ever be done:
When you develop a mod for a game (depending on the game), you create a library. In some cases, your mod will include a DLL file (most often when it changes core game logic). Your mod is then installed in a specific directory. The base game will always look for any existing file in that directory (the mod you added), and try to incorporate it into its runtime.

It's not impossible that your application does something similar, e.g. looks for custom extensions at runtime and incorporates them using reflection.
However, it would be a bad (but again, not impossible) practice to expect these extensions to be put into the bin folder, as opposed to a custom folder.

So my answer is a combination of replies; ordered by desirability

  • I would advise against using the bin folder for unrelated DLL files. I can't think of a good reason why it should ever be done. This smells of a blind company rule that foregoes any common sense or good practice.
  • Since you seemingly cannot avoid putting the DLL in there, can you at least put it in a subfolder to segregate the DLL from the application DLLs? It's a matter of keeping things neatly ordered.
  • For most applications, adding the DLL directly to the bin folder shouldn't matter on a technical level. It's a messy solution, but not inherently a problem by itself.
  • If the application looks into its own bin folder at runtime, you can run into problems by adding the DLL and should clearly avoid it. However, I would expect such an application to document this feature. If it is never mentioned that the application does this, it seems fair to assume that it doesn't happen. Of course, that very much depends on your company's documentation quality and common coding practices.

TL;DR
It's a horrible solution. Depending on the application, it might create conflicts. It won't conflict for most standard applications that do not use reflection. It's still a horrible solution.

Flater
  • 12,908
  • 4
  • 39
  • 62