如何使用 Nant 0.91解决配置错误？

在下载了 Nant 0.91之后，我得到了一些与配置或安全性相关的相当隐秘的配置错误(见下文)。

我试图简单地将我的 Nant 可执行文件从0.86升级到0.91。

在 Windows7机器上构建时，如何解决以下问题？

Log4net: ERROR XmlConfiguratorAttribute: 正在获取 ConfigurationFileLocation 的异常。必须能够在未设置 ConfigFile 和 ConfigFileExtension 属性时解析 ConfigurationFileLocation。 System.Security. SecurityException: 请求类型“ System.Security. Permission. FileIOPermission，mscolib，Version = 4.0.0.0，Culture = 释放，PublicKeyToken = b77a5c561934e089”的权限失败。检查(对象需求，StackCrawlMark & stackMark，Boolean isPermSet) 检查(CodeAccessPermission cap，StackCrawlMark & stackMark) 在系统。安全。代码访问权限。需求() 在 System.AppDomainSetup.VerifyDir (字符串目录，布尔规范化) 在 log4net. Util. SystemInfo.get _ ConfigurationFileLocation () Config. XmlConfiguratorAttribute. ConfigureFromFile (Assembly source，ILoggerRepository targetRepository)

失败的行动是: 要求第一个失败的权限类型是: 系统。安全。权限。 FileIOPermission 失败的程序集区域为: 互联网

未处理的异常: 系统。保安。SecurityException: 请求 ConfigurationPermission 在尝试访问配置节“ ant”时失败。为了允许所有调用方访问这个部分的数据，在声明这个部分的配置文件中将 section 属性‘ requPermission’设置为等于‘ false’。—— > 制度。保安。SecurityException: 请求类型“ System”的权限。配置。配置许可，系统。配置，版本 = 4.0.0.0，文化 = 中性，PublicKeyToken = b03f5f7f11d50a3a’失败。检查(对象需求，StackCrawlMark & stackMark，Boolean isPermSet) 检查(CodeAccessPermission cap，StackCrawlMark & stackMark) 在系统。安全。代码访问权限。需求() 在 System.Configuration。 BaseConfigurationRecord.CheckPermission 允许(字符串 configKey，布尔需求许可，布尔值 isTrustedWithoutAptca) ——内部异常堆栈跟踪结束—— 在 System.Configuration。 BaseConfigurationRecord.CheckPermission 允许(字符串 configKey，布尔需求许可，布尔值 isTrustedWithoutAptca) GetSectionRecursive (String configKey，Boolean getLkg，Boolean checkPermission，Boolean getRuntimeObject，Boolean requestIsHere，Object & result，Object & result & result RuntimeObject) 在 System.Configuration.BaseConfigurationRecord.GetSection (String configKey) 在 System.Configuration. ClientConfigurationSystem.System.Configuration. Internal.IInternalConfigSystem.GetSection (String sectionName) 在 System.Configuration. ConfigurationManager.GetSection (StringsectionName) 在 NAnt. Console. Console Stub.Framework. GetRuntimeFramework () 在 NAnt. Console. Console Stub.Main (String [] args

(答案即将揭晓，作为参考问题发布... ...)

21204

小开

最佳答案

Oddly enough, this is related to how the executables are extracted from the Nant 0.91 archive. (This made no sense to me until I actually tried it, but it does actually work...)

Source : http://surfjungle.blogspot.com/2011/11/tip-running-nant-091-on-windows-7.html

I found that the problem was Windows 7 security related in that the downloaded NAnt 0.91 zip file needed additional security related configuration to be performed: before extracting, one must right click on the zip file, select Properties and under the General tab, click the button labelled Unblock, then click OK on the Properties window. Now, extract the file to your desired location, ensure it is on the system path, open a new command line and NAnt should run successfully.

小开

I had this same problem, however my Properties/General tab did not contain an unblock button. (I'm not sure why; it seems as though this is potentially related to the fact that I'm running inside VMWare Fusion virtual machine.)

This problem seemed to go away if I used something besides Windows built-in ZIP extractor to extract the file. For example, I used 7-Zip to extract the archive and everything worked fine.

小开

Here's how to unblock all the files recursively after the fact with powershell. Weirdly, unblock-file only checks for the pspath property over the pipe.

get-childitem -recurse c:\nant-92 |
get-item -stream zone.identifier -erroraction silentlycontinue |
foreach { $_.pspath = $_.pspath -replace ':zone.identifier'; $_ } |
unblock-file

Of course you could do it this way, without knowing which was blocked or not:

get-childitem -recurse c:\nant-92 | unblock-file

小开

This can be caused by a different issue: After completing the download of the NANT zip file, Windows 10, for whatever reason, automatically launched a Windows File Explorer Window and drilled into the ZIP file itself.

I didn't notice this, and inadvertently directly moved the FOLDER within the zip file to my target location. Not a proper extraction, even though all of the files and directories appeared intact. This could still be an issue with the way that Windows handles zipped archives. I received the same security errors as documented in this article.

By downloading the NAnt archive fresh, and then using 7-zip to extract it normally, the security issues did not recur.