I have the following:
Web.Config (this is a segment of an NLog configuration)
<target name="fileAsException"
xsi:type="FilteringWrapper"
condition="length('${exception}')>0">
... removed ...
</target>
This is translated to the following when built with release:
<target name="fileAsException"
xsi:type="FilteringWrapper"
condition="length('${exception}')>0">
... removed ...
</target>
As you can see the condition expression has been HTML Encoded resulting in the > replacing the >. This causes the condition to not work.
There is nothing specific to this within my web.release.config file, it is simply copied over from the base web.config.
How can I suppress this encoding?
I have spoken to Microsoft and they have asked me to open a bug.
https://connect.microsoft.com/VisualStudio/feedback/details/797554/web-config-transforms-are-html-encoding-some-of-the-config-and-breaking-it
Related
I need to add the ability to a phing build to:
Parse an existing xml file within the project area to get an existing build number (in format 1.2.3)
Ask the user what type of 'change' this is (i.e. major, minor, fix)
Based on the response of the user at the time of run, upgrade the respective digit from the build number (if major increase 1 by 1; if minor increase 2 by 1; if fix increase 3 by 1)
Store the build number back into the original xml file
Have the new build number available for use when naming a zip file (later in the build).
Wondering if anyone already has a phing build file that does something like this or if you happen to know what phing tasks might help with these steps?
As a starting point you could do it without overhead using the version task (it uses a property file to store the version information) or with some more effort from a xml file.
The following example build script (documentation links can be found in the description attributes) contains both ways.
<?xml version="1.0" encoding="UTF-8" ?>
<project name="version test"
default="help"
phingVersion="3.0"
description="https://stackoverflow.com/questions/68584221/phing-update-version-number-in-xml-manifest"
>
<target name="help" description="usage help">
<echo>Usage:</echo>
<echo>bin/phing xml-file-based-workflow</echo>
<echo>bin/phing property-file-based-workflow</echo>
</target>
<target name="xml-file-based-workflow"
description="version handling with xml file"
depends="user-input,handle-xml-version,use-version"
/>
<target name="property-file-based-workflow"
description="version handling with property file"
depends="user-input,handle-property-version,use-version"
/>
<target name="user-input"
description="https://www.phing.info/guide/hlhtml/#InputTask"
hidden="true"
>
<input message="what is your release type?" propertyName="release.type" defaultValue="Bugfix"/>
</target>
<target name="handle-property-version"
description="https://www.phing.info/guide/hlhtml/#VersionTask"
hidden="true"
>
<version releasetype="${release.type}" file="VERSION.txt" property="version.number"/>
</target>
<target name="handle-xml-version"
description="
https://www.phing.info/guide/hlhtml/#XmlPropertyTask
https://www.phing.info/guide/hlhtml/#EchoPropertiesTask
https://www.phing.info/guide/hlhtml/#VersionTask
https://www.phing.info/guide/hlhtml/#DeleteTask
https://www.phing.info/guide/hlhtml/#EchoXMLTask
"
hidden="true"
>
<xmlproperty file="VERSION.xml" />
<echoproperties destfile="VERSION.txt" regex="/version\.number/"/>
<version releasetype="${release.type}" file="VERSION.txt" property="version.number"/>
<delete file="VERSION.txt"/>
<echoxml file="VERSION.xml">
<version>
<number>${version.number}</number>
</version>
</echoxml>
</target>
<target name="use-version"
description="https://www.phing.info/guide/hlhtml/#EchoTask"
hidden="true"
>
<echo message="${version.number}" />
</target>
</project>
Error on Azure Pipeline for NuGet Pack task, using a SDK format .csproj, which autogenerates the .nuspec file:
The process cannot access the file 'D:\a\1\a\*.nupkg' because it is being used by another process.
System.IO.IOException: The process cannot access the file 'D:\a\1\a\*.nupkg' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalDelete(String path, Boolean checkHost)
at NuGet.Commands.PackCommandRunner.BuildPackage(PackageBuilder builder, String outputPath, Boolean symbolsPackage)
at NuGet.Commands.PackCommandRunner.BuildFromProjectFile(String path)
at NuGet.CommandLine.PackCommand.ExecuteCommand()
at NuGet.CommandLine.Command.ExecuteCommandAsync()
at NuGet.CommandLine.Command.Execute()
at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args))
##[error]An error occurred while trying to pack the files.
The .csproj file being built, uses TargetsForTfmSpecificBuildOutput:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<Description>Provides a .....</Description>
</PropertyGroup>
<PropertyGroup>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<Target Name="CopyProjectReferencesToPackage" DependsOnTargets="BuildOnlySettings;ResolveReferences">
<ItemGroup>
<!-- Filter out unnecessary files -->
<_ReferenceCopyLocalPaths Include="#(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference')->WithMetadataValue('PrivateAssets', 'All'))" />
</ItemGroup>
<!-- Print batches for debug purposes -->
<Message Text="Batch for .nupkg: ReferenceCopyLocalPaths = #(_ReferenceCopyLocalPaths), ReferenceCopyLocalPaths.DestinationSubDirectory = %(_ReferenceCopyLocalPaths.DestinationSubDirectory) Filename = %(_ReferenceCopyLocalPaths.Filename) Extension = %(_ReferenceCopyLocalPaths.Extension)" Importance="High" Condition="'#(_ReferenceCopyLocalPaths)' != ''" />
<ItemGroup>
<!-- Add file to package with consideration of sub folder. If empty, the root folder is chosen. -->
<BuildOutputInPackage Include="#(_ReferenceCopyLocalPaths)" TargetPath="%(_ReferenceCopyLocalPaths.DestinationSubDirectory)" />
</ItemGroup>
</Target>
The above modification to the .csproj file is needed due to legacy dll's being required to be built which can't be packaged up on their own. But is based on this answer: https://stackoverflow.com/a/59893520/1231374
Note: Removing the custom package steps still causes the error.
There is an additional error before this, not sure if this could be related.
Error NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below:
- Add a dependency group for .NETStandard2.0 to the nuspec
See the task configuration below:
See the Nuget installer task, which is the first task the installer runs:
I finialy found a "reason" to this problem.
I can't use dotnet cli on my side because my project is not compatible, but I find a workaround.
It seems related to that https://github.com/NuGet/Home/issues/8713, so I used the "Nuget Tool Installer" to force version "5.2.x" and it just works as expected.
I don't understand why this problem is present since 5 minor versions !
The resolution for my problem was to use dotnet pack (as I am working with .NetStandard and .NetCore projects) instead of nuget pack.
In particular to enable the Do not build option. As a pervious step builds the solution and projects within it.
I have a fairly complex and large project that I want to attempt to package as a nuget package for internal use. I want to avoid copying files, because there are quite a few (150 MB+ of binaries). Instead, I am trying to point a package blueprint file to the files using the <file ...> element. Here's a simplified version of the file that I can reproduce my problem with:
<?xml version="1.0"?>
<package >
<metadata>
<id>AgentCore</id>
<version>6.1.0</version>
<authors>kkm</authors>
<description>AgentCore</description>
<references>
<reference file="Utils.dll" />
</references>
</metadata>
<files>
<file src="Kigo\bin\Release\Utils.dll" target="/lib/net40"/>
</files>
</package>
Whatever I try, I am getting the error:
Invalid assembly reference 'utils.dll'. Ensure that a file named 'utils.dll' exists in the lib directory.
I tried suggestions from this answer, but to no avail.
Is it possible to avoid laying out the directory physically, as explained in the NuGet documentation, and use file references instead?
The problem was in the target= directory of the <file ...> element. It must not contain the leading /, i. e. should contain a relative path. The leading slash does not change package layout, but apparently confuses a reference evaluation device in NuGet. A correct line in the above specification should be
<file src="Kigo\bin\Release\Utils.dll" target="lib/net40"/>
Wildcards also work (and that was my original intention):
<file src="Kigo\bin\Release\*.*" target="lib/net40"/>
With the wildcard spec, a <reference=...> correctly accepts any binary packaged by way of wildcard expansion.
I have made a build file for the automated compilation of Oracle Forms files. An excerpt of the code is as follows:
<target name="build" description="compiles the source code">
...
<foreach item="File" property="filename" failonerror="false" >
<in>
<items basedir="${source.directory}\${project.type}\Forms">
<include name="*.fmb" />
</items>
</in>
<do>
<exec program="${forms.path}" workingdir="${source.directory}\${project.type}\Forms" commandline="module=${filename} userid=${username}/${password}#${database} batch=yes module_type=form compile_all=yes window_state=minimize" />
</do>
</foreach>
...
</target>
The build file navigates to the directory containing the forms that the user desires fo compile and attempts to compile each form. The failonerror attribute is set to false so that the build file does not exit if a compilation error occurs. Unfortunately, however, though this prevents the build file from exiting when a compilation error occurs, it also appears to make the build file exit the task. This is a problem because, unless the form that does not compile successfully is the last to be tested (based on the filename of the form in alphanumerical decsending order), there will be one or more forms that the build file does not attempt to compile. So, for example, if the folder containing the forms that are desired to be compiled contains 10 forms and the first form does not compile successfully, the build file will not attempt to compile the remaining 9 forms (ie exit the task). Is there a way to make the build file attempt to compile remaining forms after encountering after failing to compile a form? Thanks in advance!
Apologies, this has now been solved. The problem is that the you need to set “failonerror” in the task instead.
I have a generic common.xml file that holds a number of generic nant targets that are re-used among multiple builds. What I want to do is 'override' some of these nant targets and include additional steps either before or after the existing target is executed.
Are nant targets used from the current file first? ie. If i create a nant target in the current buildfile with the same name as a target in an included file does that one get called and the included one ignored? If that's the case I can just do and call the included target but it would seem like then that would be a recursive call rather then to an included task.
Thoughts?
I had the same question (and found the same results), but I also found a workaround. Allow me to illustrate with an example.
You have a ProjectFile.build and a CommonFile.build. Let's say you want to overwrite a target called "Clean".
You would need to create a new file (call it CommonFile_Clean.build) which contains:
<?xml version="1.0"?>
<project>
<target name="Clean">
<echo message="Do clean stuff here" />
</target>
</project>
In CommonFile.build, you conditionally include CommonFile_Clean.build:
<?xml version="1.0"?>
<project>
<echo message="checking Clean definition..." />
<if test="${not target::exists('Clean')}">
<echo message="Clean target not defined." />
<include buildfile="CommonFile_Clean.build" />
</if>
</project>
In ProjectFile.build, you can either define the Clean target (in which case CommonFile_Clean.build will not be used) or use the default implementation as defined in CommonFile_Clean.build.
Of course, if you have a large number of targets, this will be quite a bit of work.
Hope that helps.
No, I've just tried it for you, as I have a similar set-up, in that I have all of the build targets we use in a commonFile.build and then use the following code to bring it in...
<include buildfile="../commonFile.build"/>
In my newFile.build (that includes the commonFile.build at the top of the file), I added a new target called 'build', as it exists in the commonFile, and here's the error message you get in response...
BUILD FAILED
Duplicate target named 'build'!
Nice idea, probably bourne of OO principles, but sadly it doesn't work.
Any good?