I've created a build definition using TF Build. It is the nightly build for our project. It should run the defined Unit Tests and it should package the Azure Cloud Service projects.
This build has been running for some time without the packaging step. This resulted in a successful build that also ran the Unit Tests.
Based on the following guide I have added the packaging of the Cloud Services: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-continuous-delivery/. Basically it comes down to setting the target to Publish for msbuild (/target:Publish) in the Build definition.
The problem is that when a solution is build with a Publish target the Unit test projects are not build. MSBuild will return with the following message: Skipping unpublishable project. I have traced this back to the common MSBuild target file. A project will only build when Publishing is the project results in an exe, as can be seen here: http://referencesource.microsoft.com/#MSBuildFiles/C/ProgramFiles(x86)/MSBuild/14.0/bin_/amd64/Microsoft.Common.CurrentVersion.targets,217
What I have tried:
Forcing building of Unit Test projects in Publish builds.
I have added the following msbuild to the Unit Test csproj-files in order to override the default target on Publish:
<PropertyGroup>
<PublishDependsOn>
Build;
</PublishDependsOn>
</PropertyGroup>
Setting the output type of the Unit Test project to Console Application
In both cased MSBuild will give the The specified project reference metadata for the reference "..\..csproj" is missing or has an invalid value: Project for all projects that are referenced by the unit test project.
I feel like I'm not on the right track. Is there a way I can both build the Unit Test projects and build and publish the Cloud Service projects?
Okee, it was much simpler then I though.
The /target-arguments of MSBuild can take multiple targets that are built in turn. I change my build definition to have /target:Build;Publish as msbuild params. This fixed the issue.
I got an error (no entry point specified for cloud service) doing /t:Build;Publish with my service. So I did 2 separate actions, one with Build and one with Publish and that worked.
Related
I have an established CI pipeline comprising (prior to deployment):
TFS build
JFrog Artifactory for build artifact management
SoapUI and SpecFlow (BDD & itaretive, parameterised) for web service functional test automation
I have no access to our build agent servers and no permission to install anything thereon. Instead, I've added the SoapUI binaries as links to my functional test project; the binaries are pulled from source control in the Get Sources step of every build.
This works okay but it greatly increases the footprint of my test project (and any other test project for which SoapUI would be required), and by extension, the execution time of the build: functional testing will only execute on a small fraction of the builds executed (only if application codebase has changed or sufficient time interval since last full build and test has elapsed).
For these reasons, I opted to remove the SoapUI binaries folder from my test project and instead deploy a SoapUI binaries zip archive to an Artifactory repository. With the addition of a PowerShell script step in my build definition, I can pull the SoapUI binaries as needed and extract to the desired location on the build server. Foolishly, I thought this might be straightforward...
I did manage to push the zipped SoapUI binaries folder to the Artifactory repo, and, in my Development build definition, I did manage to correctly script my PowerShell step to pull the zip archive and extract its content successfully to he same folder in the build binaries directory on the build agent server as it had been located originally.
However, when I execute my build, in the step where the SoapUI tests are executed, on the first test iteration, I see the following error returned to build console:
System.ComponentModel.Win32Exception: The directory name is invalid
I added a PowerShell scripted filtered folder content step before the test execution step in both my Development (new) and my Production (original) builds for comparison. Both show the required 'testrunner.bat' to be present, in the same folder on the build agent server.
The test project itself has been unchanged (except for the removal of the SoapUI binaries folder).
To summarise:
I'm trying to execute SoapUI tests in two builds; in each build, the same test project is used and the SoapUI binaries are in the same location when the test execution kicks off.
One build executes successfully without issue.
One build fails at test execution step, returning error "System.ComponentModel.Win32Exception: The directory name is invalid".
I'm very puzzled by this; insights and SoapUI wisdom most welcome.
Thanks for looking.
Turned out, there was a discrepancy in the directory paths on the testrunner.bat between the builds; a '_' where a '-' should have been
I'm possibly in over my head here, but I've been asked to set up a scheduled Team Foundation Build for our team's branch and then after the build completes for our automated tests to be executed using NUnit.
I've had a look at a few online tutorials on setting up the build definition in TFS, but I can't seem to figure out how to call NUnit after the build is successful. I was expecting to see or find some kind of "run this command line on success" option somewhere; the best I could find is "Pre/Post-test script path", but that's related to tests like **\*test*.dll;**\*test*.appx and I'm not sure what that is.
Just knowing what to Google for would be a help, as I am at a loss now.
If you use XAML build:
You can either install the NUnit Test Adapter NuGet package in the unit test project. Or you can check the assemblies into the Build Controller's Custom Assemblies Path.
Useful article:
https://blogs.msdn.microsoft.com/visualstudioalm/2013/06/11/part-3-unit-testing-with-traits-and-code-coverage-in-visual-studio-2012-using-the-tfs-build-and-the-new-nuget-adapter-approach/
https://www.codit.eu/blog/2015/03/18/continuous-integration-with-javascript-nunit-on-tfsbuild-part-3-of-3-/
If you use new task based build:
You can add the NUnit Test Adapter NuGet package to your solution, and specify the path of NUnit Test Adapter NuGet package in the Path to Custom Test Adapters field in VSTest task. Check the screenshot below:
Useful article:
http://bartwullems.blogspot.sg/2015/10/team-foundation-server-2015enable-nunit.html
I have a solution containing a web application and multiple database projects. While using the old XAML definition, I can compile and generate the database deployment files in TFS. With the new definition introduced in TFS 2015, I can only generate the web application deployment files.
Here are parts of the log -
2016-10-28T22:14:48.6892904Z Build started 10/28/2016 4:14:48 PM.
2016-10-28T22:14:48.8883071Z 1>Project "E:\TFS\agent\_work\1\s\Test.Client.sln" on node 1 (default targets).
2016-10-28T22:14:48.8893071Z 1>ValidateSolutionConfiguration:
2016-10-28T22:14:48.8903071Z Building solution configuration "release|any cpu".
2016-10-28T22:14:49.0633142Z ##[warning]E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj(0,0): Warning MSB4046: Error reading project file "..\Databases\Test\Test.DB.Test.sqlproj": Could not find a part of the path 'E:\TFS\agent\_work\1\Databases\Test\Test.DB.Test.sqlproj'.
2016-10-28T22:14:49.0643150Z 1>Project "E:\TFS\agent\_work\1\s\Test.Client.sln" (1) is building "E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj" (2) on node 1 (default targets).
2016-10-28T22:14:49.0693159Z 2>E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj : warning MSB4046: Error reading project file "..\Databases\Test\Test.DB.Test.sqlproj": Could not find a part of the path 'E:\TFS\agent\_work\1\Databases\Test\Test.DB.Test.sqlproj'.
2016-10-28T22:14:49.0823182Z 2>Done Building Project "E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj" (default targets).
I could not find much information on the new build definition. Anyone can help?
Thanks
We figured out what is wrong with this. Our database projects are in another folder. We need to map the server path with the local path in the Build's repository. After added this, the database project can be built.
First double check the difference of your two definitions XAML and vNext.
And check the file path E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj on the build agent, if there are the corresponding file.
And try to build your database project directly instead of building the whole solution to see if there are some useful info for troubleshooting.
Update
Tips:
You can also build MSBuild project (.*proj) files.
If you are building a customized MSBuild project file, we recommend you use the MSBuild step instead of the Visual Studio Build step.
Source Link: Visual Studio Build
I'm using psake, msbuild and nUnit to automate my build and testing of an MVC web app, which will be carried out (kindly), by Jenkins, once I have it working.
My build steps work fine, creating two DLL's in the build\bin dir:
MyWebApplication.dll
MyWebApplication.Tests.dll
I'm using nunit-console.exe to run the automated tests as part of the psake build script, pointing it at the newly built MyWebApplication.Test.dll. However, the tests fail due to is saying it could not load file or assembly MyWebApplication.dll, despite it being in the same directory as the test dll file.
How do I go about executing tests using nunit in this scenario?
It's most likely looking for the application .dll in the workspace root, which is the current directory by default in Jenkins. Try changing the current directory to %WORKSPACE%\build\bin before launching the test.
I found the answer to my own question.
I had to compile a debug version of my projects as part of the build script, then run the Nunit console exe against my csproj file for the test project. With this, it executes the tests properly.
I’m working with a VS2010 solution that has multiple projects (normal assemblies, an ASP.NET MVC project, a Windows Azure project, and a SQL project). I am trying to figure out how to set up a TFS build definition to deploy both the Windows Azure project and the SQL project.
I know how to do a Windows Azure deployment, and have a custom build task in the Windows Azure project file (.ccproj) that does the deployment. I can easily create a build definition that runs against the .ccproj file, passing in some MSBuild command line arguments as parameters, and works as expected.
I can create another build definition that runs against the SQL project (.sqlproj) file, passing to MSBuild the build targets and parameters needed to build and publish the SQL project. That works as expected.
As two distinct build definitions what I have works. Easy enough.
What I have yet to figure out is how to combine these two build definitions into one. Is that even possible (without a lot of work)? Ideally I’d be able to kick off a new build that will build the projects and deploy them both (just as they do as separate build definitions) as part of a single unit of work.
I have tried using the solution file as the item to build, and specifying the build targets as /t:<project>:<target>;<project>:<target>. But, apparently that syntax only works for targets in the base set and not any custom targets or those imported by other .targets files (or so that’s my understanding).
What is the best (simplest) way to accomplish what I’m looking to do?
Sure you can totally do this! Basically, you need to have a target in each project with the same name. Then you change the DependsOn list for each to include the project specific list of targets. Example:
Project 1:
<Target Name="MyBuild" DependsOnTargets="AzureTarget1,AzureTarget2" />
Project 2:
<Target Name="MyBuild" DependsOnTargets="SQLTarget1,SQLTarget2" />
Then you can tell the build definition to build the MyBuild target on each and it should invoke the appropriate DependsOn targets.
This is a very simple example of how to do this, but you can make this much more robust if you also use MSBuild Traversal projects and an MSBuild traversal task much like the method described in the following article under the "Building Large Source Trees" section:
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx#id0100082