A vulnerability version range can be: the literal string (any) empty string (equivalent to (any)) single single, single single, single, single single, single, single, single etc. A single vulnerability version range can be: version >version >=version <version <=version >version <version >=version <version >version <=version >=version <=version The format of version is defined by the feed type.

Hello Matt, It looks like the PostgreSQL version of Feeds_SetLastSyncDate was not updated when the MSSQL version was. I've logged this as PG-1006 and it will be fixed in the next version of ProGet.

I see you also opened a ticket, so it's going to be best to collaborate on that instead. But I will respond here as well in case anyone finds this... Unless you're entirely distributing third-party, vendor-provided packages (i.e. you don't move them through a pipeline like Dev > Test > Prod), then BuildMaster is quite important to manage this pipeline , especially in regulated environments. Regarding HA, it's best to first come up with a list of questions you'd like us to help with, and then we can research and figure out how best to help. For example, we can't really help on selecting or configuring a particular brand of load balancer; that's something generally done by your IT/NetOps folks, but we could point you to Microsoft's NLB documentation (which has step-by-step instructions on how to set it up).

There's a bug we haven't been able to figure out where the Linux version of ProGet doesn't respond to requests for URLs with colons in them.

Hi Alana, Thank you for the update. I was quite surprised too when realised we can't use case insensitive collation in Postgres. But what if we have 2 columns, one contains data as is, and one contains normalised data, e.g. Login and LoginNormalized. The first one is indexed, the last one is used in queries. But I understand this leads to different schemas in SQL Server and Postgres. I completely agree we can bet on SQL Server, but I don't know its licensing options yet. Posgres is working well from my point of view, except this detail. Since a lot of web applications use Postgres and I haven't heard about case sensitive logins yet, I believe that solution exists. Thank you for all of your hard work on this awesome project!

That is good news, i was able to bypass this though by setting the service to run as an outgoing trust user which then allowed me set the LDAP to the other domain.

If you are using IIS, you'll need to make sure that the ProGet AppPool is set to use Integrated Pipeline mode. If hosting with the integrated web server, it should just work. You may also need to enable always-auth for npm to force basic authentication.

I agree that it is a poor solution, but we do not have very many good solutions for this. Docker itself does not support prefixing private repositories; everything is assumed to be hosted in the same manner as the public registry (ie, absolute URL path from the server root), and assuming all /v2/ requests are Docker without some other declaration of intent in the request didn't seem good either. That said, if there's no collisions with anything else using that URL, we can change the default behavior.

Please upgrade to the latest version of ProGet; 4.3.1 is outdated.

Answering my own question: all one needs to so for this is to remove the Anonymous user from the users allowed to "View and download packages".

Note that these are different issues. Please upgrade to the latest ProGet to resolve this and the other issue. As of this post, that's 4.7.8. However, we do release often so if another one comes out before then, pick that one :)

This can be found in the lower-right of any page in the software.

You can configure this via the "BaseUrl" setting in the Admin > Advanced Settings configuration option.

This package indicates that the package you are adding is in an invalid format. If it's a nuGet feed, you must upload a nuget package. If it's a universal feed, you must upload a universal package format.

This seems to be fixed as of the Docker image containing ProGet Version 4.7.14. The Docker image hash is: b7a3d6595c21d34997b4cbe6da9187801f410f17bff8e84228711bf29396a6ab pulled on 9/6/2017

Ok I figured out what I was doing wrong. I was setting the URL in build.gradle to: http://<user>:<password>@proget-server But it should look like this instead publishing { repositories { maven { credentials { username "$mavenUser" password "$mavenPassword" } url "http://proget-server" } } } With the mavenUser and mavenPassword being defined in ~/.gradle/gradle.properties

This is on our list for an upcoming maintence release, and may get implemented in the next one. you can check the status of it at PG-1001. https://inedo.myjetbrains.com/youtrack/issue/PG-1001

There are many guides and ways to do this, please search "adding a maven artifact to a repository". Here is one such example: https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

Version 1.1.0 of the upack command line tool is now available from http://inedo.com/support/documentation/proget/reference/upack. The chocolatey version has been submitted and will be available once it's approved.

In this case, you will need to give the "Anonymous" access to push packages to the feed. You can configure this from Admin > Tasks.