Hello Mark, This is not currently possible due to a bug, but I've filed PG-1059 and submitted some code that will fix this for review.

Hello Megha, That URL looks correct. Are you doing a POST or PUT request, or a GET request? If you're visiting the page in your browser, that's a GET request and it won't work. Either POST or PUT will work, though. You can use a web hook to automate this through TFS.

Hi Megha, Per the Release & Package Deployment API, you must POST or PUT to this url. On the Invoke-RestMethod CmdLet, you specify this using the -Method argument. $response = Invoke-RestMethod 'http://<<BuildMasterServer>>/api/releases/packages/create?releaseNumber=1.0.2&applicationName=DeployWWMapping&key=5WRTeJcctiY32u2bEqTb4Q==' -Method Post

This is currently slated for ProGet 4.8-beta, which we expect to release in the next two weeks.

ProGet already supports SemVer2 for Universal Packages. Unfortunately, NuGet does not yet support this. Remember they also have a "quasi-support" for this quirky 4-party version number as well, which so many packages utilize. Please refer to the NuGet Team's documentation on SemVer. 3.0.0 and up support SemVer 2.0.0 with a limited capacity. Local folders and shares are unable to parse versions with multiple release labels or metadata due to the use of NuGet.Core.dll from the older 2.11.0 client. Project.json restore supports SemVer 2.0.0 and is able to read local folders correctly since it does not depend on NuGet.Core.dll. In some scenarios metadata is written to the disk folder path which causes. Multiple release labels are supported. Starting in NuGet Client 3.5.0-rc1 has added SemVer 2.0.0 for supported for local folders and UNC shares. It's a much more complicated issue than it appears at first, and with the velocity of the NuGet team's releases has slowed, and it's likely NuGet will not fully support this in a while (document was from Oct 2016). We may add some support for this down the line, but it would require a major change to the way we do package indexing, and thus could impact a lot of our enterprise customers. You ought to consider changing your requirement if you're going to use NuGet packages, given the limited supported from the NuGet team for it.

Excellent. Thanks for letting me know, Alana.

To solve this, make sure to have the following nuget.config file in the same dir as the .sln file. <?xml version="1.0" encoding="utf-8"?> <configuration>   <packageSources>   <clear />   <add key="ProGet" value="https://your-proget-server/nuget/feed-name/" protocolVersion="2"/>   </packageSources> </configuration>

Those features shouldn't be available in free versions; if so, that's an oversight/bug.

There is a setting on your pipeline; if you edit the pipeline settings, you'll be able to uncheck that option. Note that, we'll be handling this in a different manner in a future version (post-deployment OtterScript plans) with the Create Release operation; but of course, you could do this today at the end of your production plan, or as a new target/stage in your pipeline.

We'll be handling this in a different manner in a future version (post-deployment OtterScript plans) with the Create Release operation; but of course, you could do this today at the end of your production plan, or as a new target/stage in your pipeline.

A build is a separate object in Artifactory. You can create one with the Upload-Build operation. Artifactory::Upload-Build ( Credentials: ArtifactoryCredentialsName, Name: builds.json, Version: 1.2.4, Number: 1, Modules: @(%(id: some-module-name, artifacts: @(%ArtifactDefinition)) ); You can get %ArtifactDefinition from Get-Artifact-Metadata or Upload-Artifact.

Sorry but I run the indexer and it fails... Creating C:\ProgramData\ProGet\Packages.maven2\I22 if necessary. Opening C:\ProgramData\ProGet\Packages.maven2\I22\next-index.gz to write feed index. Writing local artifact info to feed index. Writing connector http://xcdeveljees2:8081/artifactory/novagalicia-repository artifacts to feed index. Unabled to open Lucene index for connector 31 Index generation complete.

ProGet already supports SemVer2 for Universal Packages. Unfortunately, NuGet does not yet support this. Remember they also have a "quasi-support" for this quirky 4-party version number as well, which so many packages utilize. Please refer to the NuGet Team's documentation on SemVer. 3.0.0 and up support SemVer 2.0.0 with a limited capacity. Local folders and shares are unable to parse versions with multiple release labels or metadata due to the use of NuGet.Core.dll from the older 2.11.0 client. Project.json restore supports SemVer 2.0.0 and is able to read local folders correctly since it does not depend on NuGet.Core.dll. In some scenarios metadata is written to the disk folder path which causes. Multiple release labels are supported. Starting in NuGet Client 3.5.0-rc1 has added SemVer 2.0.0 for supported for local folders and UNC shares. It's a much more complicated issue than it appears at first, and with the velocity of the NuGet team's releases has slowed, and it's likely NuGet will not fully support this in a while (document was from Oct 2016). We may add some support for this down the line, but it would require a major change to the way we do package indexing, and thus could impact a lot of our enterprise customers. You ought to consider changing your requirement if you're going to use NuGet packages, given the limited supported from the NuGet team for it.

Hi Megha, Ensure application dont have selection of appPool right now, may be you can try create a powershell like below might solve your problem for time being. param( [parameter(mandatory=$true)] $iisAppPoolName, [parameter(mandatory=$true)] $iisAppName ) Import-Module WebAdministration #gets the iis application name $iisApp = get-item 'IIS:\Sites\Default Web Site' if((Test-Path ("IIS:\AppPools" + $iisAppPoolName)) -and (Test-Path ("IIS:\Sites\Default Web Site" + $iisAppName))) { #set the app pool to the application #Set-ItemProperty IIS:\Sites'Default Web Site'$iisAppName -Name applicationpool -Value $iisAppPoolName Set-ItemProperty -path IIS:\Sites'Default Web Site'$iisAppName -name applicationPool -value $iisAppPoolName -Force Write-Host $iisAppPoolName“ configured to web site: “$iisAppName } else { Write-Host "The App Pool/site does not exists" -ForegroundColor Yellow Write-Error "Failed to add application to the app pool" exit } Thanks, Srinivas

Thanks, that fixed it.

Thanks all, it seems the problem with the extension. One thing I've observed is the extension is not working for 5.6.5. As we end up in upgrading the buildmaster to 5.6.11 then it started working.

Thanks Alana, [EDO-2856] has been raised. Thanks, Clint

That type of difference is understood. Someone here asked me about it so I just wanted to clarify what should be expected as it was not clearly defined in the documentation as to what differences it would be reporting. Thanks.

There wasn't another role doing remediation. This particular instance was just supposed to be a simple check for a file just for display. I have orchestration plans that run and actually build servers. Other points of interest however: Why does running the configuration job for role Rebuild then return result for all servers, but the recurring job does not? I saw the same results with a more complete role configuration using the OtterScript "Ensure File" that would create the file as needed with remediation.

If you have Windows Integrated Authentication enabled, then it will not be possible to do this. The 401 is occurring before the request even makes it to ProGet, which is how WIA is designed. You can also set up a second site in IIS without WIA enabled. That would lalow the request to get to ProGet, and if you have an "Anonymous" pseudo-user configured with permissions, then the lack of a credential will be ignored.