其它关于本主题的文章请看我以前的文章
<再谈.net项目类库dll的管理及Framework 文件重用方法>
javascript:void(0)
即采用了上一篇文章之后. 这种共享文件夹, 共享输出dll的方式仍然会有一些问题不能解决.
第一个问题是: dll 的依赖关系无法处理.
新项目中引用common项目的dll时, 需要知道 common项目又引用了哪个 dll 很头疼.
第二个问题是: dll 的版本冲突.
举个例子. Elmah 项目中引用了 Json.Net 2.0 . 而我在新项目中忘记了 又引用了Json.net 3.0 和Elmah项目. 这样的项目依赖导致dll引用版本冲突..很难解决.很麻烦.（虽然后来知道了使用配置文件来解决这个问题，方法如下：）
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<!--<dependentAssembly>
<assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
</dependentAssembly>-->
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" />
</dependentAssembly>第三个问题是: dll 的版本依赖太多. 形成了依赖链.很难解开.
这一点在java的开源项目上最明显.. 需要很多的jar包. jar包之间还有冲突.jar包的版本问题. 这个问题常常困扰java开发人员.. 到目前为止也没有什么有效的解决方法..
对于以上3个问题, 有两个解决方案.
一是 使用NuGet, 并且搭建公司自己的NuGet服务器. 把开源项目经过筛选放到自己的服务器里. 这样可以控制开源版本的随意升级导致的公司内部系统不稳定和版本冲突. 而且也可以把自己公司内部的一些项目打包起来放进去… NuGet 本身就拥有自动解决dll依赖的功能.非常强大.建议用来管理开源项目和一些很底层的不需要依赖很多dll 的项目.
第二个使用svn的文件夹共享功能, 也就是svn的文件夹快捷方式..具体操作方法请自行百度. svn:externals 仅需设置一次其它开发人员即可生效..方便管理. 这种方法适合用来放util工具类. 原因是util工具类一般功能单一,.基本上一个文件干一个事情..例如sqlHelper, stringHelper. util项目却由于长期的积累却比较大. 我的util类就多达50多个... 这些都是能够大量减少工作量的代码... 但是对于这种工具类组成的Common项目. 由于功能各异,单独建立项目又不合适.而且它们组成的依赖dll会非常多... 对于此类Common项目我建议使用svn的文件夹共享功能. 把需要的工具类包含进来, 不需要的则排除掉.
