We have several projects containing XAML UI and XAML workflow files. Since we enabled execution of MSBuild in parallel, with the flag /m the builds, from time to time we get an exception in the MSBuild task XamlMarkupCompilePass1
##[error]C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets(193,5): Error XC1000: XC1020: Build error occurred in the XAML MSBuild task: 'Could not load file or assembly 'file:///C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\Facades\System.Threading.ThreadPool.dll' or one of its dependencies. Access is denied.
This is just an example, it is also happening sometimes on NuGet packages and not only .NET framework assemblies.
What is our setup: We have build servers and on each we have at least 2 build agents.
What did we try out already:
Turning off build agents to have only one per server, still running MSBuild with /m --> failed with Access denied
Run msbuild without /m --> was successful, but not a solution because of too long running build
Try to use a hidden flag for MSBuild, to retry on access denied MSBUILDALWAYSRETRY --> this is only used for Copy MSBuild task and not the XAML msbuild task
Question: Is there a way to affect the MSBuild task XamlMarkupCompilePass1 somehow? or is there another solution than turning off parallel execution of MSBuild? I guess there is also a possibility that XamlMarkupCompilePass2 could fail as well but didn't see that.
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.
I have a ClickOnce project that I'm publishing on DevOps. I've set the MSBuild Arguments property for the WinForm solution's build stage in DevOps to /target:Publish in order to trigger the creation of all the ClickOnce files:
However, that solution also contains an SSDT project, and adding the /target:Publish setting appears to then cause the build process to try publish the SSDT too. That then fails with the error:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1808,5):
error MSB4044: The "SqlPublishTask" task was not given a value for the
required parameter "SqlPublishProfilePath"
Presumably it's failing because there's no publish profile specified in a build parameter for the SSDT to use.
I don't want MSBuild to publish the DacPac to a server, I just want it to create the DacPac. How can I stop the /target:Publish triggering the SSDT publish, is there another build argument I can add to stop that happening?
Notes on what I tried so far to solve this, none of which has worked:
Read about the -target switch in the MS Build official docs in the MSBuild command-line reference and in the MSBuild targets section.
Looked at the code in the .csproj file to try and identify the 'Publish' sections - think Publish must also call Build.
Unticking Deploy for the SSDTs in the solution configuration in VS
Adding entries for False in the Release and Deployment configurations in the SSDT's .csproj file, and also setting that to false for the Debug configuration (as per this question)
Setting MSBuild to only publish one project using the MS Build arguments on DevOps (as per this answer)
Considered pulling the ClickOnce publish out into an entirely separate stage using Mage.exe as per this Walkthrough: Manually deploy a ClickOnce application
Tried to create a publish profile that doesn't actually publish, so that the publish stage can complete (was looking at this question for ideas on that and also the official documentation for SqlPackage.exe)
Eventually I solved the issue above a completely different way. Instead of getting MSBuild to do what I wanted it to, I instead split the solution configuration in two, with one stage for the databases and one for the WinForms project without the databases.
I then used two separate VS Build stages on DevOps with only the WinForms stage still having /target:Publish set.
I've written that up here, but would still like to know the answer to whether it's possible to tell MSBuild not to build the SSDTs when the target is set to Publish?
Our continuous delivery set-up, until recently, was delivering Service Fabric packages using the following command:
msbuild SFApp.sfproj /t:Package
This was necessary because the target Package is unavailable at the solution level. I.e. The command
msbuild SFSolution.sln /t:Package
Fails, as the target does not exist.
As our dependency mesh grows, it gets to a point in which most interfaces projects will not build without a solution file (to work around the "OutputPath does not exist" red herring). There seems to be a way to do that according to this answer. Unfortunately, while targets like Clean work…
msbuild SFSolution.sln /t:SFApplication:Clean
(…snip…)
Build succeeded.
0 Warning(s)
0 Error(s)
…the target Package won't!
msbuild SFSolution.sln /t:SFApplication:Package
(…snip…)
Build FAILED.
"SFSolution.sln" (SFApplication:Package target) (1) -> SFSolution.sln.metaproj :
error MSB4057: The target "SFApplication:Package" does not exist in the
project. [SFSolution.sln]
0 Warning(s)
1 Error(s)
(Solution/project folders/names omitted/paraphrased for clarity. I can provide the actual logs if necessary.)
So the question is: how could I, using the Command Line, build one project using the Package target and the solution file?
Or how can I otherwise package a Service Fabric application from the command line?
It's bad idea to compile sfproj file(and any other project file) without sln, because it can bring wrong content to its output from referenced projects. Only solution has a knowledge about what project to compile in what configuration.
To make Package similar to "Right Click->Package" in VS:
Just add to your sfproj the following target
<Target Name="ForcePackageTarget" AfterTargets="Build" Condition="'$(ForcePackageTarget)' =='true'">
<CallTarget Targets="Package"/>
</Target>
And then running normal build on solution you may trigger the package step by /p:ForcePackageTarget=true :
msbuild yoursolution.sln /t:Build /p:ForcePackageTarget=true /p:Configuration=Release /p:Platform=x64
Actually it performs two-in-one steps, build and package, with respect to Solution Configurations on all referenced projects
MSBuild only supports a small set of target names that can be specified at the solution level. As you've discovered, Package is not one of them. You'll need to execute two separate calls to MSBuild: one which builds the solution and one which calls the Package target on the sfproj. The Package target of an sfproj has a dependency on the Build target so it will ensure that the sfproj and its project dependencies are built.
I had the same problem and fixed it by changing the Platform in the failing projects to explicitly build for x64.
Click Build > Configuration Manager and make sure that the assemblies are compiled for the x64 platform, that should also set the Output Paths in the corresponding .csproj files.
The actual command line action that is being executed is this:
"C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe" "C:\agent\_work\1\s\Project\SFProject.sfproj" /t:Package /p:platform="x64" /p:configuration="release" /p:VisualStudioVersion="14.0"
Use the below script.
C:\Program Files (x86)\Microsoft Visual Studio 14.0> msbuild "Fabric.sfproj" /t:Package /p:Configuration=Release
Service fabric requires Target to be set in x64 platform,
So change all you reference projects target to x64 platform.
you can do this by using configuration properties of your solution. If x64 is not listed in 'Configuration Properties' click configuration manager in the same window and under platform column for the required project add new project platform as x64.
Hope this works for you.
We have had the exact same problem as you had and I have been looking around for a solution all over the web and did some experiments. Those are the steps that worked for us:
Don't manually add a target anywhere as suggested by other answers on StackOverflow. Not necessary. Especially in a CI environment, you want to build the projects separately anyways.
Prepare the projects in the Solution: Change the target platform for all projects to x64
Build the application
msbuild.exe SFAplication.xproj /p:Configuration=Release /target:rebuild
Package the App
msbuild.exe SFAplication.sfproj /p:Configuration=Release /target:Package
We have CCNET and msbuild creating our regular builds. I am trying to update our process so msbuild creates zipped deployment packages and msdeploy sends them out to the target IIS7 web servers. I was having trouble doing the end to end solution, so for testing I'm trying to just call msbuild from the command line for now. I execute this statement:
msbuild /target:Build;Package /P:Configuration=Staging;OutDir=D:\Builds\Viper.ProdSupport\MSDeployPkg\ /verbosity:diagnostic D:\builds\ViperPortal.ProdSupport\Code\Viper\Viper.UI.MVC\Viper.UI.MVC.csproj
and I get this error:
/temp/global.asax(1): error ASPPARSE: Could not load type 'Viper.UI.MVC.MvcApplication'. [D:\builds\ViperPortal.ProdSupport\Code\Viper\Viper.UI.MVC\Viper.UI.MVC.csproj]
Oh, and for our specs: .NET4, MVC3, IIS7/Win2k8 64bit for web server. Build server is Win2k8 as well, but I'm testing the scripts locally on a win 7 32bit box with ccnet and a full dev config mgmt environment setup locally.
Does anyone have any ideas why I'm getting this error? I read some messages complaining about the aspnet compiler or changing where your bin deploys assemblies to, but none of those seemed to really apply here. I am simply trying to call msbuild, which has been working all along til now. We have a custom msbuild script for our solution. I tried using both that and the mvc csproj file as the build configuration file. Please help! Thanks!
this happens if you've set to precompile views, i.e. you changed:
<MvcBuildViews>false</MvcBuildViews>
to
<MvcBuildViews>true</MvcBuildViews>
This is because MSBuild throws the output to different places than Visual Studio might, so you should change the folder on which the precompiling runs on from:
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)" />
to:
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
Ive got CC.Net and NAnt (and MSBuild) running on a new VM-based build server (Win7-64 Pro).
CC.Net can call MSBuild just fine - but I run into problems there when dealing with project-scope builds. The conditionals just dont have what I need. Not even close.
So I decide to deal with those conditions by calling MSBuild with NAnt, which fails every time. When I run the nant script from the command prompt, I get this:
[loadtasks] Failure scanning "C:\nant\bin\extensions\common\2.0\Collection
Gen.dll" for extensions. Could not load file or assembly 'Microsoft.VSDesigner,
Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of
its dependencies. The system cannot find the file specified.
Buildfile: file:///c:/c7/projects/dyndata/dyndata.build
Target framework: Microsoft .NET Framework 4.0
Target(s) specified: build
build:
[loadtasks] Scanning directory "c:\nantcontrib\bin\lib" for extension assemblies
.
[echo] Building DynData v7.0.7
BUILD FAILED
c:\c7\projects\dyndata\dyndata.build(24,12):
Failed to start MSBuild.
c:\c7\projects\dyndata\dyndata.build(24,12):
External Program Failed: C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbui
ld.exe (return code was 1)
Total time: 0.4 seconds.
c:\c7\projects\dyndata\dyndata.build(24,12):
Failed to start MSBuild.
c:\c7\projects\dyndata\dyndata.build(24,12):
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe' failed to start.
The directory name is invalid
The Designer assembly is present on this machine, which has VS2010 Pro installed on it.
The build folder is correct.
The framework folder is correct.
Umpteen searches for nant/msbuild and this message have yielded nothing substantive.
These items have been tried and failed to change the results:
Nant msbuild task with .net 4.0 rc
.NET projects build automation with NAnt/MSBuild + SVN (tho I am using Vault)
I tried to build the nant code so I could debug the problem via VS2010's debugger but the source project is an unworkable mess and wont even begin to build.
Ideas are welcome:)
I think the first error about Microsoft.VSDesigner is just a warning - not a failure. On my developer box and build server I have VS2005 and VS2010 Pro installed and I do not have Microsoft.VSDesigner version 7 installed. I have version 8 and 9 installed but not 7.
It looks like the "build" target is running in nant and then then it fails. You are loading the tasks from nantcontrib then trying to start msbuild. How are you starting msbuild? Could you post the part of the nant file that starts it? What version of nant are you using? Does running nant with -v and -debug+ flags show anything helpful?