Msbuild not able to create Smart Device CAB Project - msbuild

I am trying to setup TeamCity 7.0 for a smart device application. My visual studio solution contains two projects:
SmartRead -> The mobile application
SmartReadInstaller -> A Smart Device CAB Project for creating CAB file
My TeamCity configuration seems to build the SmartRead application successfully and create the necessary artifacts. But, it seems MSBuild is not able to handle the SmartReadInstaller project. The TeamCity build logs says:
vddproj is not supported by MSBuild and cannot be built.
Here is the complete build log for reference:
[11:46:10]Checking for changes
[11:46:10]Publishing internal artifacts
[11:46:10]Clearing temporary directory: C:\TeamCity\buildAgent\temp\buildTmp
[11:46:10]Clean build enabled: removing old files from C:\TeamCity\buildAgent\work\e252314f72f0d569
[11:46:10]Checkout directory: C:\TeamCity\buildAgent\work\e252314f72f0d569
[11:46:10]Updating sources: server side checkout
[11:46:11]Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:C:\TeamCity\buildAgent\work\e252314f72f0d569 /msbuildPath:C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
[11:46:11]in directory: C:\TeamCity\buildAgent\work\e252314f72f0d569
[11:46:13]SmartRead.sln.teamcity: Build target: TeamCity_Generated_Build (3s)
[11:46:13][SmartRead.sln.teamcity] TeamCity_Generated_Build (3s)
[11:46:13][TeamCity_Generated_Build] MSBuild (3s)
[11:46:13][MSBuild] SmartRead.sln: Build target: Rebuild (2s)
[11:46:13][SmartRead.sln] ValidateSolutionConfiguration
[11:46:13][ValidateSolutionConfiguration] Building solution configuration "Release|Any CPU".
[11:46:13]SmartRead\SmartRead.csproj: Build target: Rebuild (2s)
[11:46:13][SmartRead.sln] Rebuild (2s)
[11:46:16][Rebuild] CallTarget
[11:46:16][CallTarget] SmartReadInstaller:Rebuild
[11:46:16][SmartReadInstaller:Rebuild] Warning
[11:46:16][Warning] C:\TeamCity\buildAgent\work\e252314f72f0d569\SmartRead.sln warning MSB4078: The project file "SmartReadInstaller\SmartReadInstaller.vddproj" is not supported by MSBuild and cannot be built.
[11:46:16]Process exited with code 0
[11:46:16]Publishing internal artifacts
[11:46:16][Publishing internal artifacts] Sending build.finish.properties.gz file
[11:46:16]Publishing artifacts
[11:46:16]Build finished
Please note that I am using Visual Studio (sln) runner for building my application. How do I fix this? How do I build the CAB files for my project?

MSBuild does not support VS deployment projects. You may want to consider moving your installers to WiX as from the next version of Visual Studio deployment projects will become obsolete.
For the current projects build using Devenv.

Related

Build Fails with "Error:The process '/usr/bin/dotnet' failed with exit code 1" after adding "no-build:true" in the dotnet pack command

The CI pipeline works well if I remove the nobuild:true option from the DotNetCoreCLI#2 task to pack the Project (ie to create a NuGet package) but I am not able to understand what special except not building the project does the nobuild option brings.
I need not want to build the Project again as the Previous task have already build the Project and locked the Assembly version of DLLs generated. I want to use the same build to create the NuGet package and to do the same I need to pass the NoBuild option but doing the same breaks the pipeline.
The pipeline gives the error that the DLLs to be packed are not present at the specified location but I tried to look at the location and I could find the DLLs.One thing that confuses me is that though I have given nobuild to be true but still the tasks shows as Building the Project.
- task: DotNetCoreCLI#2
displayName: ".NET pack"
inputs:
command: pack
packagesToPack: ${{ parameters.packagesToPack }}
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: CI_Version
packDirectory: $(build.artifactStagingDirectory)\${{ parameters.packTo }}
verbosityPack: 'Normal'
Its also important to note that the same thing( nobuild:true) works on Windows Agent but it fails on Ubuntu Agent.
PS: It could be a case where windows has upgraded the agent and has caused the issue. I searched over the issue and found that one has to lock the .net SDK in the build pipeline
Thanks for the other answers that may be related to the issue but things were already taken care.
The issue was only on the Linux Environment because of an issue in .NET SDK. Refer here
The error(DLLs could not be found in the path specified ) that was being generated was correct in somehow but also it was misleading. The DLLs were being generated in Release folder at the build stage and when I was packing the DLLs they were being searched in release folder.
Though Release and release remains the same in Windows Environment but Ubuntu being case sensitive generates the Error.
The SDK implementation of .Net Core missed the IgnoreCase in the Regex option and that caused the build to break on switchin to a Linux Agent.
DotnetBuild:
Dotnet Pack:
Solution: Define the folder where to generate the DLLs in the .csproj and the automatically build and pack step would pick the DLLs from there.
For this error NU5026 ,it refers to the project being packed has not been built yet and hence cannot be packed. Please view this reference.
The file ''F:\project\bin\Debug\net461\project.exe' to be packed was not found on disk.
According to your description, you canceled the automatic build before pack. There's possibility that your build task and pack task did't run with same configuration. For example, In dotnet build task, the project is automatically built with Debug configuration, and in the pack task you set the configuration as Release.
In dotnet build task, the project is automatically built with Debug configuration.
In the dotnet pack task , the default Configuration to Package is Release
If you do not cancel the automatic build before pack, in the .net pack task the project is built in Release configuration.
So please check the log of your build task and pack task, make sure the dotnet build command and dotnet pack command use the same configuration.

The SonarQube MSBuild integration failed: SonarQube was unable to collect the required information about your projects

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

Command-line Package Service Fabric Application

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

Visual Studio Team Services Continuous Integration: NuGet Restore Task Failed

I am using Continuous Integration feature in Team Services (was Visual Studio Online). My build definition targets a specific project in a solution (not the whole solution), which is ClientUI MVC website.
The solution contains three projects:
ClientUI
AdminUI
Client Services
The Build Definition for ClientUI Project:
Repository:
Nuget Installer Step:
I have tried different params but not working.
Visual Studio Build
Before trying to target the a single project, my build definition was targeting the whole solution with the following parameters:
NuGet Installer -> Path to Solution: **\*.sln
Visual Studio Build -> Solution: **\*.sln ; MSBuild Arguments: /p:outdir=$(build.artifactstagingdirectory)
It was working. However now, it generates this error in the Nugget Restore Task:
2016-04-22T21:07:00.6716725Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.98.1\tasks\NuGetInstaller\0.1.25
2016-04-22T21:07:00.8163908Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.98.1\tasks\NuGetInstaller\0.1.25\NuGetInstaller.ps1
2016-04-22T21:07:01.5283529Z ##[error]Cannot find path 'C:\a\1\s\packages.config' because it does not exist.
2016-04-22T21:07:01.5439897Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.98.1\agent\worker\tools\NuGet.exe restore "C:\a\1\s\packages.config" -NonInteractive
2016-04-22T21:07:03.0441507Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-04-22T21:07:03.0597010Z ##[error]Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.
2016-04-22T21:07:03.0909881Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
Try setting "Installation type" to "Install" for "Nuget Installer" task since you are using "packages.config" to install the packages.
For anyone curious, the source of the error about "Please specify either -PackagesDirectory or -SolutionDirectory" is that the build process is trying to issue a command similar to this:
C:\hostedtoolcache\windows\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\MyProject\packages.config -PackagesDirectory packages -Verbosity Detailed -NonInteractive
The below screenshots should help if you want to build a project (rather than the solution) and your nuget "packages" folder is at the solution-level.
Additionally, you may need to specify this as the "MSBuild Argument" in the build task of your project: /p:SolutionDir="/"
I had the same thing sorted it out by changing the mapping - go to Repository tab, I had my mapping to another directory which means the nuget installer could not execute.

NAnt + MSBuild (4.0) == MSBuild launch failure w/directory not found error

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?