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?
Related
i have been read xUnit getting test results in vsts
after build , it's run my test , and show all testcase pass.
but the task is failed, i can't find any reason from the log.
vstest.console.exe
"D:\a\1\s\Services\AuthManagement\XXXX.Management.Api.Test\bin\Release\netcoreapp2.1\XXXX.Management.Api.Test.dll"
"D:\a\1\s\Services\AuthManagement\XXXX.Management.Api.Test\obj\Release\netcoreapp2.1\XXXX.Management.Api.Test.dll"
/EnableCodeCoverage
/logger:"trx"
/TestAdapterPath:"D:\a\1\s"
/InIsolation
i run this command in my local nb, there's no any error.
in vsts there's had the error message
System.IO.FileNotFoundException: Unable to find tests for D:\a\1\s\Services\AuthManagement\XXXX.Management.Api.Test\obj\Release\netcoreapp2.1\XXXX.Management.Api.Test.dll. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk" and framework version settings are appropriate. Rerun with /diag option to diagnose further.
the XXXX.Management.Api.Test Project , already install Microsoft.NET.Test.Sdk nuget package
Based on the error message, it looks up the files in obj/release folder, which should be exclude, so you can add !**\obj\** to exclude the files in obj folder. For example;
**\*xUnitTest*.dll
!**\obj\**
I had a Visual Studio 2015 solution with 3 projects and then started using VS 2017 adding 2 new xunit projects. When I build everything succeeds but the tests are being discovered in Test Explorer.
I reviewed this question Found conflicts between different versions of the same dependent assembly that could not be resolved and set my Build output to Diagnostic and I am getting a warning saying:
1> C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2052,5): warning MSB3277: Found conflicts between different versions of "System.Runtime" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
i have updated the 3 .csproj files from
Project ToolsVersion="14.0"to
Project ToolsVersion="15.0"
added <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to the 2 VS2017 projects which did not have it
set Test -> Test Settings -> Default Processor Architecture to x64 and my Build -> Configuration Manager -> Platform to x64 or Any CPU (some projects do not allow x64?)
I have reinstall nuget packages across the solutions with Update-Package -reinstall
updated and repaired VS2017
I can see my tests on solution load but once I build the solution the tests are grayed out. Then I tried to run one and they say
4/4/2018 4:34:25 PM Warning] Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run:
DatabaseRestoreManager.exe, RestoreBaseLib.IntegrationTests.dll, RestoreBaseLib.Tests.dll, RestoreBaseLib.dll, Restores.exe are built for Framework Framework45 and Platform X64.
Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
[4/4/2018 4:34:26 PM Warning] [xUnit.net 00:00:00.1993869] Exception discovering tests from RestoreBaseLib.IntegrationTests: System.BadImageFormatException: Could not load file or assembly 'RestoreBaseLib.IntegrationTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'RestoreBaseLib.IntegrationTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
Most people with this issue seem to have the problem in a nuget package but my issue seem to be a msbuild or VS15 to VS17 upgrade with testing and System.Runtime.
Is there anything that can fix this? I want to be able to run xunit tests in VS17.
I am trying to build, package and deploy a web application using Teamcity but for some reason Teamcity is ignoring the properties that I am passing to MsBuild.exe.
I have created a step in the build configuration to build, package and deploy teh application to the local server. Here are the properties:
/P:Configuration=Release
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
/P:DeployIISAppPath=MyDeployedWebsitePath
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=Administrator
/P:Password=******
/P:MsDeployServiceUrl=MyServerName
Passing them as command line parameters to MSBuild step or declaring them as System Properties in Parameters tabs doesn't seem to work. Teamcity builds the application but ignores the package and deployment steps!
If I execute MSBuild through command line on the same server (with the same params) the package and deployment works.
I am following the steps mentioned in Troy Hunt's series: https://www.troyhunt.com/you-deploying-it-wrong-teamcity_26/
I have read a lot of stack overflow questions and it seems to work seamlessly for others. I am not sure what's going wrong.
I would really appreciate any help.
Update - Build log
> Step 2/2: Build (MSBuild) (51s)
[18:32:48][Step 2/2] ##teamcity[buildStatisticValue key='buildStageDuration:buildStepRUNNER_18' value='0.0']
[18:32:48][Step 2/2] Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:C:\TeamCity\buildAgent\work\b12fe165603f4f19 /msbuildPath:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
[18:32:48][Step 2/2] in directory: C:\TeamCity\buildAgent\work\b12fe165603f4f19
[18:32:56][Step 2/2] Targets were not defined in the build configuration.
[18:32:56][Step 2/2] MSBuild command line parameters contain "/property:" or "/p:". It is recommended to define System Property on Build Parameters instead.
[18:33:02][Step 2/2] EnsembleID.Web\EnsembleID.Web.csproj.teamcity: Build target: Build (37s)
[18:33:40][Step 2/2] Process exited with code 0
It turned out to be a version issue :/
I tried different options for MSBuild version - Microsoft .Net Framework 4.5, 4.0 etc.
Finally, Microsoft Build Tools 2015 option worked.
For the past week I have been banging my head on this and I lost track of what all different permutations I tried. I had installed all the different versions of framework tools and web deployment tools, I am not sure why the other options didn't work for me. So if someone is facing a similar problem, make sure to try out different MSBuild version.
I installed like these...
sonarqube-6.2 | sonar-scanner-2.8 | sonar-scanner-msbuild-2.2.0.24 | msbuild 14
And I made windows batch file to build and scan(sonar). but some projects are ok. but some projects are failed.
batch file is...
MSBuild.SonarQube.Runner.exe begin /k:%PROJECT_KEY% /n:%PROJECT_NAME% /v:%BUILD_VERSION% /d:sonar.verbose=true
MSBuild.exe "projects" /t:build /v:m
MSBuild.SonarQube.Runner.exe end
error message is...
SonarQube Scanner for MSBuild 2.2
Default properties file was found at C:\SONARQUBE\sonar-scanner-msbuild-2.2.0.24\SonarQube.Analysis.xml
Loading analysis properties from C:\SONARQUBE\sonar-scanner-msbuild-2.2.0.24\SonarQube.Analysis.xml
Post-processing started.
SonarQube Scanner for MSBuild 2.2
18:50:20.591 Loading the SonarQube analysis config from C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\conf\SonarQubeAnalysisConfig.xml
18:50:20.592 Not running under TeamBuild
18:50:20.593 Analysis base directory: C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube
Build directory:
Bin directory: C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\bin
Config directory: C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\conf
Output directory: C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\out
Config file: C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\conf\SonarQubeAnalysisConfig.xml
Generating SonarQube project properties file to C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\out\sonar-project.properties
The SonarQube MSBuild integration failed: SonarQube was unable to collect the required information about your projects.
Possible causes:
The project has not been built - the project must be built in between the begin and end steps
An unsupported version of MSBuild has been used to build the project. Currently MSBuild 12.0 upwards are supported
The begin, build or end steps have not all been launched from the same folder
Writing processing summary to C:\jenkins_slave_buildpc\workspace\amis3_client_sonar.sonarqube\out\ProjectInfo.log
Generation of the sonar-properties file failed. Unable to complete SonarQube analysis.
18:50:20.615 Creating a summary markdown file...
18:50:20.617 Post-processing failed. Exit code: 1
I executed same batch file for sonar. but some project is ok. and some project is failed..
What makes this error message?
I got the similar error when trying to run MSBuild.SonarQube.Runner end command in teamcity.
Begin step and MSBuild step to build project was working fine.
When I given full path for runner and MSbuild in teamcity. It worked for me.
C:\SonarQube\sonar-scanner-msbuild-3.0.2.656\MSBuild.Sonarqube.runner.exe
begin /k:"Sonar key here" /n:"Sonar project here" /v:%build.number%
/d:sonar.log.level=DEBUG
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" [path for .sln file
here] /t:Rebuild
/p:VisualStudioversion=14.0;Configuration=Release;Platform="Any CPU"
C:\SonarQube\sonar-scanner-msbuild-3.0.2.656\MSBuild.Sonarqube.runner end
Another thing worth checking--especially if you're trying to run SonarQube from a build server--is whether it is operating in the local system profile. From the logs, you may see something like:
Installed SonarQube.Integration.ImportBefore.targets to C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\MSBuild\15.0\Microsoft.Common.targets\ImportBefore
I found that this path did not exist, even though SonarQube's scanner happily claimed to have installed its targets there. My solution was to create a build agent account for executing the build tasks. This will cause SonarQube to install its targets to the user profile MSBuild folder. For example:
C:\Users\buildagent\AppData\Local\Microsoft\MSBuild\15.0\Microsoft.Common.targets\ImportBefore
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