How do I resolve configuration errors with Nant 0.91?

Question

After downloading Nant 0.91, I'm getting some rather cryptic configuration errors relating to configuration or security (see below).

I'm trying to simply upgrade my Nant executables from 0.86 to 0.91.

How can I resolve the issues below when building on a Windows 7 machine?

log4net:ERROR XmlConfiguratorAttribute: Exception getting ConfigurationFileLocation. Must be able to resolve ConfigurationFileLocation when ConfigFile and ConfigFileExtension properties are not set. System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed. at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark) at System.Security.CodeAccessPermission.Demand() at System.AppDomainSetup.VerifyDir(String dir, Boolean normalize) at log4net.Util.SystemInfo.get_ConfigurationFileLocation() at log4net.Config.XmlConfiguratorAttribute.ConfigureFromFile(Assembly sourceAssembly, ILoggerRepository targetRepository)

The action that failed was: Demand The type of the first permission that failed was: System.Security.Permissions.FileIOPermission The Zone of the assembly that failed was: Internet

Unhandled Exception: System.Security.SecurityException: Request for ConfigurationPermission failed while attempting to access configuration section 'nant'. To allow all callers to access the data for this section, set section attribute 'requirePermission' equal 'false' in the configuration file where this section is declared. ---> System.Security.SecurityException: Request for the permission of type 'System.Configuration.ConfigurationPermission, System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed. at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark) at System.Security.CodeAccessPermission.Demand() at System.Configuration.BaseConfigurationRecord.CheckPermissionAllowed(String configKey, Boolean requirePermission, Boolean isTrustedWithoutAptca) --- End of inner exception stack trace --- at System.Configuration.BaseConfigurationRecord.CheckPermissionAllowed(String configKey, Boolean requirePermission, Boolean isTrustedWithoutAptca) at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) at System.Configuration.BaseConfigurationRecord.GetSection(String configKey) at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName) at System.Configuration.ConfigurationManager.GetSection(String sectionName) at NAnt.Console.ConsoleStub.Framework.GetRuntimeFramework() at NAnt.Console.ConsoleStub.Main(String[] args

(Answer is forthcoming, posting as a question for reference....)

Montagna

still the same issue with NAnt 0.92 and Windows 8.1. But this was expectable. As can be found in another comment also for Windows 10 -- is there another tag to add? – Eyebright

Answer 1

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.

Montagna

Also, save the downloaded .zip file to your local computer, and then Unblock it, followed by Extracting. I tried this whilst the file was saved on a network share and Windows freaked as though it wasn't unblocked. #ProTip – Caporetto

In case anybody was wondering this solution also works for Windows 10 – Revisionist

Another (translation) oddity: in German the button is labelled Zulassen – Eyebright

This also applies to the NAnt 0.92 zipped archive. – Team

Answer 2

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.

Ares

Absolutely! But even if you mostly use 7-Zip to compress, it's sometimes confusing to hit the right context menu item when decompressing, because the built-in option is so attracting ;) – Eyebright

Answer 3

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.

Team

this is the easiest way for people having 7-zip installed – Cartload

Answer 4

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

Esplanade