Hello Otto,

I've filed what I think is the bug as PG-1250.

Could you check if the packages that exhibit this problem have something like "license": "" or "licenses": [{"type": ""}] in their package.json file?

Hello Thomas,

ProGet's NuGet feed error messages for duplicate package versions look like this:

The package ExamplePackage.1.0.0 already exists and the user ExampleUser does not have the Feeds_OverwritePackage privilege. If you are trying to push a symbol package, note that ProGet only requires the symbol package to be pushed; there is no need for a package with no symbols. See http://inedo.com/support/kb/1036/using-progets-symbol-server for more information.

However, the current version of the command line NuGet client does not display error message bodies in any easy-to-access place. I've filed PG-1249 to replace the status code descriptions with some custom phrases. For example, 403 Forbidden will now be 403 Package Already Exists for this type of error.

Hello Josh,

I agree that this would be very useful to have.

I've filed IEE-8, which will allow the use of variables in block descriptions if the script contains ##AH:EvaluateStatementDescriptions at the top.

Hello Rickard,

The official installation guide creates a volume using docker run -v.

You can also extend the ProGet image like this:

FROM inedo/proget:5.0.9

RUN mkdir -p /var/proget/extensions
RUN curl -sSL -o /var/proget/extensions/InedoCore.upack \
        https://inedo.com/den/feed/download/inedox/InedoCore/1.0.3 && \
    echo "14f4df63af7b8991390cf77d1f68be55569609f4 *InedoCore.upack" | sha1sum -c

(The checksum part is optional, but it will cause the image to fail to build if the file isn't what was expected, which gives you a better guarantee that the same image will be built every time.)

Hello Jarrod,

This was fixed in PG-1209, which is part of ProGet 5.0.9.

Hello Thomas,

I've filed PG-1223 to fix the UI sending you to the wrong URL and promotion trying to load the package from the wrong filename (the name contains the build metadata, but the promotion code doesn't add it on the source feed).

Hello Andre,

The version number you posted is indeed a valid SemVer2 version number.

If you go to the Manage Feed page for the NuGet feed, is there an orange button near the top of the page that says Migrate? If that button is present, the feed is not marked as supporting SemVer2.

If you run this:

EXECUTE [Rafts_GetRaftItems]
		@Raft_Id = 1,
		@RaftItemType_Code = 4,
		@RaftItem_Name = NULL

the last item listed is probably the one that's causing this problem (because the overview page stopped working when it was added).

OT-210 will fix this, but deleting the specific script that's causing the problem might be difficult through the exposed API if the name contains control characters. Instead, accessing the table directly might be easier in this case:

DELETE FROM [RaftItems]
 WHERE [RaftItem_Id] = 12345
-- obviously, 12345 would be replaced with the ID obtained in the result of the previous query.

Hello Jonathan,

If the name of the script includes ", <, >, or |, that might be causing this problem.

I'll fix the code to handle this, but in the meantime, you can delete the raft item through the database:

EXECUTE [Rafts_DeleteRaftItem]
    /* default raft */ 1,
    /* script */ 4,
    /* the filename that includes invalid characters */ 'badname.ps1',
    /* hard delete (don't just deactivate) */ 'Y'

Hello Emil,

If source or symbol stripping is enabled on the NuGet feed, the package you download will be dynamically created. If you add a query parameter ?includeSymbols=Y in the package request, ProGet will give you the original nupkg file, which should have the SHA512 sum from that field.

See my response here.

In summary, it's not a valid SemVer2 version number because it contains 4 parts before the hyphen, and it's not a valid legacy version number because it contains a . after the hyphen.

This was resolved through a ticket, but the answer I posted there will probably be useful to the general public:

LegacyNuGetVersion gets called if SemVer2NuGetVersion is unable to parse the version number.

In this case, the version number 1.0.27.14-commit.33ed7ba is neither a valid semantic version (SemVer wants 3 parts before the hyphen, but there are 4) nor a valid legacy version (I believe this is because of the . after commit).

For SemVer, something like 1.0.27-build.14.commit.33ed7ba would work. A warning, though: if the commit hash contains only digits 0-9 and the first digit is 0, that is not a valid SemVer either. (spec section 9)

A SemVer with a hyphen in it is considered to be a pre-release version, so using 1.0.27-build.14+commit.33ed7ba and then removing the -build.* part for the final version of 1.0.27 would work. If the commit hash is put after a plus sign, it also won't have problems with leading zeroes. (spec section 10)

Ok, that means that the web service is able to run with the permissions you have when you elevate.

If the web service is running with restricted permissions, it might not be able to access something it needs to start up.

As far as I know, it needs read/write access to C:\ProgramData\Otter, read access to C:\Program Files\Otter, and the ability to communicate over the named pipe otter-ctrl.

Are you able to access the Otter web UI while it's running?

Ah, sorry, I misread. The web service is what's having problems starting, so this would be the command instead:

cd "C:\Program Files\Otter\Service"
.\Otter.Service.exe run --mode=webonly

Hello Brad,

Is there any error message if you run this from an elevated shell?

cd "C:\Program Files\Otter\Service"
.\Otter.Service.exe run --mode=serviceonly

Hello Clint,

To do this, you would need to use the native API. For example:

(newlines inserted for readability. they would not be in the actual request.)

POST /api/json/Feeds_CreateFeed HTTP/1.1
Content-Type: application/x-www-form-urlencoded

key=[your native API key]&
Feed_Name=[feed name]&
FeedType_Name=Chocolatey&
FeedConfiguration_Xml=%3CInedo.ProGet.Feeds.NuGet.NuGetFeedConfig%20Assembly%3D%22ProGetCoreEx%22%3E
%3CProperties%20UseLegacyVersioning%3D%22False%22%20%2F%3E
%3C%2FInedo.ProGet.Feeds.NuGet.NuGetFeedConfig%3E

The easiest way to get a value for FeedConfiguration_Xml is to configure a feed in ProGet and then copy that column from the database.

Hello Bruce,

It looks like this can happen when the package store fails to open the file for writing.

If you don't have a custom package store set for the UPack feed, make sure Storage.ProGetPackagesLibrary is set to a full path in /administration/advanced-settings and that the ProGet web server process can modify files in that path.

Hello Friedrich,

This appears to be a bug in Mono. We previously had a workaround that would parse multipart requests manually using the input stream, but it appears that even that is broken now.

I've filed mono#6801 with a test case.

Unfortunately, there is not much we can do until this is resolved on their end.

Hello Matt,

What version of Docker do you have installed? As of ProGet 4.8.2, we require Docker 1.11.0 or newer because we use token authentication (PG-1059).