文件复制在嵌入式资源的长路径上失败 [英] File Copy fails on long paths for embedded resources

问题描述

嗨

当前，我们的夜间构建和嵌入式资源的使用遇到了一些问题.作为夜间自动测试的一部分，我们在测试程序集中利用嵌入式sql脚本进行数据库测试，但是，似乎在构建机器上，构建过程对此感到有些困难. msbuild日志包含以下错误(注意:某些名称空间已被X替换):

< snip>

目标_CopyNonResxEmbeddedResources:
任务复制"

...

obj \ Release \ Linkage.XXXXXXXX.DataAccess.UnitTests.RepositoryTests.ServerStatusRepository.TEST_ServerStatusRepository.sql"
\ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Microsoft.Common.targets(1535,9):错误MSB3021:无法将文件"RepositoryTests \ SecurityProviderFamilyRepository \ TEST_SecurityProviderFamilyRepository.sql"复制到"obj \ Release \ Linkage.XXXXXXXX". DataAccess.UnitTests.RepositoryTests.SecurityProviderFamilyRepository.TEST_SecurityProviderFamilyRepository.sql.指定的路径，文件名或两者均太长.完全限定的文件名必须少于260个字符，目录名称必须少于248个字符. /P>

...

目标_CleanGetCurrentAndPriorFileWrites:

任务"FindUnderPath"

...

C:\ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Microsoft.Common.targets(2843,9):错误MSB3541:文件具有无效值"obj \ Release \ Linkage.XXXXXXXX.DataAccess.UnitTests.RepositoryTests .SecurityProviderFamilyRepository.TEST_SecurityProviderFamilyRepository.sql".指定的路径，文件名或两者都太长.完全限定的文件名必须少于260个字符，目录名称必须少于248个字符.

< snip>

据我所知，这似乎是由于以下原因导致的:合并路径的长度是我们建立自动构建的根源，单元测试程序集的路径以及嵌入式资源的完整名称(即完整的名称空间+文件名)超过260个字符的限制(总和为261 ... argh！).有人可以确认这是实际情况吗?

 

无论如何，此限制"为我们提供了一些替代方案，我对这些替代方案都不满意.我们可以通过在更短的"路径中植根自动构建来获得一些字符，或者可以将程序集的命名空间更改为较短的名称，或者可以使用非常短的默认名称空间创建新的程序集(从而允许使用更长的嵌入名称).资源).但是，所有这些解决方案似乎都是要赢得一些角色，我们将来可能会再次达到这个极限.

 

是否有任何明显的解决方法，我们没有达到路径限制的危险，还是只是需要在命名和文件夹结构中注意避免这种情况?看来，如果这是一个正在执行且失败的简单复制构建任务，难道它不能以某种方式使用相对路径而不是绝对路径吗?

 

任何回应都令人赞赏

 

解决方案

对此有两种想法.

Hi

We are currenttly running into some issues with our nightly build and our use of embedded resources. As part of our nightly automatic test we utilize embedded sql scripts in our test assemblies for database testing, however it seems that the build process is somewhat choking on this on our buildmachine. The msbuild log contains the following errors (note:some of the namespace is replaced by X's):

<snip>

Target _CopyNonResxEmbeddedResources:
          Task "Copy"

...

obj\Release\Linkage.XXXXXXXX.DataAccess.UnitTests.RepositoryTests.ServerStatusRepository.TEST_ServerStatusRepository.sql"
            C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1535,9): error MSB3021: Unable to copy file "RepositoryTests\SecurityProviderFamilyRepository\TEST_SecurityProviderFamilyRepository.sql" to "obj\Release\Linkage.XXXXXXXX.DataAccess.UnitTests.RepositoryTests.SecurityProviderFamilyRepository.TEST_SecurityProviderFamilyRepository.sql". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

...

Target _CleanGetCurrentAndPriorFileWrites:

Task "FindUnderPath"

...

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(2843,9): error MSB3541: Files has invalid value "obj\Release\Linkage.XXXXXXXX.DataAccess.UnitTests.RepositoryTests.SecurityProviderFamilyRepository.TEST_SecurityProviderFamilyRepository.sql". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

<snip>

As far as I can tell this seems to happen due to the combined length of the path were we root our autobuild, the path to the unittest assembly plus the complete name of the embedded resource (which is complete namespace + filename) exceeds the 260 character limit (in combination it is 261...argh!). Can anybody confirm that this is what is actually happening?

 

Anyway, this "limit" leaves us with a few alternatives, none of which I'm all too happy about. We could gain a few characters by rooting our autobuild in a "shorter" path or we could change the namespace of the assembly to something short or we could create a new assembly with a very short default namespace (thus allowing for longer names of the embedded resources). However, all these solutions seems to be about gaining a few characters and we will probably hit this limit sometime in the future again.

 

Are there any obvious workarounds where we are in no danger of hitting the path-limit or do we simply need to take care in our naming and folder structure to avoid this sort of thing? It seems that if it is a simple copy-build tasks that is being executed and fails, could it not somehow use relative paths and not absolute paths?

 

Any response is much aprreciated

 

解决方案

Two thoughts on this one.

这篇关于文件复制在嵌入式资源的长路径上失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！