I'm trying to build aspnetcore artifact for a solution with multiple web projects inside. Default netcore publish task has checkbox "Publish Web Projects" that finds all projects containing web.config or wwwroot folders, but my WebApi projects doesn't need them at all.
You can disable this checkbox and provide paths to projects you want to publish. Each project must be provided in separate line.
So, if I edit this setting in task properties window, everything is ok, cause there is multiline editor that behaves as expected. But I want to move list of projects to variables, were all other configuration is stored. However variable's editor is singleline.
I've decided to put project names in variable with ";" delimiter and write powershell task that properly constructs paths for publish task:
$projects = '$(PublishProjects)'
$result = ( $projects.Split(#(';'), [System.StringSplitOptions]::RemoveEmptyEntries) | %{ ('**\' + $_.Trim() + '.csproj') } ) -join "`n"
Write-Host "##vso[task.setvariable variable=PublishProjectsPath]$result"
Unfortunately this results in setting PublishProjectsPath`s value to only first project, cause all project paths except first one are printed on their own line without ##vso... and so azure ignores them effectively.
Is there any way to set pipeline variable from script correctly?
I cannot use azure-pipelines.yml cause azure doesn't support gitlab :(
Set variable in script with string value that contains newline
For this issue , I am afraid this is currently not support in azure devops. Although dotnet publish task has the textboxes that support multiple line content , but currently does not support multi-line string as the value of a variable.
Until now, in our official feature suggestion for Azure Devops forum, there has been a such suggestion exist in it: https://developercommunity.visualstudio.com/idea/365667/multiple-lines-variable-in-build-and-release.html.
You could vote that suggestion ticket and share your comment there,the product team would provide the updates if they view it. Anyone interested in this can vote for it and track it.
Yous set the variable as job-scoped.
You need to set a multi job output variable with ##vso[task.setvariable variable=myOutputVar;isOutput=true]
Related
Before, I was displaying my product version with :
#string.Format("v{0}", ViewContext.Controller.GetType().Assembly.GetName().Version)
where the version was stored in the AssemblyInfo.cs like so :
[assembly: AssemblyVersion("2.2.1.0")]
and the result was "v2.2.1"
Now, I'm using CI/CD with Azure DevOps and I'd like to display the $(Release.ReleaseName) instead of the AssemblyVersion.
How can I do that? Is it possible?
tag\update the assemblyinfo.cs with the $(release.releasename) variable value during the build. there is a special task for that, as far as I recall, something like this: https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-Versioning-Task
or just create a script that would do that for you
Display Azure DevOps pipeline variables inside my code
AFAIK, there is no out of box to way to update the AssemblyVersion by the value the $(Release.ReleaseName).
As workaround, just like 4c74356b41 pointed out, you could use the Assembly Info task to update the AssemblyInfo.cs:
Note:
Since you need use this task in the release pipeline, you need change the default value in the Source folder to $(System.DefaultWorkingDirectory).
The Release name format need match the Semantic Versioning Specification (SemVer)
Hope this helps.
I'm currently working on a project were am at the stage of figuring out what the current implementation is doing. Have been putting in a lot of time (A LOT) searching connections between queues declared as global variables.
Is there a way to get a listing of were a specific global variable is being used, or do I actually need to go through all processes, as I´m doing atm?
Thank you :)
in Tibco Designer 5.8 you can find where global variable is used using "Tools->Find Global Variable usages" menu item.
Please note that all tibco processes source code are text files. So, you also can search inside project folder using file text search from any utility that allowing you to search inside text files. For windows I prefer Far Manager
In the "Far manager" you can navigate to project folder then ALt+F7 and search for
%%GLOBAL_VARIABLE_NAME%%
Please also note that even if you don't have tibco project source code you can get it from tibco BW server. example path
tibco\tra\domain\tibco\datafiles\YOUR_PROJECT_NAME
I have a folder in TFS which has SQL Scripts. At the moment I am manually adding a comment and updating a version number inside the comment every time i make a change and check it back it. This works however was hoping there might be a better way. Is there a way to automate this in TFS?
I have read the following article
Version control project files
do i have to go through such a process for simple .sql files? Are there any other simple ways.
There are a few ways you can do this:
Create an automated build in TFS and write a custom build step / PowerShell script to parse the appropriate SQL scripts, read the version, increment it, and store the new version by either checking in the updated file or a local store
Use a database project (part of SQL Server Data Tools) which will output a DACPAC. Inside the database project, you can set the version as specified here. This stores the version in the project file. If you update your TFS build number to be digits only, you can then update the project file to set that value to match the build using a custom build task. For example, if your build number was yyyy.m.d.R where R is the number of times that build was run today (TFS manages that - it's the revision variable). Or, you could set the the <DacVersion> tag to something like 2.1.0.0 and your build replaces the last digit with yyyymmddr.
I'd recommend using a database project. It's pretty easy to create a new database project off an existing database.
The first way mentioned by Jacob above can achieve that if you just want to incremental the version number of the script/folder, just create a CI build definition.
Actually you can just enable Label sources and set the Label format with predefined environment variables such as $(build.buildNumber), and set without publish any artifacts during build process.
Thus, it will automatically trigger the CI build when you check in files, and the source (SQL Script /folder) will be labeled with the incremental number.
Then you can find the specific versions with the label.
I am attempting to follow the tutorial for CI with Azure and a Team Foundation Build Server located here, but am running into an issue with the configuration of the build configuration template XAML file, in Step 5. In trying to configure a new ConvertWorkSpaceItem, and add it to the modified build template TFS provides (TfvsTemplate.12.xaml) so that a custom script can be run on a TFS build agent, I attempt to set the property Workspace = "Workspace", but am given a compiler error: 'Workspace' is a type and cannot be used as an expression.
I've done some troubleshooting already, and the errors that have happened to others -- not scoping the CreateWorkSpaceItem, or using the wrong version of TFS or Visual Studio -- do not seem to be issues. I placed the logic correctly inside the "Run on Agent" block, so the scope should be right, and Visual Studio and my TFS Server are both running 2013. My only thought is that the instructions are out of date, and there is some other step that needs to be taken that I am missing. Any ideas?
EDIT:
Here are the parameters for the first failed convert item. The second failed Convert item is similar. The Input and Result variables are parameters defined by me for the workflow as part of the instructions for the tutorial. The error displayed is: "Compiler error(s) encountered processing expression "Workspace". 'Workspace' is a type and cannot be used as an expression."
ok this has come up a couple of times now, for TFS 2013.
Built in variables used to be available for
SourcesDirectory, Binaries Directory and Workspace
these are no longer available in TFS 2013 you now have to use
Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables
to access these.
Getting the workspace is a little more complicated but if you assign some local variables you should be able to get the workspace object.
Declare local variables for sourcesDirectory (string) and buildDetail (IBuildDetail) and workSpace(Workspace) set their scope to the whole workflow
Create an GetEnvironmentVariable Activity and set its Result value to be sourcesDirectory and use Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.SourcesDirectory.
Repeat the same for buildDetail = WellKnownEnvironmentVariables.BuildDetail
Create an assign task for the workSpace object, set this one as
workSpace =
"[buildDetail.BuildServer.TeamProjectCollection.GetService().GetWorkspace(sourcesDirectory)]"
This should then give you a Workspace object to use.
note: syntax might be slightly out.
To compliment the removal of these variables MS have added a new Activity
GetLocalPath
which may be of use to you instead
We have a standard MSBuild project file that is used for our different deployment stages (pre-stage, stage, live, etc). Since each deployment stage is performed on a different server we introduced a server parameter called $SourceDatabaseServer and used this extensively in each of the targets inside the project file. Note: This database server name could be different from the server name on which the build is run.
To assist us with the customization of this parameter, we created a response file for each deployment stage and subsequently defined a value for this parameter in the response file, e.g. /p:SourceDatabaseServer=SRC_DB_NAME.
This worked fine, until we created a new deployment stage in which this value had to be the current computer name. So we thought by using the $(COMPUTERNAME) reserved property in the response file (/p:SourceDatabaseServer=$(COMPUTERNAME)), this would do the trick, but it seems like this value is interpreted literally by MSBuild, and we consequently get an error that server $(ComputerName) could not be found.
Interestingly, when the $(COMPUTERNAME) property is used directly in the proj file it works, but as stated above, we do not necessarily want to use the computer name in all the cases.
Is there a way to still use the $(COMPUTERNAME) property in the response file and get MSBuild to interpret this correctly?
What if you use %COMPUTERNAME%?
$(VAR) is the syntax for variable expansion when you're "inside" the MSBuild system, but coming from the outside, I believe you'd have to use the shell environment variable expansion syntax, %VAR%.