Location of Third Party Dll's in Version Control for .NET Project

守給你的承諾、 提交于 2019-12-21 04:32:10

问题


What would be the ideal location (directory) to check in Third Party Reference Dll's for a .NET Project in a version control system. Typically i have seen most people to put them under bin, so that the runtime can automatically pickup these files. However is that the right way to go.

I originally wanted to have a separate directory which is parallel to bin called lib which will contain all third party Dll's , but this needs changes to the applications config file so that the lib directory is picked up by the run time. My idea over here is that lib will contain third party dll's while bin will contain the projects Binary (could be Dll or Exe)

What is the preferred way, The concentration over is the location in the Version Control and not just the Physical File System.


回答1:


We use the following directory structure (more details available on my blog):

Solution\
  Libraries\
    third-party DLLs here
  Source\
    Project1\
    Project2\

Each project references (using the "Browse" tab in the Add Reference dialog) the assemblies in the "Libraries" folder. These are automatically copied to each project's "bin" folder at compile time. (The "Libraries" folder is, of course, committed to version control.)




回答2:


Have the separate directory contain the third-party assemblies (this will make things easier to maintain in source control) and then create references in your project to those assemblies. Then, on build, your third-party assemblies will be copied into your \bin and you won't have to make any configuration changes.




回答3:


I assume those 3rd party DLLs would be used in more that one project of yours. Therefore putting the DLL directly under bin of every project means you end-up having as many DLL copies (in the VCS) as there are projects, which is not elegant. As Andrew H. mentionned, if the DLLs are truly common, they should be put in a common directory that will be refered to by all other projects that need it. The only catch here is being able to distinguish different versions of the same DLL: over time, you may end up with something like:

/common/ThirdPartyLibrary.dll  (version 1.2)    
/common/ThirdPartyLibrary.dll  (version 1.3)

The best way I know (for now) around that is renaming the 3rd party DLL with an explicit version number and refer to that new name in your project, such that your project will always, for sure, refer to the right version. Like:

/common/ThirdPartyLibrary_v1.2.dll    
/common/ThirdPartyLibrary_v1.3.dll


来源:https://stackoverflow.com/questions/763309/location-of-third-party-dlls-in-version-control-for-net-project

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!