I'm trying to get Silverlight unit tests integrated into a TFS build using a "Generic Test" on a test project to wrap Statlight
When I hard code the paths to everything it works fine but I'm tearing my hair out trying to work out how to pass project-relative paths to the generic test so that it works in the TFS build environment.
The closest I've come is to have the build process workflow set environment variables pointing to StatLight and the xap files containing the SL unit tests so that I can reference those in the command line arguments to statlight.
Feels hacky though - is there a better way of getting path information into generic tests based on the current solution/build configuration?
The MSDN documentation uses a couple of environment variables (%TestDeploymentDir% for one) that I can't find documented anywhere so I'm wondering if there are any more magic variables that I can use to infer paths from rather than having to set my own.
Here are some references on MSBuild properties:
Common MSBuild Project Properties
MSBuild Reserved Properties
Team Build 2008 Property Reference
Hope that helps.
Related
We use xUnit to run tests using Visual Studio Test task after Visual Studio Build task.
The solution is created on .NET Fw 4.6.2 and using xUnit version 2.4.1.
There is some kind of bug, that makes the Test run resulting in all tests GREEN, but resulting the task to Fail.
As a solution/workaround for the Visual Studio Test there can be specified a Path to custom test adapters property, targeting directly to Packages/xunit.runner.visualstudio.2.4.1/build/_common where the Framework testing dlls are placed.
So far so good - using that workaround gives a way to go.
As an improvement I wrote a PS script, that runs before the the Test task, setting a variable that I also use in the Visual Studio Test task - Path to custom test adapters.
The script is about to set my custom variable "XunitRunnerFolder" to programmatically selected path.
The problem is, that athough the variable is correctly set in PS script (and confirmed by reading in an extra script that i added in between the PS and Test task), the Test task still shows the initial value of the "XunitRunnerFolder" instead of reading the current/changed one.
Recap:
initial value of XunitRunnerFolder is "auto" (defined on Task Group input variables)
PS script changes the XunitRunnerFolder variable to Packages/xunit.runner.visualstudio.2.4.1/build/_common, using ##vso[task.setvariable variable=XunitRunnerFolder;]xxx/Packages/xunit.runner.visualstudio.2.4.1/build/_common
an extra script that reads the $Env:XunitRunnerFolder confirms its value is set to the (2.) value
Visual Studio Test task has set in its property Path to custom test adapters the variable $(XunitRunnerFolder), but in its log it writes-out that the value is the initial one ("auto")
Is there, please, a way to solve this, resulting in correct use of the newly set value in Test task?
Googling for 2 days so far didn't help, maybe because of not being native english speaker to ask correctly.
I've got a boatload of legacy project files that use a $(ProjectRoot) variable in include paths to refer to the root of the source tree. We define the variable in our visual studio environment so desktop builds can find their way to the tfs workspace in use.
I would like to define this variable in the Team Build environment via an MSBuild command line option in my tfs build definition, but I can't seem to find a way that works. I found an answer (List of msbuild properties TFS passes to a build script) with a list of variables and SolutionRoot looked promising.
When I put /p:ProjectRoot=$(SolutionRoot) in the MSBuild Arguments for my build definition, ProjectRoot ends up empty. I want it to expand to something like D:\Builds\18\TfsProject\BuildDef\src\
Is there a way to define my variable with the value of the root of the workspace sources in Team Build?
Note: I tried to figure this out in TFS2010 and finally gave up and modified the BuildProcessTemplate to define the variable using the SourcesDirectory variable that's available inside that context. I thought I'd take another run at it in the hopes of using the new template in TFS2013 without modification, but I'm still stumped.
UPDATE: Turns out the syntax I had in my MSBuild Arguments would work if the variable I'm dereferencing were actually being passed to msbuild. The list from the other post I reference seems to no longer be valid. Looking at the detailed Team Build logs, it looks like the only variables being passed in to msbuild in Team Build are OutDir, BuildId, BuildLabel, BuildTimestamp, BuildSourceVersion, and BuildDefinition. None of those gives me the info my current msbuild scripts need at build time so I'm stuck with either reworking all our project files or continuing with the BuildProcessTemplate modifications I've been using. Unless someone comes along with a better answer here.
You should be able to specify /p:ProjectRoot=$(TF_BUILD_SOURCESDIRECTORY) in the MSBuild Arguments of your build definition when using TFS2013.
See the Team Foundation Build environment variables documentation for more information.
Set the property using the other property. Use condition to only set it if its empty.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="xxxxxxxxxxxx">
<PropertyGroup>
<ProjectRoot Condition="$(ProjectRoot)==''"/>$(SolutionRoot)</ProjectRoot>
</PropertyGroup>
I am new to TFSBuild but I have been able to create a build definition for my solution. I have a couple questions that help would be great with.
I have created 3 definitions - I wonder if this is the correct way to this.
A definition that fires for every check in, builds the code and runs unit tests only
A definition runs every night, builds everything, runs all unit and integration tests
A definition that I specifically use for deployments - so I specify the environment via a parameter and it builds the code, runs unit and integration tests and ms deploys it to specified environment, again via parameter
When I branch my code etc, I will have to create 3 definitions for each and this could become unmanageable. Feedback on this please?
Is it true that each definition has its own set of build numbers? Can they be shared?
My application is an MVC4 app with VS2012 IDE.
Sadly TFS Build doesn't have very good support for branches, yes this typically means you duplicate your build definitions for each branch. There are a few custom build process template that I've seen in the past which try to get around this, but nothing built in.
You could replace #2 with a windows scheduler task to run #1 with custom parameters, not the nicest solution, but could be extended to queue every build definition at midnight with the integration test flag.
For #3 instead of using a build definition to deploy I use an external tool called TFS Deployer, this allows me to use any build to deploy simply by changing the build quality of the build. Reducing the number of builds that need to be setup by 1 for each branch.
Each build definition has its own build numbers, there's no built in way to share however I believe this is set by the build definition, so you may be able to hack around it somehow.
I feel I am missing something extremely basic; yet I have spent hours to no avail. I am trying to get a TFS build working and for the life of me I cannot figure out where this property gets set from.
I have picked up a TFS 2010 project from a team member that cannot help me at this time.
I have a simple TFS build that builds a solution.
In the tfproj file I have:
<SolutionToBuild Include="$(BuildProjectFolderPath)/MySolution.sln">
This seems to work, but for the life of me I cannot figure out how. I have not set the variable $(BuildProjectFolderPath) anywhere or anything resembling the correct path to MySolution.sln.
I have checked both the build definition, the build script, and the environment variables on the build box and I cannot figure out where the path corresponding to $(BuildProjectFolderPath) comes from.
Can someone help me unravel this black magic ?
Your build is actually performed by MSBuild. When MSuild starts, it gets some environment type of variables initialized that are project / solution specific. For example on the build server, the build agent will have injected its BuildProjectFolderPath value in MSBuild, that is used to resolve the macro that is in your tfsproj file.
No magic, just the environment that startup up to process your request supplies those values.
I have a vcproj file that includes a simple pre-build event along the lines of:
Helpertask.exe $(ProjectDir)
This works fine on developer PCs, but when the solution is built on our TFS 2008 build server under MSBuild, $(ProjectDir) is either blank or points to an unrelated folder on the server!
So far the best workaround I have managed is to hard code the developer and server paths instead:
if exist C:\DeveloperCode\MyProject HelperTask.exe C:\DeveloperCode\MyProject
if exist D:\BuildServerCode\MyProject HelperTask.exe D:\BuildServerCode\MyProject
This hack works in post-build steps but it doesn't work for a pre-build step (the Pre-build task now does nothing at all under MSBuild!)
Do you have any ideas for a fix or workaround? I have very little hair left!
$(MSBuildProjectDirectory) worked for me
I think your problem may be related to how items are initalized. An items include attribute is evaluated at the begining of a build. So if you depend on files that are created in the build process you must declare these as dynamic items. Dynamic items are those defined inside of a target, or by using the CreateItem task. I've detailed this on my blog MSBuild: Item and Property Evaluation.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
I think the problem is that build server's workspace probably isn't initialized properly.
I just kept getting problems with this - I tried many different approaches but they all failed in mysterious ways.
Once $(ProjectDir) started behaving properly again, the pre-build step stopped executing the command (I added echo commands above and below it - they were both executed, but the program in between them was not. No errors or output of any kind were generated to indicate why it failed).
I don't know if this is a dodgy server of if MSBuild is having a laugh.
I've given up now. I gave the build server a big kick and have changed tack: We now run this tool offline (manually) and check in the results for the build server to use. So much for an automated build :-( If only MSBuild would run solutions in the same way as Visual Studio does - it's maddening that it sets up the environment completely differently (different paths coming out of the solution variables, ouptus redirected into different folders so you can't find them where they're supposed to be, etc)
I branched an existing project and $(ProjectDir) kept the old directory in the newly branched code. But that's because I had some compiling errors. Once every project in the solution compiled without errors, $(ProjectDir) changed to the correct path.
Carlos A Merighe