By default, properties defined on the NAnt command line are read-only, even ignoring the overwrite="true" attribute. Is there any way to make them read-write?
I ran into exactly the same problem yesterday. Since I couldn't find a solution, I ended up renaming the command line arguments. Somewhat cumbersome but at least it works.
I was passing in property repo.name via -D:repo.name=MyRepo and tried this:
<property name="repo.name" value="${repo.name}/MySubrepo" />
That gave me a warning and the assignment was ignored. So I changed the name of the command line argument to repo.name.orig.
<property name="repo.name" value="${repo.name.orig}/MySubrepo" />
Would that be possible for you as well?
Related
I'm dealing with a .vcxproj file with the following Link segment:
<Link>
<OutputFile>$(OutDir)$(TargetName)$(TargetExt)</OutputFile>
<SuppressStartupBanner>true</SuppressStartupBanner>
<AdditionalLibraryDirectories>..\lib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<GenerateDebugInformation>true</GenerateDebugInformation>
<AssemblyDebug>
</AssemblyDebug>
<ProgramDatabaseFile>$(OutDir)$(TargetName).pdb</ProgramDatabaseFile>
<SubSystem>Console</SubSystem>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
<TargetMachine>MachineX86</TargetMachine>
<ImageHasSafeExceptionHandlers>false</ImageHasSafeExceptionHandlers>
</Link>
It would seem, I should be able to add more elements to the linker's LIBPATH by simply adding one more argument to msbuild's command line: /p:AdditionalLibraryDirectories=D:\Foo\lib. Unfortunately, this seems ignored and link.exe is invoked with only the /LIBPATH:..\lib argument...
If I edit the file and replace the %(AdditionalLibraryDirectories)-part with the desired path, things work -- linker is invoked with two /LIBPATH: arguments and the executable gets built.
Why can't I specify it as property on command-line, though?
I'm using Visual Studio 2017, with msbuild announcing itself as "Build Engine version 15.9.21+g9802d43bc3".
You'll need to use a completely separate MSBuild property.
For example, on your command line:
msbuild ... /p:FooLibDir=..\lib
and in the project file:
<AdditionalLibraryDirectories>$(FooLibDir);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
The reason that setting AdditionalLibraryDirectories on the command line doesn't work, is that the /p command line option for MSBuild sets properties, whereas AdditionalLibraryDirectories is metadata on the Link item (note how the parent of the AdditionalLibraryDirectories tag is a Link tag, not PropertyGroup).
The way to think about the difference is:
A property is a global variable accessible to everything (hence it can be set on the command line).
Metadata is specific to a single item (e.g., what additional directories to search for libs in, when linking this specific .obj).
Metadata in a ItemDefinitionGroup becomes a "template" that each instance of that item will use when declared.
I want add a property that with a value that is a path to a local directory, for example, <property name="loc" value="C:\Program Files\myDir" />.
This works during the build, but when I retrieve this property I get C:Program FilesmyDir.
What is the right away to represent file references and URL references in config.ini?
Use forward slashes or replace each backslash with two backslashes:
C:/Program Files/myDir or
C:\\Program Files\\myDir
In our nant build script for our web-based application, we <copy> a set of files to a target directory and then run aspnet_compiler over them via <exec>.
<copy> only copies files that have changed, however here is no way to pass this information to <exec>, and I want to avoid running aspnet_compiler when nothing has actually changed.
Options I've tried to find are: <copy> setting a property when any file is copied that can then be checked with <if>; or being able to create a file before the copy and doing something like <if test="any-file-newer-than(targetdir, timestampfile)">. Even better would be if <copy> could return a list of copied files that I can then iterate over to avoid having to process the entire tree, but I think that might be asking a bit too much.
So far, I've drawn a blank: is what I'm looking for possible without writing a custom extension?
Why don't you just simply replace copy task with robocopy? (you're on Windows, right?)
Robocopy returns different exit codes on different successful copy situations:
https://ss64.com/nt/robocopy-exit.html
For example:
0 - ok, nothing copied
1 - ok, something copied
You could do something like this:
<exec program="robocopy.exe" commandline="${SourceDir} ${DestDir}" failonerror="false" resultproperty="ExitCode" />
<fail unless="${ExitCode < 8}" message="Failed to copy"/> <!-- Anything between 0..7 is OK for robocopy -->
<exec unless="${ExitCode == 0}" ...
I have a nant script that ...
1. takes the content of disc-file
2. assigns that content to a nant property
3. and then calls sqlcmd with a -v passing in that property containg the content of the disc file
4. inside the sql script the contents of the file should be used by a stored proc.
The problem is that when the content of the file contains a space the nant build stops with a "Invalid argument" issue
Anone know a way around this ?
The top part of the nant script is ...
<?xml version="1.0"?>
<!-- the main name of this project -->
<project name="Hops" default="all">
<!-- BuildHistory -->
<property name="buildHistoryContents" value="" />
<xmlpeek xpath="/" file="BuildNotes.xml" property="buildHistoryContents"></xmlpeek>
<!-- <echo message="${buildHistoryContents}" /> -->
<!-- ***************** -->
<target name="ExecSql">
<echo message="running sql script : ${SqlBuildScriptsDir}${sqlBuildFileName}" />
<exec program="${SqlCmd}" commandline="-S ${SqlServerInstanceName} -E -d HBus -i ${SqlBuildScriptsDir}${sqlBuildFileName} -v vSchemaVersion=${buildHistoryContents} " />
</target>
The sql script contains the line ...
exec lsp_SchemaVersionUpsert '1.4', N'$(vSchemaVersion)'
A disc file content that works is ...
<BuildNotes>
<Note>
<buildVer>HasNotSpace</buildVer>
</Note>
</BuildNotes>
A disc file content that does not works is ...
<BuildNotes>
<Note>
<buildVer>Has Space</buildVer>
</Note>
</BuildNotes>
The use of all this is pass xml build comments to a table logging version build history for the db schema.
Does anyone know an alternate method or know a way through this ?
The next part, added after Phillip Keeley correcty solved first part (the SPACE Problem)
I simplified the original task to simplify the question.
There is also a Quoted Attribute Problem ; xml quoted attributes cause the nant build to fail with "Invalid Argument".
eg this will cause nant to choke but removing the dt attribute will enable the nant build to succeed ...
<BuildNotes>
<Note>
<buildVer>1.4</buildVer>
<dateStarted>09/24/2009 11:25:42</dateStarted>
<Item dt="20091008" >SpacesAndNoQuotedAttribute</Item>
</Note>
</BuildNotes>
Any ideas ... ?
Your problem is (of course) in line
<exec program="${SqlCmd}" commandline="-S ${SqlServerInstanceName} -E -d HBus -i ${SqlBuildScriptsDir}${sqlBuildFileName} -v vSchemaVersion=${buildHistoryContents} " />
specifically, in
-v vSchemaVersion=${buildHistoryContents}
The NAnt expression replaces property ${buildHistoryContents} with the stored value--which will include any embedded spaces. Problem is, when calling SQLCMD (I"m assuming that's what ${SqlCmd} resolves to) from a command window, the values for any and all -v parameters are space delimited -- that is, the parser hits -v, reads the next characters through the "=" as the variable name, then reads all characters after the = and through the next space (or end of line) as the value to assign to the variable, and that embedded space will mess you up bigtime.
On the command line, the work-around is to wrap the variable value in quotes:
- v MyVariable=Hello World
becomes
- v MyVariable="Hello World"
That doesn't work here, because it's XML and you have to wrap the commandline attribute of the exec element with quotes... and embedded quotes will, once again, mess you up bigtime.
I believe the work-around here is to use XML macro substitution (I quite possibly have the formal titles of these concepts wrong) for those embedded quotes. This value should be
"
Which means that the following should work:
<exec program="${SqlCmd}" commandline="-S ${SqlServerInstanceName} -E -d HBus -i ${SqlBuildScriptsDir}${sqlBuildFileName} -v vSchemaVersion="${buildHistoryContents}" " />
Please try this and see -- I may have to do something like this myself some day soon.
I have NAnt script which as part of its project calls a batch file using the following task:
<target name="makeplane">
<exec program="C:\WINDOWS\system32\CMD.EXE"
commandline="/C ${make.file} > ${make.log}"
verbose="false"
workingdir="${make.dir}"
basedir="${make.dir}">
</exec>
<delete>
<fileset basedir="c:\">
<include name="program" />
</fileset>
</delete>
</target>
Unfortunately i dont have control over the contents on the batch file and it spews out a lot of garbage onto the screen which is of no use in the log. So to get around this im redirecting the output from the bat file to a text file using the
> ${make.log}
part which equates to "> log.txt".
This redirection seems to create a file called "program" on the C drive and messes up all sorts of services and windows generally doesnt like it. To get around this Im manually deleting this file after the bat file has executed.
The problem is i now need to run a similar task for another project entirely and if they run at the same time then the first will lock the file called "program" and the second will fail. Not exactly a great situation for Continuous integration.
I searched on the net but because the file is called program i get all sorts of rubbish results. Anyone got any ideas on a work around. I tried the output parameter on the exec task but the issue remains the same.
If the file path to the log contains spaces, one generally would want to surround the path in quotes. In order to do this in nant one can use the " entity.
It sounds like this is what's happening in your particular situation. Therefore, if you change your example to the following I think things should work as expected.
<target name="makeplane">
<exec program="C:\WINDOWS\system32\CMD.EXE"
commandline="/C ${make.file} > "${make.log}""
verbose="false"
workingdir="${make.dir}"
basedir="${make.dir}">
</exec>
</target>
Usually this happens because the script is trying to create a file with a long file name with space in it (c:\program files in your case), but it is not using quotes around the long file name.
Here is what I did. I think it is a bit cleaner for complex commands.
<property name="cmd.label" value="\${ss.previous.label}#$Project.SSPath" />
<echo message="Getting $Project.Name source code with label \${cmd.label}" />
<property name="cmd" value=""\${tfs.root}\tf.exe" get $Project.SSPath "/version:L\${cmd.label}" /force /recursive /noprompt"/>
<exec program="cmd.exe"
workingdir="\${shadow.dir}"
failonerror="true"
verbose="true">
<arg value="/c" />
<arg value=""\${cmd}"" />
<arg value="> nul" />
</exec>