Posts made by ben

Hello Attila,

This is indeed a bug. I've filed PG-1272 to fix this.

Hello Tobias,

PG-1270 will make local packages appear before remote packages in the list, as well as making connector packages appear in the same order that they would appear in the connector.

Hello Fabrice,

I looked at the code and it seems that only NuGet and UPack feeds look at those headers. I've filed PG-1271 to make npm feeds also record deployments.

Hello Yutaccho,

To help me track down the exact cause of this issue, does using a forward slash instead of a backslash in the vsix manifest's <Icon> element cause ProGet to display the correct icon?

Hello Lev,

A possible reason this might be happening is if Apache is caching the 404 error returned by Docker when the client checks for an existing layer and then returning the cached error after the layer is uploaded and the blob URL becomes valid.

Hello Chris,

I don't think Bower feeds store anything on the filesystem (it's all in the database). I've filed PG-1256 to add support for Maven feeds being stored in package stores.

Hello Rob,

I've released version 1.0.1 of the TeamCity extension, which should fix this (or at least give a more sensible error message). It should be available in /administration/extensions.

Hello Subash,

To check whether any connectors are unhealthy, you could use a PowerShell script like this:

$someConnectorsUnhealthy = (
    Invoke-RestMethod 'https://devget.syhapp.com:8798/api/json/Connectors_GetConnectors?API_Key=*******&Feed_Id=***' |
    Where-Object { $_.Status_Code -ne 'H' }).Count -gt 0

After this, $someConnectorsUnhealthy is $True if any connectors for that feed are not in a healthy state, and $False if all connectors are healthy.

If your API key contains = or +, it needs to be URL-encoded, with = replaced by %3D and + replaced by %2B. Alternatively, you can change the API key to be URL-safe.

Hello Dmytro,

I've filed PG-1252 to address this.

Hello Jon,

Is the Approval Required event listener filtered by pipeline stage?

Approval Required listens for Build Promotion Completed events, so the pipeline stage filter should have the name of the stage of the pipeline immediately before the approval gate, not the stage that is blocked by the approval gate.

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).

Hello Rickard,

This is PG-1212 and will be fixed in ProGet 5.0.9.

Hello Leandro,

Feeds_GetLicenseUrls hasn't existed since 4.7.0. It's possible that the error you encountered was from a custom extension which is not compatible with 5.0.

ProGet 5.0 uses the Inedo.SDK NuGet package instead of the Inedo.ProGet.SDK NuGet package, and loads extensions that end in .inedox instead of .progetx.

Hello Phil,

This appears to be a bug where NuGet packages with no stable versions keep their first-uploaded version as the "latest". I've filed PG-1201 with a fix.

As a workaround, uploading a version of the package with a version number that does not include a hyphen (with a lower version number than the actual latest version of the package) will make the latest version update correctly.

I have tracked down the root cause of this issue. NuGet feeds (but not NuGet (quirks) feeds) in ProGet 5 generate a list of symbols, but never actually put them in the database.

The fix is filed as PG-1195 and will be coming in the next version of ProGet 5. It includes a button in the feed management page to re-index all symbols in a feed, and packages affected by this bug have a message with a link to the feed management page in the place where the list of symbol files would normally be.

Hello Matt,

Is Web.BaseUrl set to https://host.name.net in https://host.name.net/administration/advanced-settings? Is there a reverse proxy between ProGet and the internet that requires authentication, or that might be modifying authentication headers?

If you access the /v2/ URL in your browser, there should be a header like WWW-Authenticate: Bearer realm="https://host.name.net/v2/_auth",service="host.name.net".

EDIT: We have updated our Docker documentation to include this information and more information about setting up your Docker client and ProGet server.

Hello Clint,

This SQL will copy any credentials that BuildMaster has but Otter doesn't to Otter. However, it will not work if BuildMaster and Otter use different encryption keys. You can find the encryption keys for BuildMaster and Otter in app_appSettings.config and in web_appSettings.config. The key will look like this in the file: <add key="Persistence.EncryptionKey" value="[encryption key is here]" />

INSERT INTO [Otter].[dbo].[Credentials] ([Environment_Id], [Credential_Name], [CredentialType_Name], [LegacyConfiguration_Bytes], [Configuration_Xml], [AllowFunctionAccess_Indicator])
-- Omit the line above this comment to test this before running it for real
SELECT OE.[Environment_Id]
      ,BC.[Credential_Name]
      ,BC.[CredentialType_Name]
      ,[LegacyConfiguration_Bytes] = NULL
      ,[Configuration_Xml] = CAST(REPLACE(
                                REPLACE(
                                    REPLACE(
                                        REPLACE(
                                            REPLACE(
                                                REPLACE(
                                                    REPLACE(
                                                        REPLACE(
                                                            REPLACE(
                                                                REPLACE(
                                                                    CAST(BC.[Configuration_Xml] AS VARCHAR(MAX)),
                                                                    '<Inedo.BuildMaster.Extensibility.Credentials.BuildMasterCredentials Assembly="BuildMasterCore">',
                                                                    '<Inedo.Otter.Extensions.Credentials.BuildMasterCredentials Assembly="OtterCore">'
                                                                ),
                                                                '<Inedo.BuildMaster.Extensibility.Credentials.OtterCredentials Assembly="BuildMasterCore">',
                                                                '<Inedo.Otter.Extensions.Credentials.OtterCredentials Assembly="OtterCore">'
                                                            ),
                                                            '<Inedo.BuildMaster.Extensibility.Credentials.ProGetCredentials Assembly="BuildMasterCore">',
                                                            '<Inedo.Otter.Extensions.Credentials.ProGetCredentials Assembly="OtterCore">'
                                                        ),
                                                        '<Inedo.BuildMaster.Extensibility.Credentials.PrivateKeyCredentials Assembly="BuildMasterCore">',
                                                        '<Inedo.Otter.Extensions.Credentials.PrivateKeyCredentials Assembly="OtterCore">'
                                                    ),
                                                    '<Inedo.BuildMaster.Extensibility.Credentials.UsernamePasswordCredentials Assembly="BuildMasterCore">',
                                                    '<Inedo.Otter.Extensions.Credentials.UsernamePasswordCredentials Assembly="OtterCore">'
                                                ),
                                                '</Inedo.BuildMaster.Extensibility.Credentials.BuildMasterCredentials>',
                                                '</Inedo.Otter.Extensions.Credentials.BuildMasterCredentials>'
                                            ),
                                            '</Inedo.BuildMaster.Extensibility.Credentials.OtterCredentials>',
                                            '</Inedo.Otter.Extensions.Credentials.OtterCredentials>'
                                        ),
                                        '</Inedo.BuildMaster.Extensibility.Credentials.ProGetCredentials>',
                                        '</Inedo.Otter.Extensions.Credentials.ProGetCredentials>'
                                    ),
                                    '</Inedo.BuildMaster.Extensibility.Credentials.PrivateKeyCredentials>',
                                    '</Inedo.Otter.Extensions.Credentials.PrivateKeyCredentials>'
                                ),
                                '</Inedo.BuildMaster.Extensibility.Credentials.UsernamePasswordCredentials>',
                                '</Inedo.Otter.Extensions.Credentials.UsernamePasswordCredentials>'
                            ) AS XML)
      ,BC.[AllowFunctionAccess_Indicator]
  FROM [BuildMaster].[dbo].[Credentials] BC
  LEFT OUTER JOIN [Otter].[dbo].[Credentials] OC
               ON BC.[Credential_Name] = OC.[Credential_Name]
  LEFT OUTER JOIN [BuildMaster].[dbo].[Environments] BE
               ON BC.[Environment_Id] = BE.[Environment_Id]
  LEFT OUTER JOIN [Otter].[dbo].[Environments] OE
               ON BE.[Environment_Name] = OE.[Environment_Name]
 WHERE OC.[Credential_Id] IS NULL

This may be fixed by ILIB-19, which makes buffering of Docker layer uploads happen in a temporary file instead of in memory. It's very possible that SlimMemoryStream has a bug that only manifests when it has several gigabytes of data in it.

microsoft/windowsservercore has a 7GB foreign layer, and I assume you're using the allow-nondistributable-artifacts option on the Docker daemon because you mentioned the system is not connected to the internet, so the next version of ProGet will stop that 7GB upload from being buffered in memory.

If the PDB files aren't being indexed by ProGet, it's possible that ProGet can't read them for some reason.

Try compiling this program with references to ProGetCoreEx.dll and InedoLib.dll from your version of ProGet and a reference to the System.Reflection.Metadata NuGet package and then dragging and dropping your nupkg file onto the resulting exe.

If you don't care about portable PDB files, you can also skip adding the reference to System.Reflection.Metadata and remove the code between the comments.

using Inedo.ProGet.Feeds.NuGet;
using Inedo.ProGet.Symbols;
using System;
using System.IO;
using System.IO.Compression;
using System.Linq;

namespace ReadPDB
{
    class Program
    {
        static void Main(string[] args)
        {
            if (args.Length != 1 || !args[0].EndsWith(".nupkg") || !File.Exists(args[0]))
            {
                Console.Error.WriteLine("Usage: ReadPDB [PackageName].nupkg");
                Environment.ExitCode = 1;
                return;
            }

            using (var zipFile = new ZipArchive(File.Open(args[0], FileMode.Open, FileAccess.Read)))
            {
                var pdbEntries = zipFile
                    .Entries
                    .Where(e => e.FullName.EndsWith(".pdb", StringComparison.OrdinalIgnoreCase));

                foreach (var pdbEntry in pdbEntries)
                {

                    using (var pdbStream = SeekableStream.Create(pdbEntry))
                    {
                        try
                        {
                            using (var pdbFile = new PdbFile(pdbStream, true))
                            {
                                Console.WriteLine($"PDB successfully read: {pdbEntry.FullName}");
                                Console.WriteLine($"GUID: {pdbFile.Guid}");
                                Console.WriteLine($"Age: {pdbFile.Age}");
                            }
                        }
                        catch (Exception ex)
                        {
                            // Start removing here if you don't want Portable PDB detection
                            try
                            {
                                pdbStream.Position = 0;
                                using (var pdbProvider = System.Reflection.Metadata.MetadataReaderProvider.FromPortablePdbStream(pdbStream, System.Reflection.Metadata.MetadataStreamOptions.LeaveOpen, (int)pdbEntry.Length))
                                {
                                    var portablePdb = pdbProvider.GetMetadataReader();
                                    Console.WriteLine($"Portable PDB (not yet supported in ProGet): {pdbEntry.FullName}");
                                    Console.WriteLine($"ID: {BitConverter.ToString(portablePdb.DebugMetadataHeader.Id.ToArray())}");
                                }
                            }
                            catch
                            // Stop removing here if you don't want Portable PDB detection
                            {
                                Console.WriteLine($"Exception reading PDB: {pdbEntry.FullName}");
                                Console.WriteLine(ex);
                            }
                        }
                    }
                    Console.WriteLine();
                }
            }
        }
    }
}

I ran it on an AWS SDK package I had handy and got this output:

Portable PDB (not yet supported in ProGet): lib/net35/AWSSDK.Core.pdb
ID: 5A-C8-40-60-8B-E5-A0-41-80-C7-EE-B9-8C-A0-5B-A0-A0-62-05-B0

Portable PDB (not yet supported in ProGet): lib/net45/AWSSDK.Core.pdb
ID: 4F-87-A8-84-3D-D1-C0-47-AE-87-C2-31-06-3A-6E-1E-F3-FD-D4-B4

PDB successfully read: lib/portable-net45%2Bwin8%2Bwpa81%2Bwp8/AWSSDK.Core.pdb
GUID: dc8ebad0-50a8-472e-9cc3-60532a217cbc
Age: 1

PDB successfully read: lib/uap/AWSSDK.Core.pdb
GUID: a397a2d1-0d7d-421c-a439-2035263a60aa
Age: 1

PDB successfully read: lib/MonoAndroid10/AWSSDK.Core.pdb
GUID: 30508864-ead4-403e-9a70-7cf92ddc62b3
Age: 1

PDB successfully read: lib/win8/AWSSDK.Core.pdb
GUID: 03674990-484c-4e12-a418-95b02a794ceb
Age: 1

PDB successfully read: lib/wpa81/AWSSDK.Core.pdb
GUID: a397a2d1-0d7d-421c-a439-2035263a60aa
Age: 1

PDB successfully read: lib/wp8/AWSSDK.Core.pdb
GUID: 73cde1a1-208e-4146-84d0-556fa77badc1
Age: 1

Portable PDB (not yet supported in ProGet): lib/netstandard1.3/AWSSDK.Core.pdb
ID: 54-A2-57-38-16-AB-F1-42-A8-90-4B-6B-4E-F1-9A-FA-2F-72-9D-C7

Hello Tristen,

Are you using a custom package store, such as AWS or Azure, or are the files stored in the default (local filesystem) package store?

For images, you can upload them to an external site (such as imgur) and use the photo button on the toolbar.

Symbols are accessed through this path: /symbols/[feed name]/[dll name].dll/[guid without hyphens]/[pdb name].pdb

So for the example in the image, the URL Visual Studio would request would be http://proget-url/symbols/NuGet/Bar.dll/872237e9cd584333bbe489f59ab9c89b/Bar.pdb

Just to be clear, you're only uploading the .symbols.nuget version of the package, right? If you upload the version that is just .nuget, it will overwrite the package that's already there with one that doesn't have symbols.

Hello Rob,

Sorry for the delay. Does the error occur with any Docker image that is available on Docker Hub (or, would you be willing to share your Docker image)?

Also, are you using docker-machine or something similar to run Docker on a virtual machine, or is Docker running natively on the machine with PowerShell?

Hello Boyd,

Your first question is a visual error (the symbol server is actually enabled, but the feed management page shows disabled due to a bug) - issue number PG-1169.

For the second question, on the package page, under the Files tab, does the lib\net461 folder contain a PDB file? Symbols built with <DebugType>Full</DebugType> should work. The only debug type ProGet doesn't currently support is Portable.

Hello Javier,

There is an error in the PostgreSQL version of NuGetPackagesV2_GetLatestStable, which was introduced in the 5.0 beta. I've filed this as PG-1164 and submitted a fix for my co-workers to review.

Sorry for the late reply,

ILIB-6 is the tracking number for this bug (zero-length SlimMemoryStream throws a NullReferenceException when CopyToAsync is called).

It will be fixed in the next version of ProGet, or, as noted above, you can revert to ProGet 4.8.7. There were no database structure changes between 4.8.7 and 4.8.8, so backing up your database is recommended, but restoring an old copy is not required.

Copying the explanation from the private ticket in case anyone else has this issue:

Inedo products store timestamps in the database as UTC, but our PostgreSQL library (Npgsql) "helpfully" converts DateTime objects to the local time zone. They added a way to change this behavior in their 3.3 release, but the currently available version of Npgsql is 3.2.5.

I've written a workaround for this, where DateTime objects will be converted to UTC by the database middleware. I've filed this as ILIB-7.

Hello Julien,

I've filed this as PG-1147 and a fix should be coming in the next version of ProGet.

When this build finishes, docker pull inedo/proget will fix the issue with special characters in the database password:
https://hub.docker.com/r/inedo/proget/builds/bi8ds7thvriyfldkbh2daj6/

Hello Jason,

The issue on the second run should be fixed by ProGet 4.8.8 (docker pull inedo/proget).

Due to the very simple way our Dockerfile adds the database connection information to the configuration file, you'll need to encode < as <, > as >, " as ", and & as & if they appear somewhere (I'm guessing it's in the password).

Edit: Actually, that won't work because the database updater gets the connection information verbatim. I'll fix the Dockerfile so it encodes entities as needed.

Hello Kasper,

I can't find where I solved this before, but I think the solution was to add a trailing slash to the registry URL. That is, if your registry is at http://example.com/npm/example-npm-feed, you would need to specify the parameter for npm 5.5 as --registry=http://example.com/npm/example-npm-feed/

Hello ougwen1235,

Is there any error message in the Docker container logs? To see logs for a Docker container, use the command docker logs "container-name". (If you followed the instructions exactly, the container name is proget.)

I have reproduced the problem with the rich text editor and I will work on a fix.