Have a CI build set up in a very simple solution (MVC webapp, Service, MSTest project)
The build shows orange with the following:
Handle MSTest Exception There is no working folder mapping for
/Heartbeat/Source/BvtAutomation/Local.testsettings
Now, here's the kicker, that is not the source branch being built, it is another project altogether! I cannot find any reference to it in the build definition or anywhere in my solution (WinGrep .. the whole nine yards!)
Anyone seen anything similar to this or have a suggestion as to what I might try?
Thanks!
In TFS2010 when building with DefaultTemplate.xaml, the test files to run are not specified relatively to the mapped workspace, but instead by their complete path from Source Control.
So to fix the issue:
Edit your build definition
Go to the Process tab
In the 2. Basic section, select Automated Tests and click the ... button to edit the test settings.
In the Automated Tests dialog, browse for the .testsettings file in the branch you're building.
This may help: select build definition in the Team Explorer, right-click -> Edit build definition. On the 'Workspace' tab you can configure sources to be got to the build machine. HTH
Related
I have a solution checked in to a TFS branch. That solution includes a project located in another TFS branch. Our sys admin creates a build definition so that each time we check code in. An automated build is triggered. The automated build is failing because it doesn’t see the project file of the project located in another branch. What are we doing wrong?
Just as you said, the reason is that "it doesn’t see the project file of the project located in another branch."
During the build, the first step is getting the sources from repository. If missing the needed files for the solution during getting sources, the build will be failed.
In your case, you need to include another branch (which the project located in) in Repository Mappings, means that you need to also get the needed sources from another branch.
Actually, the best way to fix that is adding the project to the solution in the same branch.
I have an on-prem 2017 install of TFS.
Other similar builds work just fine however this new build i have created fails at the first step - NuGet Restore.
The path set is: ***.sln
I will add that I created the new build by copying from another (working) build. There aren't many options to set in the task so I'm not sure what went wrong.
Attached is the result from the log page.
Any help appreciated.
thanks.
According to the error info
no matching files were found with search pattern: E:\vstsagent\_work\5\s\**\*.sln
Seems the build agent is lacking of the solution file.You could double check this on the build agent folder E:\vstsagent\_work\5\s\** to see if there are or not.
Please go through your repository mapping settings, mark sure including and not cloaked that .sln file.
I have managed to chain two TFS builds together using Jason Stangroome's chaining build definition template. This gives me the capacity to execute one build definition after the next:
CertificateRepository-CI (Continuous Integration Build)
CertificateRepository-IntegrationTests
The latter will automatically be executed if the former is successful. I am stumped by the lack of Build Definition Templates that are able to download and extract the contents of the preceding build's drop folder and perform actions upon these artifacts, in this case running SpecFlow/NUnit integration tests.
In this case I am using:
Visual Studio Online
Git for the codebase being tested
TFVC for the ALM components (NUnit Adapter, Build Definition Templates)
Any help greatly appreciated.
If you are using TFS for source control: I don't have a template for this but you can follow below steps to achieve this.
In CI build set the Staging Location option to Copy buildoutput to following Source Control folder
Download the drop folder by mapping it in source settings option
in build definition
Under drop location folder in TFS, every CI build will create a new folder, you need to pass this folder name to the second build definition. Please check another post from Jason for passing parameters to second build
Execute the tests by invoking the commandline tools using Invoke
Process activity.
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
We had a working build for our solution, but when we added a new project, it stopped working. The build runs "successfully" and the log shows: Run MSBuild for Project -> Built [my solution] for target(s) publish (same for all projects), but it doesn't actually build anything.
The problem seems to be in the build configuration. My build process definition is set to build for my custom configuration (ForMSBuild | Any CPU), but something is wrong with the way TFB is interpreting that definition (I need that custom configuration because I copy some .dlls to a designated folder to include in a publish process in order to be available for a ClickOnce install).
At one point, only the new .dlls added to the solution weren't building (even though they were listed in the Configuration Manager with the Build check box checked). So I re-created my custom configuration, ensured that all my .dlls were checked to Build under (ForMSBuild | Any CPU), and now none build. I have opened the source on the build machine directly in Visual Studio (2012) and verified the settings for my custom configuration.
Edit the Build Definition, in the Process tab click the ellipsis next to Solutions To Build, go to the Configurations tab and ensure TFS Build is set to build the configuration you want it to:
It turns out that I actually had the main startup project not checked to build. Really stupid mistake, but I sure wish MSBuild hadn't spit out all those incorrect messages.