Yes, it's available. You will need to associate the licenses with a "known" license type that is allowed. Many NuGet packages ship with proprietary licenses, or licenses that point to "random" URLS (like GitHub.org/project-name/license.txt) instead of a "known" OSI URL. This is why they are considered "unknown" to ProGet.

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.

I think I got it working. The documentation is really lacking and hard to find. After hours of searching I found https://inedo.com/support/kb/1112/api-keys-in-proget page. First I had to drop anon permissions to "Publish Packages" (I think it may have been off by default). Add a new task (e.g. "Publish to feed") and select the following operations: Add package Overwrite package View feed Grant anon user permissions to the new task Set an API key for the target feed and use the key in my CI/CD pipeline

In this case, the account that the buildMaster service is running under is not an active directory account, or does not have permission inside of ProGet.

This is supposed to check every hour. If it's not, sounds like the service's task runner isn't running. Just restart the service, then its should be ok.

This would require a custom operation to capture this text. You could also use a tool like sqlcmd.exe to output the result to the textfile.

Definitely; this feature is certainly slated for redesign, to bring it more in the line of a "scheduled job" concept, and unifying implementation across our products (ProGet, Otter, Hedgehog as well). This concept of "don't run this job if an execution associated with this job is currently running" is how it could be implemented/described I suppose

The situation with Azure is a bit confusing; I will put a note in to the docs team that it should support asset storage, but it can not support large/chunked uploads because of the limitations of the blob storage API that Alana mentioned.

It's just an unfortunate mix of terminology in "promotion" vs "deployment" vs "execution". A "promotion" is simply allowing a package to be deployed to the stage and should only happen once per release. A "deployment" can happen anywhere but may be restricted by pipeline settings depending on if the package was previously promoted, and an "execution" is essentially the worker that performs the deployment (and there could be many per deployment). The fix will make it perform a deployment instead of a promotion then a deployment, so it will work as you're expecting.

As long as the digital certificate is signed by Inedo, it's just a false positive. Please see: https://inedo.com/support/kb/1113/anti-malware-false-positives-code-signing-and-safety-of-inedo-products

Thanks Jon! This is not an uncommon pattern, it's something I call the "quasi-custom software" problem. I.e. you have a "small" number of customers (dozens not thousands), and each customer gets (1) small customizations to a common platform, and/or (2) customer-driven testing and rollout scheduling. In BuildMaster, I have seem both patterns; the "customer per app" seems to work the best when you need individual workflows and customizations, and then you can just deploy artifacts from the "core" app. Having seen this problem for many years, I have yet to see any tool that will "properly" model the situation; Octopus does have an interesting "multi-tenant" feature, but it's not so well suited for individual maintenance workflows. In my mind, this is a key benefit to the "quasi-custom software" model that companies like yours provide. That said, I think we will have definitely have better handling for this in our next generation of tooling (i.e. Hedgehog). Projects will lend better to sharing than applications, and one of our usecase for nested projects will be grouping customers in this manner Universal/romp packages will be able to be bundled, allowing for an easy conceptualization of the "quasi-custom" code as well It's not a huge departure from BuildMaster now, but it will just be much easier to handle I think!

This is the nature of connectors; if npm client asks for "latest" version, then all connectors need to be searched. If you don't want behavior, then you need to remove connectors that have newer versions.

Hi Alana, Thanks its working fine now.

Hey Alex, Thanks for the follow up! I did continue working on this, and got to a point where I'm happy with how it is working. I was in contact with Karl about it too via email, and sent him some details, but for reference for others who find it useful.. We went with the solution of putting the config into separate files, using the 'configSource' option as needed to specify references to external files. Further to that, we created an extension for Otter to allow us to manage the settings in those files - similar to how the 'EnsureAppSetting' thing works, but allowing an XPath expression to be used to identify the precise element in the config file to check. That meant we could use it for e.g. files that hold connection strings. (I do intend to publish that extension to the Den at some point - haven't so far gotten around to it though). Let me know if you would like any more detail on what we're doing! Thanks, Andrew

Looks like that's the wrong url; any url that starts with "/feeds" is for the UI only. Pl;ease use the "API Endpoint" URL specified on that same page intead.

As an alternative choice you can use Powershell for this. Add a 'Windows Powershell' step (be sure to install that Jenkins plugin first): DIR -Recurse -File -Filter "*.nupkg" | @{ & nuget.exe push $_.FullName -Source https://urltoyourproget/nuget/feedname } You will also need to ensure you have the nuget.exe command line executable available to the Jenkins node running. Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

This would require writing a custom package store. The disk-based package store does not support this. Perhaps consider using Connectors, or something like that

The Directory Troubleshooting docs page has more information: https://inedo.com/support/documentation/various/ldap/troubleshooting

Changing the name during a promotion can't be done, primarily because that's the key that identifies which packages are promoted. Would it be feasible to create another package with the same contents and non-pre-release name in the Dev Feed, then promote that?