Looking deeper, I see that the raft repositories are supposed to automatically download changes, but that functionality is broken. I've filed this as OT-183 and also fixed the related bugs OT-184 and OT-185.

Hello Giri,

This command should work:

InedoAgentSetup5.8.1.exe /S /TargetPath="D:\program files\inedoagent" /port=46336 /UserAccount=LocalSystem

I changed TargetDirectory to TargetPath, captialized /S, removed the install argument, and added quotes around the file path with spaces in it.

Hello Stijn,

This issue is caused by a hidden version of the package: https://www.nuget.org/packages/Swashbuckle.AspNetCore/1.0.0--rc1.

I've filed this as PG-1146 and will submit a fix for my co-workers to review.

Copying John's answer from StackOverflow:

Maps are specified as %(key: value), here is an example plan that should help:

set %map = %(Web.config: @("Web.Beta.config", "Web.Release.config"));

foreach $key in @MapKeys(%map)
{
    set @values = %map[$key];
    Log-Information `$key = $key;
    Log-Information `@values = $Join(", ", @values);
}

Sleep 3;

Hello Chris,

By default, Git rafts are stored in C:\ProgramData\Otter\Executions\GitRafts\[raftname] as bare repositories.

I don't think Otter git raft repositories will automatically download changes made outside of Otter - to pull the remote changes in this case, you could use the command git fetch origin master:master while inside the bare repository.

Could you capture a Fiddler or WireShark trace of the ProGet response? There should be an error message associated with the 400 (either There must be exactly one package., which would indicate a proxy issue or Package validation failed: followed by an error message, although from a quick glance over the source code, I don't see how that could happen for a NuGet package.)

Another possible cause is an IIS module, like WebDav, intercepting the request before it gets to ProGet.

Hello Tore,

I've fixed the 'syntax error at or near "IF"' error for future versions of ProGet on Linux, but that specific change script failing should not cause any problems. If you want to use the new AD user directory, you can add it on /administration/security/manage-directories.

I've filed the missing ChunkedUploads_* functions as PG-1142. They are missing from the Linux version of ProGet. I'll check to see if any other functions are missing.

Hello Bob,

You seem to have a typo in the feed URL. http://servername/nugget/feedname should be http://servername/nuget/feedname (with one g).

Hello Stefan,

Thanks for the bug report!

I've filed this as Windows#29 and submitted a pull request with a fix.

Hello Dmitry,

1. I don't think there's currently a way to delete Docker images through the API.
2. The blobs are deleted by the FeedCleanup scheduled task. You can run the task manually from /administration/scheduled-tasks, and it will run automatically once per day by default.

Hello beda,

It appears that npm 5.5.1 (the node:6.11.4 Docker image has npm 3.10.10 by default) strips anything after the last slash in the registry URL. To work around this, add a slash at the end, so --registry=https://proget/npm/my-feed-name becomes --registry=https://proget/npm/my-feed-name/

Hello Bruce,

I believe the Jenkins plugin does not want the leading slash on the path, so this should work: parent-folder,myFolder/**/*

Let me know if I misunderstood your question - I don't usually work with Jenkins.

My initial guess was wrong. The problem was that Ensure-Package assumed all directories would be explicitly listed in the archive. I've filed the issue as https://github.com/Inedo/inedox-inedocore/issues/45 and submitted a fix for my co-workers to review.

As a workaround until this fix is released, the upack command can create a upack archive in the format that it expects.

Hello Andrew,

I can't reproduce this locally. How are you creating the upack archive? Could you send me an example of a upack file that exhibits this behavior?

My guess is that the upack file has backslash path separators and that is confusing the InedoCore extension somehow.

Hello Kirill,

It appears that projects supporting .NET Standard create Portable PDB files instead of Microsoft PDB files. The current version of ProGet does not know how to read Portable PDB files, so it assumes they must not contain any symbols.

I've created a tracking issue for this: PG-1054

Hello Hugo,

That error message looks like SQL Server is not responding to connections. A StackOverflow user posted four possible solutions to this problem. Do any of the solutions on that page work for you?

Hello Curdin,

Is the connector associated with the feed (on the Manage Feed page)? Creating the connector makes it appear on the list of connectors that can be added to that type of feed, but it doesn't automatically add it as a feed connector.

Hello Charles,

upack pack expects a directory, not an individual file, so the command should be:

upack pack C:\location_of_upack_json_file C:\directory_containing_my_setup_exe --targetDirectory=C:\mytargetDir\build_artifacts

Hello Robert,

Thanks for the bug report! I've filed this as PG-1047. NPM feeds were showing the download count as the total for all NPM packages, not just the ones associated with that feed.

Hello Jon,

Config files are not accessible via imported deployables, but artifacts are, so you can create an artifact in the source application and then do something like this:

Deploy-Artifact ArtifactName
(
    To: $WorkingDirectory,
    Application: $ReferencedApplicationName(DeployableName),
    Release: $ReferencedReleaseNumber(DeployableName),
    Package: $ReferencedPackageNumber(DeployableName),
    Deployable: DeployableName
);