Thinking about your answer, i'm pretty sure that this is not a problem with the .Net API. I guess that is tightly related to the second question, I've filed here (see "USE ACCOUNTS FROM TRUSTED DOMAIN FOR RIGHTS ASSIGNMENT"). Whenever i open a browser on machine.dev.local and go to the ProGet Server (located in dev.local - see explanation of the infrastructure in above mentioned question), I'm authenticated as company\John (which is a user of a different domain but dev.local has a trust with company.com). As long as the ProGet implementation assumes the accounts used for authentication to be members of the domain where proget is located in (and i guess that's the case!), you will get null back from the .Net API. So for scenario like mine, this would fail (principal = null): var ctx = new PrincipalContext(ContextType.Domain); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); and this would work (principal has the expected value): var ctx = new PrincipalContext(ContextType.Domain, null, "company.com", @"AnAccountFromCompanyDomain", "TheAccountsPassword")); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); I guess you need, you just have to make the account domain configurable for cases, it differs from the domain where ProGet is located in and let the user apply credentials fro Account- Queries in the Account- Domain and then use the example above to query and you're done. Right? ;-) So big question for me now is if and when can i expect a version that supports our scenario. As i told Karl last week, we're looking for a commercial solution to replace our Inhouse- Solution to reduce our maintenance efforts for package management tools. Unfortunately we run out of time for the decision to go with an external tool or to keep our internal stuff running. Would be great to get some info about if and if yes, when we can expect a ProGet version that fits our needs. Best Regards, Joachim

After further investigation and help from support I found the issue. I am using the NuGet package and publish Visual Studio extension to create my NuGet packages. This is really just some MSBuild targets and supporting files that get included in your project/solution. What it does is use NuGet.exe to push the NuGet package and the symbols package. After further investigation (and help from ProGet support) I found that my packages were getting overwritten by the symbol packages. The reason for this is that NuGet.exe strips the symbols from the name of the NuGet package when it pushes. ProGet therefore has no way of knowing this is symbols package and since I have overwrite of packages enabled for the user that pushes the symbols package overwrote the primary package. The symbol package for obvious reasons only has the dll, pdb, and source files hence it looked like the content files were stripped. Since I didn't want to revamp my entire build process (it was already setup for about 30 projects across a number of solutions) I came up with an alternative approach. Since ProGet retains the symbols and source in the NuGet packages (it only strips them when they are downloaded) I created a separate feed for symbols and source (I named it SymbolsSource). This ends up working out beautifully. I push NuGet packages to Default and symbols to SymbolsSource and setup Visual Studio accordingly. I would like to give kudos to support for helping me out on this!

The "pre-release" conventions in NuGet is incredibly bizarre and changes from version to version. We do not recommend using it until they fix it. If you want all the packages to be pre-release, then you'll need to recreate all of the package files (name + nuspec file).

This problem is a pretty big deal - it means that existing TeamCity build artifacts can't be "pulled" into ProGet. The only way to make it work is for new build output, pushing nuget output to ProGet. That's suboptimal.

It's working for us too. Thanks!

Hi To recap for future reference. To push a package containing symbols and sourcecode the following has been tested and worked fine with nuget 2.8: Create nuget package using: nuget pack foo.csproj -Symbols Alternatively use: nuget pack foo.spec -Symbols The above command will create two nupkg. The one decorated with the word symbols does contain all libs as well as the sourcecode and PDB files. You cna check yourselfes by opening hte nupkg in something like winzip or 7zip, since the package is basically a zip file. Push the symbols package to proget. check the package on the feed. If the symbols server is activated the package info will show that symbols and source are available. Follow the Inedo guide on how to add The Proget symbol server support into Visual Studio. Food for thought. My, very quick test, shows me that a package build in the .NET 4.0 framework, of course works fine in a .NET 4.5 project, but i could not use the symbols to debug. I tried to remove the package, downgrade my test project to .NET 4.0 and reinstall the package. Now i could debug nicely into the source. Bottomline. The symbols package and the project that uses it must be on the same .NET version for the symbols to work. Symbols compatibility does, apparently, not span framework versions, even thou the frameworks themselves are backwards compatible. Thomas

I'm not using Windows authentication, so user rights aren't the issue. The very first thing I did was to simplify the password, and that didn't work either. I know that the connection string works, because both the web application and the service function fine. I ended up doing a manual install of 2.2.10 to get me up and running (I needed the fix for NuGet 2.8).

Hi, Thanks for the fix - I have tested in our environment and can now push with the nuget 2.8 client. Note: I did not test with the nuget 2.7 client Thanks again.

ProGet does not support being installed in a virtual directory; it must be at the site root.

I can't think of any tangible benefits to doing so, and can't think of any real drawbacks either. The only possible issue I could think of would be cookie related -- e.g. if you have the same hostname for both products differing only by port, there could possibly be conflicts with the cookie names. Using different hostnames would solve that, however.

Based on the error message and symptoms (it was working fine, until it wasn't), it would appear that the indexing error is from a poison package. We made the mistake of using Microsoft’s Packaging libraries (System.IO.Packaging) to open this package, and among many other bugs, it will produce an un-catchable exception (fun fact: if you happened to be on a non-english Locale, it will terminate the whole process with a stack overflow exception). We cannot work around this problem, but the bug appears to be fixed in .NET 4.5.1. If you upgrade to that, the error should go away.

@Tod,@Calvin I've tested it in 3.5.3 and it works now. Thanks!

Just go to Advanced Settings under Admin, change the UpdateCheck_Next value to an empty string, and click Save Changes. That should disable automatic update checking.

We don't, so that means probably in the next week or so; unfortunately this has not been a high-enough priority issue to trigger a maintenance release. Once we have that one, we can do another docker/linux build quite easily.

Great, thanks for your help !

I just noticed you actually have already released 2.2.5 I confirm that it does resolve our issue. Great support, thank you!

Feeds_DownloadPackage refers to a user downloading a package from the feed (via NuGet client, VS client, etc.) regardless if it's hosted locally or downloaded from a connector. Feeds_PullPackage refers to pulling a package down from a connected feed into the ProGet-hosted feed. There's a button that does this on the package details page.

Apologies for the delay, but as of v3.0.3, you can configure your feed so that the PDBs are not stripped out.

We managed to resolve this - it turns out that the proget feeds were being ignored because the version of proget was not compatible with NuGet 2.7.1. An update to the latest version of ProGet resolved the issue. Thanks for the response though! :)