Hi @Stephen-Schaff,

The renewal contact at your organization should have been receiving emails about 60 days ago, and then someone was supposed to be manually following up... but something clearly fell through the cracks. I already escalated it internally.

But not to worry! In a case like this, please just go to my.inedo.com, and request a 30-day trial license key. It has all the functionality of ProGet Basic, so your service won't be interrupted at all.

Changing the expiration warning in the software to 30 days is really good idea to prevent problems like this, so I'll request that as a feature internally :)

Cheers,

Nanci

@Stephen-Schaff thanks so much Stephen, that's great! It's not so hard for us to add this api key back, but your code works just the same mostly i think! let us know...

Anyway I've updated the documentation :)

Hi @mihajlo_7906 ,

It looks like you're using legacy functionality (i.e. from BuildMaster v4 and earlier) within a legacy version (v5) of BuildMaster.

Re-execute from last failed action button is re-executing the whole pipeline stage (from the beginning) instead of the current action of which the deployment failed.

The "Re-execute from Last Failed Action" is only displayed on some Legacy Plan executions, and it can't work on all plans. I'm not sure why it doesn't work in your case, but we no longer have such functionality on for non-legacy (OtterScript) executions, so I can't guess why it doesn't work.

An unhandled exception occurred while executing this action: System.IO.FileNotFoundException: Could not load file or assembly 'Windows' or one of its dependencies. The system cannot find the file specified.

This error is saying that the "Windows" extension file (Windows.upack or Windows.bmx, depending on the configuration) didn't load.

This is why why deployments fail. The most common reason for this is file locking (anti virus, etc.), but you can use tools like Procmon to see what's going on. Loading an extension involves unzipping it and loading the enclosed .dll from disk.

Cheers,
Alana

Hi @steviecoaster ,

Very cool, looking forward to the packages!

Here is the URL for the ProGet license agreement:
https://inedo.com/proget/license-agreement

The Inedo Hub does not have a separate license agreement, we just consider it part of the product; so you can just use ProGet's:
https://inedo.com/proget/license-agreement

Thanks,
Nanci

Hey @pmsensi ,

Just to jump in here... it sounds like there are two issues.

I think the first issue is that properties like owners, verified, etc. are not returned for local packages.

Those properties are not "package metadata" properties (i.e. stored inside the package), but they're "server metadata" properties (i.e. stored outside the package, on the server). Other server metadata properties are downloadCount and listed.

ProGet does not support all of the server metadata properties that nuget.org does; but even if it did, the properties would not be copied from a connector when a package is added to the feed. This is why downloadCount turns to 0 when cache a package.

However, server metadata properties are "passed through" remote packages.

The "package metadata" properties are contained in the .nuspec manifest file:

<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>Microsoft.Playwright.NUnit</id>
    <version>1.35.0</version>
    <title>Microsoft.Playwright.NUnit</title>
    <authors>Microsoft</authors>
    <license type="expression">MIT</license>
    <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
    <icon>icon.png</icon>
    <projectUrl>https://github.com/microsoft/playwright-dotnet</projectUrl>
    <description>Playwright enables reliable end-to-end testing for modern web apps. This package brings in additional helpers and fixtures to enable using it within NUnit.</description>
    <copyright>© Microsoft Corporation. All rights reserved.</copyright>
    <tags>headless,chrome,firefox,webkit,playwright</tags>
    <repository type="git" url="https://github.com/microsoft/playwright-dotnet.git" commit="ca7b02ac910e573666f48d502bfabb1c17639e68"/>
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Microsoft.Playwright.TestAdapter" version="1.35.0" exclude="Build,Analyzers"/>
        <dependency id="Microsoft.Playwright" version="1.35.0" exclude="Build,Analyzers"/>
        <dependency id="Microsoft.NET.Test.Sdk" version="16.11.0" exclude="Build,Analyzers"/>
        <dependency id="NUnit" version="3.13.2" exclude="Build,Analyzers"/>
        <dependency id="NUnit3TestAdapter" version="4.0.0" exclude="Build,Analyzers"/>
      </group>
    </dependencies>
  </metadata>
</package>

The second issue, I think, is that the versions property is not aggregated. This isn't really feasible/possible to do as a result of the "paged searching" that Dean mentioned.

For example, if you search search a feed for q=foo,take=2, then ProGet will work as follows:

1. Search local packages for foo
2. Return up to 2 search results; if not enough results, then ...
3. Forward search to first connector
4. Return search results; if not enough, then...
5. Forward search to second connector
6. Etc...

To get the behavior that you'd like, ProGet would need to:

1. Search local packages for foo
2. For each search result, query each connector for a list of all package versions (registrations)
3. Aggregate those results into the version property
4. Return up to 2 search results; if not enough result then...

So this is why it's not really possible to get search API to behave like you'd expect.

Hope that helps,
Nanci

Hi @mihajlo_7906 ,

It looks like you're using legacy functionality (i.e. from BuildMaster v4 and earlier) within a legacy version (v5) of BuildMaster.

Re-execute from last failed action button is re-executing the whole pipeline stage (from the beginning) instead of the current action of which the deployment failed.

The "Re-execute from Last Failed Action" is only displayed on some Legacy Plan executions, and it can't work on all plans. I'm not sure why it doesn't work in your case, but we no longer have such functionality on for non-legacy (OtterScript) executions, so I can't guess why it doesn't work.

An unhandled exception occurred while executing this action: System.IO.FileNotFoundException: Could not load file or assembly 'Windows' or one of its dependencies. The system cannot find the file specified.

This error is saying that the "Windows" extension file (Windows.upack or Windows.bmx, depending on the configuration) didn't load.

This is why why deployments fail. The most common reason for this is file locking (anti virus, etc.), but you can use tools like Procmon to see what's going on. Loading an extension involves unzipping it and loading the enclosed .dll from disk.

Cheers,
Alana

Hello @itpurchasing_0730 ,

The simplest way to handle this is with some some SQL Commands (i.e. the Native API), after the ProGet database is installed/updated.

You can execute commands like this:

docker exec -it inedo-sql /opt/mssql-tools/bin/sqlcmd \
  -S localhost -U SA -P '«YourStrong!Passw0rd»' \
  -Q '«sql command here»'

The commands to run (note you'll need to escape the single-quotes):

• EXEC Configuration_SetValue 'Licensing.Key', '«your key»'
• EXEC Users_SetPassword 'Admin', «password-bytes», «salt-bytes»

«password-bytes» and «salt-bytes» will be hex strings, like 0x0000, and you can find those values by querying the Users table after you've set the admin password to be what you want.

Hope that helps!

Cheers,
Nanci

Thanks for report @jim-borden_4965

We just reviewed the Version Order Specifications, which are a bit ambiguous... but if that's what the version class does, then we may as well follow.

I've fixed this as PG-2226 by comparing integer version qualifiers numerically, and it will be in the next maintenance release.

@mistique88885_0973 thanks for letting us know! I didn't realize that was wrong.

I just corrected the text , and it will be fixed via PG-2225 in the next maintenance release

Hi @jim-borden_4965 ,

The Maven API doesn't support artifact deletion, and we haven't had any requests for that to date. I suppose, usually because it's pretty rare to need to delete a package :)

In general, users configure automatic retention rules to delete older things.

From a UI-perspective, there is the "bulk package deletion" that's available in ProGet 2022 and later, and so that might save a bunch of clicks.

Cheers,
Nanci

Hi @grant-drake_7379 ,

Here are some steps for how to switch to IIS:
https://docs.inedo.com/docs/various-iis-switching-to-iis

Also note that when uninstalling ProGet, your database/packages are not deleted :)

Cheers,
Nanci

Hi @afd-compras_2365 ,

This is the second request for the feature - but I'll bring this up at our engineering meeting.

@benjamin-soddy_9591 is there something more you can add to the conversation ?

Cheers
Nanci

hi @ab-korneev_0401 ,

By "debugging", we mean running the ProGet code inside of Visual Studio's "debug mode". That will show the errors let us see quickly how to fix them. I'm afraid it's not easy to identify the problem without it, since it's very likely a bug in the third-party repository you're using.

Since it's not possible to provide that information, can you...

1. create a server on AWS LightSail (or similar cloud service)
2. Install the same type of third-party repository software and configure it in same manner
3. upload one or two packages that reproduce the problem
4. verify the problem in ProGet

Then, send us the information of the server, and we can look at it through the debug mode