We try to migrate our old XAML build to new build system with task on on-premise TFS2015 Update1. In XAML build we have step where we check-out some files do some modification and do check-in. I found powershell helper where is connection to TFS. Than I can check-out files, get list of pending check-out, but cannot do check-in. When I call
$tfsProvider.Workspace.CheckIn($pendingChanges, "some text")
I get error
Exception calling "CheckIn" with "2" argument(s): "Could not load file or assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies
I think problem is that assembly Microsoft.TeamFoundation.VersionControl.Client.dll depends on assembly Microsoft.TeamFoundation.WorkItemTracking.Client. But this assembly is not in Agent worker folder. Is only way to get this assembly to copy to agent folder or install VS2015 on machine with agent and load assembly from VS folder?
Thanks
Regards
If you want to use TFS API to check in, the assemblies must be installed on the Machine and you must import them in your PowerShell script.
Other ways to check in files would be:
With PowerShell:
You can install TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for details:PowerShell and TFS: The Basics and Beyond
With Batch Script:
You can install Team Explorer on the machine and use TF Checkin command to check in the files.
Edit the build worspace files and use tf commnads in custom/powershell task eq.
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Catch the TF.exe out it could report the errors event if everyting is ok.
Just like you said，you must make sure your build agent has the same environment with your dev machine.
The simple way is to copy the dll file on the agent folder. Or you can use Nuget to Install-Package. Suggest you to install VS2015.
Related
I am trying to use a DLL artifact from a developers build pipeline in my VSTS MSTest build pipeline. I need to reference this DLL but I get an error - Error CS0246: The type or namespace name 'Adv' could not be found (are you missing a using directive or an assembly reference?)
I am able to download the DLL's/Artifacts successfully to the agent using Download Build Artifacts option in my pipeline.
How can I get my build in the VSTS pipepline to use the downloaded DLL artifacts on the agent and get rid of this error?
I found out you need to use the copy files option to get the DLL's where you want them. I first tried \bin\debug but the problem there was the build creates these areas automatically and it overwrote my file copy. I noticed in the build log it was considering looking here for the DLL's - C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0.
I updated the copy files to copy there and the solution builds just fine now.
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 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.
Hi I am banging my head for last few days.
Here is the situation ...
1. I have VSO account which maintains the TFS in cloud.
2. Installed a build server/agent on another machine. (Works fine)
3. Tried to build(XAML build) one solution using that server/controller.
4. Got an error saying ...
"The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."
The build server and the agents are from TFS 2015 and the project is a Visual Studio 2015 project using framework 4.6. I was expecting "v14" folder for target files during build. Why it is trying to find things from "v11" folder ? And how do I solve this.
I know I can copy files to "v11" but I don't want to escape the facts. There should be a reason and a proper fix. Any help would be nice.
Several solutions for you to correct this error:
S1: Install MSBuild.Microsoft.VisualStudio.Web.targets from NuGet gallery via running the following command: Install-Package MSBuild.Microsoft.VisualStudio.Web.targets.
Then replace the following line in your .proj file
<Import Project="$(MSBuildBinPath)\Microsoft.WebApplication.targets" />
with
<Import Project="$..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0\tools\VSToolsPath\WebApplications" />
S2: Set the /p:VisualStudioVersion=12.0 MSBuild argument in the build definition.
S3: Copy the Microsoft.VisualStudio.Web.targets file to the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications folder on the build agent machine.
S4: Install VS2012 on the TFS build agent machine just like Patrick mentioned above.
And related cases: Microsoft.WebApplication.targets and Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
The WebApplications\Microsoft.WebApplication.targets (11.0) (which comes from VS2012) is referenced in your web application, so the Visual Studio 2012 should be installed on your build server to resolve this issue.
Be note that, to guarantee TFS build runs successful, you should make sure your build agent machine has the some environment as dev machine.
Did you restore a previous collection on TFS 2015 from a previous TFS version? Did your solution or any projects in your solution get created prior to VS2015?
I'm trying to get a Lightswitch Project into Teamcity and have tried the following runner types:
Visual Studio (sln)
MSBuild
Command line (ran MSBuild through the command line)
All 3 runner types gave me the same error when building the Lightswitch solution:
The "UnpackExtensionsToProjectDir" task failed unexpectedly. System.NullReferenceException: Object reference not set to an instance of an object.
Lightswitch has already been installed on the server. Have tried building the solution manually using Visual Studio on the server and it builds fine. Have also tried building the solution via the command line (using MSBuild) and it builds fine too.
Would like to ask if somebody was able to get Lightswitch building nicely on TeamCity. Cheers.
This is how you build via the Command line (using TeamCity)
Pre-requisites)
First make sure you have not checked in the extensions directory, this can cause issues when building.
Check that you have installed any visual studio extensions on the build machine .ie ExtensionsMadeEasy. You can test this by opening the solution in visual studio on the build machine and trying to do a build.
Lastly, in TeamCity do not use the msbuild task, use command line to call msbuild.
Step 1)
msbuild.exe mylightswitchproject.lsproj /p:OutDir=C:\test\stuff\;configuration=Release
Step 2)
Create a bat file to copy your output to the correct folder structure.
robocopy C:\test\stuff\bin C:\test\localrelease\bin *.* /MIR
robocopy C:\test\stuff\Resources C:\test\localrelease\Resources *.* /MIR
robocopy C:\test\stuff\Web C:\test\localrelease\Web *.* /MIR
robocopy C:\test\stuff\ C:\test\localrelease\ ClientAccessPolicy.xml
robocopy C:\test\stuff\ C:\test\localrelease\ default.htm
robocopy C:\test\stuff\ C:\test\localrelease\ Home.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Login.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ LogOff.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Silverlight.js
robocopy C:\test\stuff\ C:\test\localrelease\ web.config
You can now take this folder and release it to the next environment.
Finally, if you want to create a web deployment package, out the box visual studio 2010 does not support this. However, you can copy this into an existing website then "Export" your application into a package that is then ready for web deployment via powershell.
The previous answers didn't work for us but Yaegor's answer provided some direction.
The issue we had was extensions are installed at the user level, not the system level. This meant the MSBuild process could not find the required extensions.
Our solution was to use a user account on the build server, log into account, setup VS.NET such that the LS project builds, and then switch the TeamCity agent service to use the new user account.
With this we were able to use the Solution runner (which is preferable to the CLI runner since it provides better logging and reporting).
For not Lightswitch-specific part: If command line works from console, but fails in TeamCity, most probably the issue is in the user or running as a service. You might try running TeamCity agent with the same environment.
When command line works you can then try MSBuild and Solution runners.
I ran into the same error when trying to set up an automated build for a lightswitch application using bamboo. Turned out to be the version of msbuild being called. If the 64bit version is called (from bamboo or the command line) I get the error:
UnpackExtensionsToProjectDir" task failed unexpectedly.
Switching to the 32bit version of msbuild fixes the problem.
32bit Path: 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe'
64bit Path: 'C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe'