Hello Megha, In PowerShell, to create a JSON object key with a dollar sign in it, you need to use this syntax: "`$KeyName" So your object would look like this: $CreatePackageParam= @{releaseNumber=$ReleaseNumber; applicationName=$ApplicationName; "`$SiteName"=$SiteName; } Otherwise, PowerShell replaces both instances of $SiteName with the value in that variable.

I was trying the Otter instructions link provided by you. When we execute step 4 and try to execute command: “InedoAgentService.exe install” We get the error message saying that InedoAgentSVC already exists.. attempting to uninstall it. Which means it first removed the already existing and running InedoAgentSVC and then created the same again. But it could not install it since I checked in services.msc and there was no such service(i.e, the already existing service was gone). I tried to do it as below as well: Since the InedoAgentSVC(Inedo agent service) had already uninstalled, I tried to install it again but this time with different port(used 8080 instead of 46336) so that we can use port 46336 for second agent installation as per otter instructions. I changed the port for Inedo agent and the service was installed successfully but its name was still InedoAgentSVC, so I tried to change name of service to InedoAgentSVCMain in app_appsettings.config and installed the Inedo agent again. It did not get installed and threw error. The point that comes out is that both Otter and Inedo Agent generate same service with name InedoAgentSVC. If we install either of these and then try to install the other one, the first one gets uninstalled. So as a conclusion, we can have only one of these agents in a machine. Please let me know if I am missing something or some step as I am still not able to use multiple agents on same service box.

Ah ha! Thank you so much. I'll look in to this right now :)

Nevermind, I had to grant the Feeds_AddPackage privilege to the Anonymous User.

See: https://stackoverflow.com/questions/45063717

I created a ticket with Paket, and they did resolve the issue via an update to their code base. Testing with version 5.6.6 seems to have fixed the issue. https://github.com/fsprojects/Paket/issues/2466

In Properties, @(type: txt, sha1: <sha1 value>, md5: <md5 value>, name: Artifact7.txt) should be @(%(type: txt, sha1: <sha1 value>, md5: <md5 value>, name: Artifact7.txt)). If you're more used to JSON, those are equivalent to ["type: txt","sha1: <sha1 value>","md5: <md5 value>","name: Artifact7.txt"] and [{"type":"txt","sha1":"<sha1 value>","md5":"<md5 value>","name":"Artifact7.txt"}], respectively.

A connector will transparently mirror all of the feed, including pre-release versions. So, if you don't want to see pre-release, then disable your connectors to NuGet.org or use multiple feeds.

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.