If you set --targetDirectory on the pack command to an empty or nonexistent directory, the .upack file will be the only file in there, and you can use myDirectory\*.upack to select the upack file for the push command.

Did the multi-part API get implemented for universal packages? This is still an issue.

This means that your computer cannot connect to My.Inedo for alicense key. Please request one by logging into my.inedo.com.

Hello Michael, NPM feeds don't currently support an API key, but you can share a single ProGet user between all of the users who need to upload to the feed to simulate the same thing. The Publish Packages task group on the NPM feed is all you need to upload a package. If you want to replace an already-uploaded package, you need the Overwrite Package task, which is available on the Administer and Manage Feed task groups by default, but you can create a new task group with just Overwrite Package on the Customize Tasks page (/administration/security/customize-tasks).

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