Thank you for the report. This will be resolved in the next maintenance release as issue OTTER-130.

Thank you for this amazing honest answer, Coming from .NET and Nuget, i've been enjoying the struggles of npm and it's evil offspring for a while now, haha All developers swear it's so good, until we need to make builds from their code...

I found the solution. I had tried several different ways but finally found the right way. Just putting folder/job/jobname in the List Source made it work. The list won't auto show the job but you can type it in and it works.

Yes of course, smacking forehead now! Thanks!

Spectacular - that was exactly what I was hoping. Thank you for taking the time to answer!

There is a "multi-domain / forest" AD provider. As long as the domains have a trust to eachother, then the users from the other domain will be enumerated and it should "just work". We are considering building a new active directory provider that allows you to explicitly list the domains to query (instead of doing a trust search), but that ended up getting really complex fast, so it's on hold just for a bit...

Yes, that's precisely what it would be; an ATOM feed for private galleries that you can push extensions to. I think only MyGet supports it now, so we will look to them for how they handle pushing, so it can be consistent. Most of our enterprise customers wanted to create a workflow like they do with NuGet.org, with only certan public packages in the feed, etc. THat is, they didn't have custom extensions, they only wanted to restrict or cache public extensions for their developers.

Just to clarify... the "NuGet v3 API" is intended for internal-use (i.e. only nuget.exe and NuGet VS extension). Microsoft's new position is that they do not intend on making this API public or stable in the foreseeable future, and that they will continue to support the "NuGet v2 API" (which is documented and public) indefinitely. They actually use ProGet to test changes to v2 API. That said, until this position changes, we will not reverse-engineer the v3 protocol. So this means you will need to use nuget.org/api/v2 in your connector, not the v3 url. Both v2 and v3 API work with client tools, both support DotNetCore, etc. If you're finding a issues with DNC projects, then it's likely related to framework monikers or something like that. Please submit a ticket for this with specifics, so we can investigate and patch.

Unfortunately Visual Studio doesn't support authenticated symbol servers; i.e. if ProGet sends a 401 response, there is no authentication challenge. We may be adding a feature in 4.7 that allows for "url authentication" of sorts, where you use a "obscured" url with an api key in it somewhere that will cause authentication to be effectively bypassed.

It's hard to say, so we'll need to diagnose a bit further. Could you submit a ticket for this, with the following: which packages work? something from a package that doesn't work... package type (NuGet, npm, etc) metadata file (like nuspec, package.json, or entire package is fine) screenshot exhibiting this behavior With this, we can go back-and-forth over email a bit easier.

Auth tokens are now supported for npm feeds; you'll need to create the token as a ProGet API Key. Please see the API & Access Key documentation to learn more. This is an updated answer; earlier the answer mentioned the feature was not supported.

Pb solved with the 1.5.2

Pb solved with the 1.5.2

Pb solved with the 1.5.2

Thank you so much. This is exactly what i'm looking for.

I was able to get Otter to work with TFS Git on-premises. All I needed to do was set the Otter website and service to run as a specific domain user that has rights to the TFS Git repository. Then in the Raft settings, leave the username and password empty. The Otter code will use the "DefaultCredentials" in LibGit2Sharp., which are the credentials of the currently executing service user. This is slightly sub-optimal, but it works. The next thing I would like to understand is why Git rafts are so slow (going to assets is fairly slow to load, ~10 sec) P.S. I never tried setting the "Basic Authentication" in TFS you recommended, as it is a fundamental change that could affect other users and services.

Ah, good find. The file browser is the only component of the web app that would use the SSH client directly, and it looks like those dlls just aren't getting packaged correctly in the installer. We'll put this on the list to fix.

ProGet does not support this for a variety of reasons, primarily security and support. Some users set-up a reverse proxy and rewrite urls, but we don't recommend it. Instead, please just use a different host name (Proget.mycompany.com) or port (mycompany.com:1000).

This is what Retention Policies are designed for, you can configure them to do this.

Hi Team, Thanks for all your support. I was clearing the temp cache for symbol server. Cleaning up a nuget cache fixes the problem for me. Thanks.