如何让VS编译时自动引用Debug|Release版本的dll
1个回答
展开全部
公司一些早期的项目,把所有工程都放到一个解决方案下了,导致整个解决方案编译很慢,而且也不便于类库的复用和维护。因此我们决定把工程按照功能划分到不同的解决方案里头,然后定期发布dll到TFS配置库上固定的TeamProject下面,以后应用程序引用时就不添加工程,而是采用添加dll的方式。但是现在遇到一个问题,发布dll一般会发布Debug和Release两个版本,那么应用程序应该引用哪个版本呢?
理想情况下,开发测试的时候应该使用Debug版本,这样抛异常的时候调试很方便。正式部署到生产环境的时候可以使用Release版本,这样性能好一些。但是添加dll的时候VS只允许选择一个版本。
我们知道,VS支持把工程不同的编译选项保存到不同的配置中,编译时根据当前使用的配置来决定采用什么样的编译选项。默认会新建Debug和Release这两个配置。开发时我们一般选Debug配置,发布时一般选择Release。
如果添加dll时也能根据当前配置引用不同路径的dll,那就好了。在stackoverflow上搜到了相关的信息,说可以修改csproj工程文件,使用VS宏变量来指定dll路径。用记事本打开研究了一番倒也挺简单的.找到引用类库的地方:
False
LibDebugClassLibrary1.dll
只需要改成:
False
这样编译时VS就能根据当前配置到Debug或者Release文件夹下寻找相应的dll了。
不过这样一来,以后添加dll的时候就有点麻烦了,每次都要手工编辑csproj文件。同事吴突发奇想,能不能在发布的时候再建一个名为“$(Configuration)”的文件夹,以后直接引用这个文件夹下的dll即可,都不需要修改csproj文件了。我的第一个反应是VS应该会对这样的路径做转义之类的,因为和内置变量名冲突了。但本着“不确定的事情要通过实验去验证”的精神,我做了这个实验,发现居然可以!VS才不管你路径包含什么字符串呢。
最后的结论,发布dll时,需要同时发布到以下三个文件夹:$(Configuration)MyLibrary.dllDebugMyLibrary.dllReleaseMyLibrary.dll
其中$(Configuration)文件夹下的dll无所谓哪个版本了,这个纯粹只是为了骗过Visual
Studio的而已,编译时根本不会用到。添加dll引用的时候,直接引用$(Configuration)MyLibrary.dll即可。
希望此文对你有帮助。
理想情况下,开发测试的时候应该使用Debug版本,这样抛异常的时候调试很方便。正式部署到生产环境的时候可以使用Release版本,这样性能好一些。但是添加dll的时候VS只允许选择一个版本。
我们知道,VS支持把工程不同的编译选项保存到不同的配置中,编译时根据当前使用的配置来决定采用什么样的编译选项。默认会新建Debug和Release这两个配置。开发时我们一般选Debug配置,发布时一般选择Release。
如果添加dll时也能根据当前配置引用不同路径的dll,那就好了。在stackoverflow上搜到了相关的信息,说可以修改csproj工程文件,使用VS宏变量来指定dll路径。用记事本打开研究了一番倒也挺简单的.找到引用类库的地方:
False
LibDebugClassLibrary1.dll
只需要改成:
False
这样编译时VS就能根据当前配置到Debug或者Release文件夹下寻找相应的dll了。
不过这样一来,以后添加dll的时候就有点麻烦了,每次都要手工编辑csproj文件。同事吴突发奇想,能不能在发布的时候再建一个名为“$(Configuration)”的文件夹,以后直接引用这个文件夹下的dll即可,都不需要修改csproj文件了。我的第一个反应是VS应该会对这样的路径做转义之类的,因为和内置变量名冲突了。但本着“不确定的事情要通过实验去验证”的精神,我做了这个实验,发现居然可以!VS才不管你路径包含什么字符串呢。
最后的结论,发布dll时,需要同时发布到以下三个文件夹:$(Configuration)MyLibrary.dllDebugMyLibrary.dllReleaseMyLibrary.dll
其中$(Configuration)文件夹下的dll无所谓哪个版本了,这个纯粹只是为了骗过Visual
Studio的而已,编译时根本不会用到。添加dll引用的时候,直接引用$(Configuration)MyLibrary.dll即可。
希望此文对你有帮助。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询