Reference DLLs in ASP.NET without \Bin or GAC

31,296

Solution 1

If you are doing any kind of serious development I would recommend migrating away from the web site project and to a web project as this allows you to manage these kind of dependencies in the same manner across your entire solution.

However, assuming you cannot do that, place all of the assemblies that you need to reference from the web project into a folder somewhere ( e.g. lib\web ) and add a pre-build event to your web project that copies the content of that folder into the bin folder of the web directory. Now whenever you want to add a dependency to your web project you can drop it in the lib\web folder, and add the reference. Whenever you build, all of the referenced assemblies will be copied into the folder so you can delete the bin folder or do a clean checkout and not have any issue.

Solution 2

Technically, in step 3 a little more happens. Visual Studio copies the DLL to your \Bin directory and adds a name.dll.refresh file that contains the path to the original DLL. With SourceSafe, the .refresh file is under version control, so that when you setup a new system and get the latest code from SourceSafe, Visual Studio can find and copy the DLL from the specified location. You should be able to put the .refresh file in svn and have everything work.

Also, I generally create a \Common directory above my project directory, which is where I put the DLLs, and I include that directory in the solution (and source control), so that each version of my project in source control has the correct DLLs.

Share:
31,296
gigimon
Author by

gigimon

Software Developer and Technology Consultant

Updated on July 09, 2022

Comments

  • gigimon
    gigimon almost 2 years

    I have an ASP.NET project under source control (Subversion). For various reasons, I don't want to add the \Bin directory or its contents to source control, so I have it svn:ignored. DLLs are loaded into here during a Visual Studio build, and I can start with a clean directory and/or delete all the contents of this directory and still have a successful build.

    There are two ways that I reference code for inclusion in the project:

    1. In the Web.config element //configuration/configSections/system.web/compilation/assemblies. I can <add> any DLL that's in the GAC this way. I do this for all of the System dlls.
    2. In the VS Solution, there's a setting at Project/ProjectSection/ProjectReferences that lets me specify included references to other projects in the solution.

    (Note that this is different than non-web projects, where all references to external dependencies are stored in the project file. There's no project file for VS web projects so they have to be stored somewhere else.)

    Now I have a 3rd-party compiled DLL that I'd like to include in the project. Unfortunately, none of the referencing options I've found seem to work for me:

    1. Referencing via web.config/system.web/compilation/assemblies doesn't work unless the DLL exists in the GAC; you can't use a file path. I'd really like to avoid a GAC dependency as it will mean an extra step to make the project work on every target machine.
    2. I haven't found a way to include a file reference in the solution like I can do with project references.
    3. Any time I add a file reference using VS's "Add Reference" dialog, it merely copies the DLL to the \Bin directory. That won't work for me as my \Bin directory isn't persistent across systems.

    Is there another way I can make a reference to a DLL file and have it stick?

  • gigimon
    gigimon over 14 years
    I wondered about that. However, to get .refresh into SVN, I have to have \bin, and if I have \bin I might as well just copy the DLL in there anyway.
  • gigimon
    gigimon over 14 years
    Correct me if I'm wrong, but even with \Common in the solution you still have to manually copy the DLL and/or .refresh into \Bin, right?
  • gigimon
    gigimon over 14 years
    But how do you get the reference to the DLL to stick to the project? That's the crux of my question.
  • Jason Berkan
    Jason Berkan over 14 years
    The .refresh gets created automatically when you add a DLL through "Add a Reference". As long as you put it in source control, and have the DLL in the same place on all machines, everything works. Other machines download the .refresh from source control and during a build, copy the DLL from the specified location. The advantage of putting .refresh in source control instead of the DLL is that the .refresh file is not touched during a build. The DLL is, resulting in an unnecessary check out every time you build.
  • Shawn
    Shawn over 14 years
    Sorry I'm not sure if I understand you. You can include a file reference the same way as a project reference by choosing the browse tab. It does copy it to the bin directory but still maintains the reference.
  • gigimon
    gigimon over 14 years
    Actually, in my testing, it doesn't maintain the reference outside of the presence of the file in the \bin directory. If you close the solution and delete the DLL/.refresh, then when you reopen the solution the reference will be gone from the dialog box. Unlike project or GAC references, the file references are maintained only by the presence of the file in \Bin -- unless there's another way to do it, which is what I am asking.
  • Jason Berkan
    Jason Berkan over 14 years
    Web sites don't have a .csproj or .vbproj, hence the use of the .refresh file.
  • Joel Etherton
    Joel Etherton over 14 years
    You are correct, sir. I misspoke. The references for a website project are actually kept under the ProjectReferences key in the .sln file (which the website should require but may not). Woops.
  • Shawn
    Shawn over 14 years
    I see. Is this an ASP.NET web application project, or just a plain ASP.NET website? Because I created a new web app project, added a reference to an external dll, used the dll in code, built, deleted the bin dir, ran again, and everything worked.
  • remi bourgarel
    remi bourgarel almost 13 years
    The solution you're providing doesn't work : we can't add a pre build event to a web site.