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.
Related
I'm at a total loss. We have TeamCity installed (TeamCity Professional 2017.2.3 (build 51047)). We run the MSBuild step with:
MSBuildVersion: Microsoft Build Tools 2017
MSBuild Tools Version:
15.0
and Command Parameters:
/t:Clean /p:DeployOnBuild=true /t:build /t:publish /p:PublishProfile=Properties\PublishProfiles\Deploy.pubxml /p:PublishDirectory=Deployment /p:Configuration=Release /p:VisualStudioVersion=15.0
When we run the build t shows:
_DeploymentUnpublishable [11:16:53][_DeploymentUnpublishable] Skipping unpublishable project.
TeamCity outputs at the start:
Starting:
C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe
/workdir:C:\TeamCity\buildAgent\work\c36dd5b119aec7b
"/msbuildPath:C:\Program Files (x86)\Microsoft Visual
Studio\2017\BuildTools\MSBuild\15.0\bin\MSBuild.exe"
If I navigate to the msbuildPath in the CommandLine and run the same command it builds and publishes without issue.
Any help would be greatly appreciated.
MSBuild Step In TeamCity:
I had this issue and resolved it by setting a Parameter towards the publishing profile.
This is what i had:
- *.csproj would build and publish in visual studio locally.
- TeamCity builds fine but when asked to Publish sends me the not helpful _deploymentunpublishable
I tried all the commands in the msbuild line but only the following setup works:
pre-step: Create a Publishing profile (*.pubxml) which outputs to a folder within your build. This should be saved in your /Properties folder of the build.
inside your configuration page, go to Parameters.
Add a new Parameter for "System". Call it PublishProfile (system.PublishProfile). Give it a vaule which is the name of your publish profile file or *.pubxml
enter image description here
create a new step (or amend existing publish step), runner type "MSBuild" and in the Targets box type WebPublish
enter image description here
You dont need any command line parameters as your pubxml will handle all this.
Thats it, give it a try and your code should now publish to the folder you set in the publishing profile.
I am trying to run the "Visual studio build task" in VSTS CI, but its failing with the following error:
Build error
I read it here bclbuildWhat does the Microsoft.Bcl.Build NuGet package do?
and passed the MSBuild arguments as /p:BclBuildImported=Ignore but still it complains that nuget restore didn't occur. What could be the problem?
Nuget restore task:
Nuget-restore task
Firstly make sure you can build the project locally with VS. Then add Nuget Restore task in the build definition to restore the packages.
UPDATE:
Just check your Nuget.config file, make sure you have set the correct feeds/package sources you want to consume and the package Microsoft.Bcl.Build.1.0.21 is included in the sources.
See Specifying sources in NuGet.config for details.
Besides, you can also try to create a new build definition with the Nuget restore task, then provide the nuget.config file and proper path to solution, also try with other Hosted agents.
I'm trying to restore NuGet packages for a .NET Core solution using NuGet Installer TeamCity build step. The 'MSBuild auto-detection' chooses MSBuild v4.0 instead of v15.0 which is required for .NET Core projects:
[15:41:53][restore] Starting NuGet.exe 4.1.0.2450 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.4.1.0\tools\NuGet.exe
[15:41:53][restore] MSBuild auto-detection: using msbuild version '4.0' from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319'.
[15:41:53][restore] Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
[15:41:53][restore] Process exited with code 0
This leads to the compilation error in the 'MSBuild' TeamCity step that runs after the package restoring:
Assets file 'C:\TeamCity\...\MyProj\obj\project.assets.json' not found.
Run a NuGet package restore to generate this file.
For the 'MSBuild' TeamCity step I choose the MSBuildTools version manually as described in this SO answer:
But I didn't manage to find the similar setting for the 'NuGet Installer' step. Am I missing something?
I managed to overcome this specifying the -MSBuildPath command line parameter:
As #PeterLai said, nuget version is the right place to look.
So, because I had the same problem here, I updated Nuget inside Teamcity / Administration / Integrations / Tools.
I moved from 3.4.3 to 4.6.2, and just rebuild.
Now it finds my visual studio 2017 msbuild, version 15!
BEFORE:
NuGet command: D:\...\NuGet.CommandLine.3.4.3\tools\NuGet.exe restore D:\...\proj.sln
...
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
AFTER:
NuGet command: D:\...\NuGet.CommandLine.4.6.2\tools\NuGet.exe restore D:\...\proj.sln
...
MSBuild auto-detection: using msbuild version '15.5.180.51428' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
2 things,
It might be because it's running it from the folder Starting NuGet.exe 4.1.0.2450 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.4.1.0\tools\NuGet.exe, and not in the source code directory as you'd expect.
Have you got a packages.config file in your project?
If you are only using .NET Core / .NET Standard projects ("SDK-based" csproj), you don't need to restore with nuget.exe but can create an msbuild invocation that calls the Restore target:
msbuild /t:Restore the.sln
This also applies to non-core/standard projects (classic csproj) if they use the PackageReference package management format:
After adding MSBuild arguments:
/tv:14.0 /p:VisualStudioVersion=14
I get the following error message:
C:\Builds\10\IW_*****\Dev\src\Sites\******\Properties\CompileLicxFiles_Patched.targets (98): The "LC" task was not given a value for the required parameter "TargetFrameworkVersion".
I'm trying to build using VS2015 (TFS2013 server)
Found this: https://connect.microsoft.com/VisualStudio/feedback/details/1406942/new-required-lc-task-parameter-targetframeworkversion
However, I've checked and all projects in the solution have 4.5.2 version assigned.
Log (it seems it's still using VS2013):
Added package 'NEST.1.9.1' to folder ...
Added package 'FluentAssertions.4.17.0'....
...
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\10\IW_****\Dev\src\Solution123.All.sln" /nr:False /fl
To use VS 2015, the argument should be /p:VisualStudioVersion=14.0.
First thing first.
I was using VS2015 to edit TfvcTemplate.12.xaml build template which cased issues. For some reason, when using VS2015 - it was modifying the xaml document incorrectly. To make any type of changes to TfvcTemplate.12.xaml template you have to use VS2013!
TfvcTemplate.12.xaml does not contain "ToolPath" variable. To make this work I simply added "14.0" (quotes necessary) under "ToolVersion"
TFS2013 will use VS2015 MSBuild to run the build. No need for MSBuild command line switches. Works without them.
Output log:
Run MSBuild00:13:39 C:\Program Files\Microsoft Team Foundation Server
12.0\Tools\nuget.exe restore "C:\Builds\9************\packageRestore.proj" -NonInteractive MSBuild
auto-detection: using msbuild version '14.0' from 'C:\Program Files
(x86)\MSBuild\14.0\bin'.
You could also just modify your build definition with Visual Studio. On the process tab of the build definition that uses TfvcTemplate.12.xaml expand 2.5 section to see the MSBuild arguments. Add the below arguments to the build definition and save it. I assume your problem was you had /p:VisualStudioVersion=14 instead of /p:VisualStudioVersion=14.0.
/p:VisualStudioVersion=14.0 /tv:14.0
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