Are you pushing the same version number? If so, this is (unfortunately) a by-design feature of NuGet. The solution is to use pre-release versioning, or instruct the NuGet task of the build server to always request with the -NoCache flag.

There are 2 ways to handle this: set a higher-scoped variable to the default value, e.g. set $BuildTestsFlag to false at the application group or system level; this removes the need to check at all, or: use if !$IsVariableDefined(BuildTestsFlag) function to determine if it doesn't exist

Please disable the "Overwrite Package" permission in Admin > Tasks. Then, you will get "Package Already Exists" error

Thanks Josh for the response. I ended up using custom Power shell task. <# .SYNOPSIS Script to set assembly version for dot net assmeblies. .PARAMETERS .sourceFolder folder where the source is located. .newVersion .assemblyInfoFileNamePattern name of assembly info file #> param( [string]$sourceFolder, [string]$newVersion, [string]$assemblyInfoFileNamePattern ) if( [string]::IsNullOrEmpty($assemblyInfoFileNamePattern)){ $assemblyInfoFileNamePattern = "*AssemblyInfo*.*" } if( [string]::IsNullOrEmpty($newVersion)){ $newVersion = "1.0.0.0" } $versionSplit = $newVersion.Split(".") if($versionSplit.Length -eq 2){ $newVersion = $newVersion + ".*.*" } if($versionSplit.Length -eq 3){ $newVersion = $newVersion + ".*" } ################################################################################## # Output execution parameters. "Executing with the following parameters:" " source Folder: $sourceFolder" " new Version: $newVersion" " assembly Info File Name Pattern: $assemblyInfoFileNamePattern" ################################################################################## $pattern = '\[assembly: AssemblyVersion\("(.*)"\)\]' Get-ChildItem -Path $sourceFolder -Filter $assemblyInfoFileNamePattern -Recurse | ForEach{ "found file " + $_.FullName $fileFound = $_ (Get-Content $fileFound.FullName) | ForEach-Object{ if($_ -match $pattern){ # We have found the matching line # Edit the version number and put back. #$fileVersion = [version]$matches[1] #$targetVersion = "{0}.{1}.{2}.{3}" -f $fileVersion.Major, $fileVersion.Minor, $fileVersion.Build, ($fileVersion.Revision + 1) '[assembly: AssemblyVersion("{0}")]' -f $newVersion } else { # Output line as is $_ } } | Set-Content $fileFound.FullName -Force }

Well, I've been meaning to upgrade anyway. If that's something that's available in v6 means that I'll be doing that sooner rather than later.

Have you considered to use an external connector ? See the details here : https://inedo.com/support/documentation/proget/core-concepts/feeds/connectors If impossible you would have to download and compile and them to your feed.

George, thank you so much for pointing me in the right direction, that's exactly what I was looking for!

In this case, you can use the execute command line operation; please see Executing a Command Line Utility During Deployment in BuildMaster

Thank you for the report; it looks like the extension was migrated correctly but never officially released to our extension feed... I'll have someone release it ASAP

There must be some confusion here (and that is understandable since it's a legacy feature that I am in the process of reworking to support the "provider-less" model). An SCM Trigger cannot create a release, only a release package. If there are no releases (or the specific selected release doesn't exist) nothing will happen. Can you share the example pipeline, and the plan associated with its first stage's target?

A 401 means that npm requires authentication which was not supplied, visit Feeds > Connectors > [edit/create npm connector] and enter a username/password to connect to the external registry.

You can do this with default values. template Check_Version<$App, $Role=default> { } And then test if it's the default value to see if it wasn't passed in

Hi, I got the InedoCore extension from an other installation on an other machine. And I copied it into the extension folder, restart the service and it works now. Thanks for the answers. KR.

We are only aware of that message occurring in the two cases I mentioned, and haven't had reports of the contrary. From here, please use a tool like Fiddler or Wireshark to identify the exact request/response patterns that are happening. You can see the authentication headers sent, and it's possible there's a typo or something in a name or password.

Thanks it works. I can then continue my testing and integration. With kind regards.

Thanks for the usecase - that's interesting and a good point in favor of doing this. Unfortunately after a brief review I've found that it's a little more technically complex than we first anticipated. I still think that we will do it, but it isn't something we can just drop in the next release.

Alana, thanks. I didn't realize those variables did not appear in that list, thought that was all variables. In any event, knowing they are app settings variables helps. Thanks!

BuildMaster does all of these things, it's almost as if you've rewritten the feature page for it in bullet form :) Most downloaders start by getting a super simple app deployed and then expand on it. Here is the "starter" tutorial we recommend (it should hopefully make sense even if you don't use .NET or IIS): https://inedo.com/support/tutorials/buildmaster/deployments/deploying-a-simple-web-app-to-iis

Please refer to the Upgrading Extensions section of the v6.0 upgrade notes.

TFS labels can be a bit complicated, and the way that Visual Studio (GUI) vs tools (tf.exe, BuildMaster, etc) interact with them are different. What may be happening in the GUI is that multiple labels are being created with the same name, and the the GUI is "searching" for files by label name (as opposed to "getting" those files). If you were to do a tf.exe get (https://docs.microsoft.com/en-us/vsts/tfvc/get-command?view=vsts), for example, you should see the same behavior. Instead, makes sure to first create a label at the $/ root level (e.g. tf label myLabel $/ ), and then you can sub-label items.