I'm setting up a build in TFS. In the MSBuild step, it allows wildcards for the project name (like **/*.csproj). I'm assuming that it accepts fnmatch syntax like other fields in TFS.
I want to build all projects that don't contain the number "6" in the project name (because they are using .NET 6)
I would expect **/*!(6)*.csproj to work, but no dice.
I've tried a few different combinations but can't seem to get it to work.
A few of the things I've tried:
**/*!(6)*.csproj
**/*([a-zA-Z0-57-9.]).csproj
**/[a-zA-Z0-57-9.]*.csproj
As of the time of writing this answer the current version of the Azure Pipelines MSBuild task is v1 and fnmatch syntax is not supported by the task.
The Azure Pipelines DotNetCoreCLI task does support fnmatch syntax and MSBuild can be run via the dotnet command.
Something like the following should work (but note that I have not tested this example):
- task: DotNetCoreCLI#2
displayName: 'dotnet msbuild'
inputs:
command: 'custom'
custom: 'msbuild'
projects: '**/*!(6)*.csproj'
Related
I currently use TFS build for my Azure cloud service project.
as a output of that .cspkg and .cscfg file is created after the successful build.
is there any way to add the $(Build.BuildNumber) to my .cspkg file
say for eg: currently my output file looks like
SchoolWebPortalAzure.cspkg
is it possible to rename like SchoolWebPortal_1.0.0.1.cspkg in the tfs build definition.
thanks,
kind regards,
Snegha
You could use the Run Command Line task or do it in a PowerShell script in build.
1). Add the Inline Powershell task from the marketplace before the copy task in build definition.
2).Enter the following Powershell in the text area
Param (
[string]$pathToFileToRename
)
Rename-Item $pathToFileToRename Helloworld_$(Build.BuildNumber).exe
3). Enter any required arguments in the arguments text box (you could
use environment variables) e.g. -pathToFileToRename $(Build.SourcesDirectory)\somepath\CurrentName.exe
Then you will get the renamed file in the drop folder.
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.
We use TFS 2010.
There are a couple of projects with deployment steps which must know whether they are running on a dev machine or on the TFS build agent.
Right now they check whether the build is from within Visual Studio assuming that only devs compile from VS. Alas, it means I cannot compile from the command line!
So, my question is how an msbuild script can determine if it is being run by the TFS build agent?
You have a few options:
'$(BuildingInsideVisualStudio)' != ''
'$(TeamBuildConstants)' != '' (supported in team Build 2008)
'$(IsDesktopBuild)' == 'false'
'$(tf_build)' != '' (supported in recent versions of Azure Pipelines)
You can check either one to detect the context the task has been executed in. If both don't evaluate then MsBuild has been called from the commandline or some other process.
I have TFS2012 and use this:
<IsTfsServerBuild Condition=" '$(IsTfsServerBuild)' == '' ">false</IsTfsServerBuild>
<IsTfsServerBuild Condition=" '$(BuildingInsideVisualStudio)' != 'true' AND '$(BuildUri)' != '' ">true</IsTfsServerBuild>
When calling MSBuild from the command line, you can pass/overwrite properties like this:
# Simulate Visual Studio build
. msbuild.exe Project.csproj /p:BuildingInsideVisualStudio=true [...]
# Custom property
. msbuild.exe Project.csproj /p:MyCustomProperty=true [...]
Is use these to check them in my post/afterbuild events.
I thought to provide my own answer updated to 2020.
The way we do it is by checking an environment variable, because TFS (now Azure DevOps) exposes build variables through the environment. When tested in msbuild code they look the same build variables passed on the msbuild command line, but we also employ powershell scripts, which rely only on the environment.
Also, I would sometimes like to distinguish between the Build and the Release pipeline, because in the classic Release pipeline (as opposed to yaml, which we do not have on prem) some things do not work the same (like vsts logging commands)
So, here is what we are using:
BUILD_BUILDNUMBER - exists in both build and release, because all of our releases include a build artifact
RELEASE_ENVIRONMENTNAME - exists only in the classic release pipeline
TF_BUILD - not sure if exists in release, definitely in build
I would not bother with BuildingInsideVisualStudio, because it is false when build with msbuild on the command line, yet it is not a build on the CI server.
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
I'm trying to deploy a web application using MSDeploy, on Team Build in TFS. There are several questions that address the properties that have to be passed in MSBuild in order to call MSDeploy, but I haven't found sufficient documentation for what properties are available. Does someone have a list of available properties?
Here are some questions that I've found, but I haven't been able to find a definitive list of the properties:
Breaking MsBuild package & deploy into separate MsBuild and MsDeploy commands
How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?
Here's a list I've compiled for my own reference, along with some of the legal values that can be used. Note that these are passed into MSBuild using the /p:<PropertyName>=<Value> syntax.
DeployOnBuild
True
False
DeployTarget
MsDeployPublish
Package
Configuration
Name of a valid solution configuration
CreatePackageOnPublish
True
False
DeployIisAppPath
<Web Site Name>/<Folder>
MsDeployServiceUrl
Location of MSDeploy installation you want to use
MsDeployPublishMethod
WMSVC (Web Management Service)
RemoteAgent
AllowUntrustedCertificate (used with self-signed SSL certificates)
True
False
UserName
Password
SkipExtraFilesOnServer (leave existing non-conflicting files alone)
True
False
Unfortunately documentation for this is almost non-existent at this point. If the various blog posts and forum posts aren't comprehensive enough, you can always look at the .target file that MSDeploy uses which shows how the various properties are used if you are willing to spend the time to wade through copious amounts of XML.
On my machine it's located here:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I don't know if this is what you are looking for but you can invoke msdeploy with the /? argument and it will display a list of valid arguments
How about this one /p:IncrementalBuild=True
Some more here https://msdn.microsoft.com/en-us/ff622991.aspx (for sharepoint)
To create a package in build:
/p:IsPackaging=true
To set the publish directory in the same drop output location:
/p:PublishDir=
When your solution contains multiple app projects, set the following parameter to produce app specific publish directories.
/p:AppSpecificPublishOutputs=true
WebDeploy configuration of a SelfContained .NET Core2 application.
Note 2 mandatory properties:
Missing RuntimeIdentifier throws:
error NETSDK1031: It is not supported to build or publish a
self-contained application without specifying a RuntimeIdentifier.
Please either specify a RuntimeIdentifier or set SelfContained to
false.
Missing DeployIisAppPath can throw:
error : Property 'DeployIisAppPath' must be non-empty.
In case you are passing the parameters to dotnet publish, avoid circular dependency with /p:DeployOnBuild=false
error MSB4006: There is a circular dependency in the target dependency
graph involving target "Publish".
Complete WebDeploy configuration for command line:
/P:WebPublishMethod=MSDeploy
/P:DeployOnBuild=True
/P:DeployTarget=MsDeployPublish
/P:TargetFramework=netcoreapp2.0
/P:SelfContained=true
/P:MsDeployServiceUrl=https://my_subdomain.jobit.io:8172/MsDeploy.axd?site=subdomain_path
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=OTB
/P:Password=Expert
/P:RuntimeIdentifier=win-x86
/P:DeployIisAppPath=subdomain_path