ASP.NET and Visual Studio - Adding project references vs Bin Folder DLL

后端 未结 5 2116
甜味超标
甜味超标 2021-02-14 19:32

I just started a new job yesterday and this is only my second job working in ASP.NET. We were setting up my dev box and were having trouble with some third party components like

相关标签:
5条回答
  • 2021-02-14 19:47

    Usually I just drop them in the bin, unless it is part of something that isn't that simple. Sitecore for example installs itself and has a couple of folders that it likes to use for putting some of its own code to give an example of something non-trivial.

    0 讨论(0)
  • 2021-02-14 19:52

    It depends on how your project is set up. If you want to precompile your site (and get Intellisense to work properly) you have to have a Visual Studio reference. But anything dropped in the bin folder will be automatically loaded by ASP.NET at runtime... so it's possible to access that assembly's controls/objects in code behind without adding a project reference.

    For small projects I just throw the DLL into the bin and add reference. For more complex sites/projects, I have a dedicated "library" folder for third party add-ons and code.

    0 讨论(0)
  • 2021-02-14 19:53

    Si is very correct there. Also: keep your bin folder for results of builds/compiles. Like said before use a "library" folder to link to. I even do this with devexpress.

    Normally by installing devexpress it will install its dll's in the GAC, and you can reference them like you reference the standard .Net dll's. But for version control it is much easier to use a library folder.

    In that way, you can be sure that everybody uses the same version of devexpress (the one that is in sourcesafe) to test their code, and you will have less problems with code that compiles on your machine, but does not on another.

    0 讨论(0)
  • 2021-02-14 20:04

    We version control our 3rd party assemblies using Subversion, then pull them down via svn:externals into a sub-directory of the solution or project in question, which then references them (and copies into bin).

    This provides quite a few benefits:

    1. Build servers are happier, need less maintenance and are less brittle.
    2. We have a history of releases and can explicitly control versioning for each solution/project by setting the revision number on each svn:external. For example your trunk code may be using latest Telerik version, but your release branches are using old versions.
    3. We can share 3rd party assemblies for different projects, and be confident they are using the correct versions.
    4. We're not relying on developers installing or upgrading to the correct version, yet they can still add and test new versions without interfering with other projects (assuming you have explicitly defined the revision)
    5. We can test new versions, but easily go back if things don't work.

    So a little more working setting things up, but I think it's worth it. Note that we don't version control (svn:ignore) our bin and obj directories, and the 3rd party assemblies are in the same Subversion repository, referenced by relative pathing.

    FWIW: Subversion 1.6.6 fixes an annoying bug for file based svn:externals. This means you can choose one or more files (e.g. assemblies) from a directory instead of having to pull the whole directory down.

    2013 Update

    With the rise of NuGet, consider hosting your own feed via a local server before opting for using svn:externals, simply because it gives you all the same benefits, plus it's baked into Visual Studio via the Extension Manager and provides for better information and meta-data, e.g. being able to let developers know when there is a new release.

    The only caveat would be to host your feed using a Win2008 or higher server, as I ran into some issues with our old Win2003 server using SSL with windows authentication to secure the feed. I believe this was due to the older version of IIS used in Win2003, but couldn't verify.

    0 讨论(0)
  • 2021-02-14 20:05

    I always preffer to have project reference rather than having DLL reference. Below are the main reason for it.

    • The project, which is adding the reference of other project, will not be up to date.
    • Any change to the referred project will not directly reflect. User has to manully delete the old reference and add new reference.
    0 讨论(0)
提交回复
热议问题