views:

1866

answers:

5

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?

A: 

The only way I've thought of so far is to have my NAnt build script copy the DLL from an outside (versioned) lib directory into the \Bin directory prior to building. I don't like this very much because it introduces an process dependency that's outside of Visual Studio: developers must ensure that the library is copied before trying to build inside VS.

Craig Walker
A: 

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.

Jason Berkan
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.
Craig Walker
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?
Craig Walker
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.
Jason Berkan
A: 

I save 3rd party assemblies without source code in source control. In their own directory outside of the Project - `C:\Projects\3rdPartyAssemblies' This way any projects / developers that need them can reference them.

Shawn Simon
But how do you get the reference to the DLL to stick to the project? That's the crux of my question.
Craig Walker
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.
Shawn Simon
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.
Craig Walker
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.
Shawn Simon
A: 

Project references are stored in the .csproj or .vbproj file which should be under source control. The .refresh file is completely irrelevant and is only an assistance file for the studio. If you create a directory local to the project or solution and store all compiled references not already in the GAC in this directory, you can then add that directory to the source control and reference directly from there. This way all developers are guaranteed to have the most current copy (from source control) of the .dll when they perform their next compile and it will never impact the /bin.

Getting your developers to "Get Latest Version" ... you're on your own for that one. I still haven't figured it out.

Maybe another memo.

Joel Etherton
Web sites don't have a .csproj or .vbproj, hence the use of the .refresh file.
Jason Berkan
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.
Joel Etherton
+3  A: 

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.

Neal