How do I use MSBuild Community Tasks to delete a node in web.config. I can update a node using XmlUpdate task but I cannot delete a node. Any ideas.
The XmlUpdate task can do it. I am using the nightly build from 11/30/2010.
<XmlUpdate
XmlFileName="web.config"
XPath="/configuration/appSettings/add[#key='setting2']"
Delete="true" />
The XmlFile task of the MSBuild Extension Pack can also do it:
<XmlFile
TaskAction="RemoveElement"
File="web.config"
XPath="/configuration/appSettings/add[#key='setting2']" />
Related
I created an Azure Devops Build pipeline and i am trying to build my ASP.NET MVC and Angular hybrid site project on bitbucket (git).
The project first gets checked out, and nuget restores the necessary packages, and then the .NET builds. I used windows 2019 as azure pipeline agent for the build to succeed. however, Its taking about 7 minutes to complete, whilst running the tasks (besides .Net) on a ubuntu agent is much faster! takes around 2 mins instead!
Therefore, I'd like to use ubuntu, but im running into an issue with the MSBuild task...
"/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj" (default target) (1) ->
(KillVBCSCompilerAndRetryCopy target) ->
/home/vsts/work/1/s/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8/build/net45/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(23,5):
error MSB4044: The "KillProcess" task was not given a value for the required parameter "ImagePath". [/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj]
According to this post, VBCSCompiler.exe continues running from the Compiler Nuget package (nuget restore task?) so it locks the src folders and prevented future builds from running, e.g. causing error like this:
/home/vsts/work/1/s/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8/build/net45/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(17,5):
warning MSB3021: Unable to copy file "/home/vsts/work/1/s/packages/Microsoft.Net.Compilers.2.4.0/build/../tools/csc.exe" to "/bin/roslyn/csc.exe". Access to the path '/bin/roslyn' is denied. [/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj]
So the solution would be to kill the VBCSCompiler.exe but since i cant actually access the hosted machine during the build, im not sure how to do that.
screenshot of my pipeline so far:
Am i facing a dead-end path here with this approach? The build runs fine on windows 2019 but it just takes too long, so thats why if i can make it run on ubuntu successfully that would be great!
You can have a try with below workarounds:
1,Set MSBUILD arguements /p:UseSharedCompilation=false.
You can add above arguement to the msbuild arguements field of the msbuild task. See here.
2,Upgrade Microsoft.CodeDom.Providers.DotNetCompilerPlatform nupkg to the latest and remove Microsoft.Net.Compilers nupkg from your project. See here for more information.
3, Try Specifing the TTL of Roslyn compiler server.
You can define a pipeline variable VBCSCOMPILER_TTL on the Variable tab to specify a shorter idle time for VBCSCompiler.exe
Or you can add <providerOption name="CompilerServerTimeToLive" value="[num of seconds]" /> under system.codedom/compilers/compiler in the config file. See here for more information.
4, Use CheckIfShouldKillVBCSCompiler target:
You can try add below to your csproj file:
<Target Name="CheckIfShouldKillVBCSCompiler">
<PropertyGroup>
<ShouldKillVBCSCompiler>true</ShouldKillVBCSCompiler>
</PropertyGroup>
</Target>
See here.
The build on Ubuntu 20 finally worked! I don't know why removing these lines resolved the VBCSCompiler issue, but by doing so, the msbuild completed successfully on Ubunutu 20 agent!!
Remove the following lines from the .csproj file:
<Import Project="..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />
<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
To give some context to the answer, this post here indicated that converting from MSBuild-Integrated Package Restore to Automatic Package Restore (nuget restore task) implied that the Microsoft.Net.Compilers <Import> and <Error Condition> snippets are no longer relevant/needed in the .csproj file.
A solution that is built via Azure DevOps pipeline has some projects that use conditional package references such as:
<Choose>
<When Condition="'$(Configuration)'=='Debug'">
<ItemGroup>
<PackageReference Include="Mock.MyPackage" Version="1.0.0" />
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
<PackageReference Include="MyPackage" Version="1.2.0" />
</ItemGroup>
</Otherwise>
</Choose>
The package source is a private NuGet feed.
The dotnet restore task does not respect the conditional package selection. (it restores Mock.MyPackage)
Question:
how can I conditionally restore packages (based on a $Configuration) ?
Remarks:
I have also tried restoring during Visual Studio Build task by specifying an MsBuild argument: /t:restore.
In that case it fails with a message: Failed to retrieve information about XX from remote source. If this command can restore packages how can I specify authorization args for the private feed ?
There is an issue on Github: https://github.com/NuGet/Home/issues/5895 where such issue is mentioned at the end.
Azure DevOps - conditional package restoration
This issue should be related your specify requirement and the limitation for current Visual Studio Build task/dotnet restore.
Just as you test, if we use the restore task, we could not specify the configuration parameter with this task. Since there is no such option to receive the configuration parameter for the restore task. That is the reason why it always restores the default package Mock.MyPackage.
If you use the Visual Studio build task, we could not to specify authorization args for the private feed.
To resolve this issue, I use the Command line V1 task to invoke MSBuild to restore and build the project with following MSBuild argument:
-t:restore;build "CoreConditionRestore/CoreConditionRestore/CoreConditionRestore.csproj" -p:RestoreSources="<MyFeed>/v3/index.json" -p:RestoreConfigFile="<MyNugetConfigPath>\nuget.config" /p:Configuration=Debug
Note: we could save the authorization args for the private feed in the nuget.config file.
As test, it works fine on my side with Devops.
Hope this helps.
A much, much simpler answer is to add in NUGET_RESTORE_MSBUILD_ARGS with a value of /p:Configuration=$(BuildConfiguration) to your pipeline variables. This will actually just pass your build configuration to the NuGet restore task.
This is incredibly poorly documented and it took scouring github bug requests to find it
Environment variable documentation:
https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-environment-variables
Github issue I found this on:
https://github.com/NuGet/Home/issues/7575
Not sure why this isn't enabled by default, either.
As a note, you still need to do the (imo strange)
<Choose>
<When Condition="'$(Configuration)'=='Debug'">
<ItemGroup>
<PackageReference Include="Mock.MyPackage" Version="1.0.0" />
</ItemGroup>
</When>
</Choose>
in your project file rather than the more intuitive:
<PackageReference Include="Mock.MyPackage" Version="1.0.0" Condition="'$(Configuration)' == 'Debug'" />
...which does work with normal Reference directives eg:
<Reference Include="MOCK_DLL" Condition="'$(Configuration)' == 'Debug'">
<HintPath>..\References\MOCK_DLL.dll</HintPath>
</Reference>
I wanted minimal change in deployment configuration, so the following was acceptable.
An empty project is created and all packages which are restored conditionally are referenced there (without any conditions).
Additional argument to msbuild task is added: '/t:restore'
During build the following will happen:
'dotnet restore' will restore all the packages thanks to 1).
Since it does not know a selected configuration it may pick a wrong package (Mock.MyPackage instead of MyPackage).
That is where 2) comes, where msbuild task will restore packages from a local cache made by 'dotnet restore'.
Remarks:
As #(Leo Liu-MSFT) wrote, dotnet restore can authenticate but it does not know configuration, and msbuild knows configuration but it can not authenticate, so package restoration in AzDevOps from private feeds is tricky.
I am using a TFS build project to build a Visual Studio 2015 project that contains a gulpfile for compiling SASS among other things. I am trying to understand the sequence of events using MSBuild Tasks and Task Runner bindings. It appears that MSBuild knows enough to detect and run my default gulp task BeforeBuild:
/// <binding BeforeBuild='default' />
var gulp = require('gulp');
var sass = require('gulp-sass');
var importer = require('sass-importer-npm');
gulp.task('sass', function () {
return gulp.src([
'./sass/**/*.scss',
'./node_modules/font-awesome/scss/**/*.scss'
])
.pipe(sass({ importer: importer }).on('error', sass.logError))
.pipe(gulp.dest('./Content/css'));
});
I am to using an MSBuild target to run after the BeforeBuild target so that I can include the generated files in the project for publishing:
<Target Name="CopyGulpFiles" AfterTargets="BeforeBuild">
Here is my MSBuild call in my build .proj file with the relevant info:
<ItemGroup>
<ProjectsToBuild Include="$(MSBuildThisFileDirectory)..\MyProject.sln">
<AdditionalProperties>
VisualStudioVersion=$(VisualStudioVersion);
OutputPath=$(OutputRoot);
WebPublishMethod=FileSystem;
publishUrl=$(StageFolder);
DeployOnBuild=false;
DeployTarget=WebPublish;
PublishProfile=$(MSBuildThisFileFullPath)
</AdditionalProperties>
</ProjectsToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectsToBuild)" Properties="Configuration=Dev"/>
These two things seem to run in the right order everytime I run them. This raises some questions though:
Would the 'BeforeBuild' binding for Task Runner get executed before the 'BeforeBuild' target in MSBuild?
Are the order of bindings/targets deterministic here?
Does using the AfterTargets property ensure that this is run after the whole 'BeforeBuild' stage (targets and bindings) are completed?
How does MSBuild know how to use my Gulp file? I assume it has to be the same mechanism as visual studio uses.
I ran into the issue where everything worked locally when building with the Task Runner, but Gulp was never called by MSBuild.
I ended up with the following solution, which extends the Compile task with our custom target GulpBuild. In this snippet build is the name of my Gulp task.
<PropertyGroup>
<CompileDependsOn>
$(CompileDependsOn);
GulpBuild;
</CompileDependsOn>
</PropertyGroup>
<Target Name="GulpBuild">
<Exec Command="npm install" />
<Exec Command="gulp build" />
</Target>
Steve Cadwallader's post was very helpful in solving this issue.
The BeforeBuild target should always run before BeforeBuild in MSBuild. The Task Runner is specific to Visual Studio, so this will only happen when building in Visual Studio.
This will help with your questions about ordering.
I have a TFS 2013 build xaml workflow, that eventually calls the Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild activity once for each solution that I want to build. When msbuild.exe is called, it's working directory is the working directory of the current solution being built. I can see this through the 'MSBuildStartupDirectory' property when running msbuild with a 'diagnostic' verbosity.
Unfortunately, I need the working of msbuild.exe to be somewhere else when msbuild.exe starts. This is because I use the MSBuild SonarQube runner that imposes constraints on the directory from which msbuild is called.
I have looked at the 'msbuild' activity and there is no way to control the working directory. Is there another way to control the working directory of this activity?
Its been a while since I edited a build process template but I believe you could use an activity that just executes a command in CMD and provide the full MSBuild command. I'm sure there are tons of variables you will need to setup for this to work.
Instead of editing the build process template have you considered using a PowerShell script in the Post-build script to execute SonarQube?
I still haven't found any way to control the working directory of msbuild. But since I know that the working directory will be the directory of the project being built by msbuild, I created a new proj file at the root of my workspace (where my working directory has to be) and only build this new proj file from my workflow. This new proj file then builds all my other solutions. That way, my working directory is the same for all the solutions being built.
Here is an example of my top level proj file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<Solutions Include="**\*.sln"/>
</ItemGroup>
<Target Name="Build">
<MSBuild Projects="#(Solutions)" Targets="Build"/>
</Target>
</Project>
But beware that doing this may affect the output directory (OutDir) given to each solution. So you may want to do something like this:
<MSBuild Projects="#(Solutions)" Targets="Build" Properties="OutDir=$(OutDir)..\%(Solutions.Filename)"/>
I need a set of tasks that need to be executed exactly once for the entire solution. This will run tasks that will modify each project to run a separate set of tasks for each project. We had done this earlier using a separate project to the solution which had the solution level tasks, but we want to move away from that. Has anyone done this or does anyone have any suggestions on how to implement this?
Since Solution files are not in MSBuild format they are not easily extended or customized. If you want more control over the build process you would have to create a "driver" msbuild file which would replace your solution file. Inside this driver file you would build all the projects that you needed and perform some additional tasks. You would do this using the MSBuild task. Here is a sample showing how to build more than 1 project.
<Project ...>
<ItemGroup>
<Projects Include="proj01.csproj"/>
<Projects Include="proj02.csproj"/>
<Projects Include="proj03.csproj"/>
</ItemGroup>
<Target Name="BuildAll">
<MSBuild Projects="#(Projects)" BuildInParallel="true" />
</Target>
</Project>
So in your case you would just execute the tasks before you build the projects. Also note that I specified the value true for the BuildInParallel indicating that MSBuild can try and build more than one project at once.
An alternative solution is to have a single target that dispatches to an MSBuild invoked target with as many Global properties removed as possible. My team have a target in the InitialTargets of a Directory.Build.props Import'ed props file - something like:
<Target Name="Prebuild">
<MSBuild Projects="$(MSBuildThisFileFullPath)"
Targets="PrebuildWorker"
RemoveProperties="Configuration;Platform;TargetFramework;BuildProjectReferences" />
</Target>
Since MSBuild appears to synchronize parallel builds on the {project file, global properties, target} set, then by removing all of the properties you can synchronize the build and run it once for all projects being built. The downside: you have to maintain the RemoveProperties attribute - MSBuild doesn't have a way to remove all global properties. If something in the build issues a new MSBuild task with a custom property specified, then you'll get a second instance of the Target invoked.
And - of course - your build will be synchronized on this target. You could try hooking the target up by setting, say, CompileDependsOn to depend on the Prebuild target, to allow independent progress in the build. But to have the target run early and ubiquitously using InitialTargets seems like the better option.