Tod's answer gave me something to look for. The IIS 7.5 did not have ISAPI enabled so after doing that the proget site worked as a charm. Definitely something that is missing in the documentation! For further reference see below: To enable ISAPI in the IIS look here: http://www.iis.net/configreference/system.webserver/security/isapicgirestriction at the part Setup The <isapiCgiRestriction> collection is available only after you install the CGI or ISAPI Extensions modules on your IIS 7 server. You cannot install it independent of those features. WINDOWS SERVER 2008 OR WINDOWS SERVER 2008 R2 On the taskbar, click Start, point to Administrative Tools, and then click Server Manager. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS). In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services. On the Select Role Services page of the Add Role Services Wizard, select CGI or ISAPI Extensions. If the Add role services dialog appears, click Add Required Role Services. (This page appears only if you have not already installed any prerequisite role services on your server.) On the Select Role Services page, click Next. On the Confirm Installation Selections page, click Install. On the Results page, click Close. After doing that i restarted and did not have to any further setup. Loading the site just worked. Inedo should make it much clearer in the documentation that this must be installed in the IIS for proget to work. Just setting the App Pool to Classic is not enough. Thomas

There is no way to tell from that error alone what the problem is. Some questions to help troubleshoot: is the other feed also a ProGet feed, or some other type of a feed? Can you actually browse to and get packages from that other feed? Can you connect to the NuGet.org feed from the feed that current has the broken connector?

In this case, you should install ProGet to IIS (it's an option in the installer), and configure SSL from there.

Are you still experiencing this problem? The ProGet service is very lightweight and should startup almost instantly, though it's possible that the database connection is what's taking the time. Could you try running the ProGet service interactively? (Make sure to stop the service and run the ProGet.Service.exe executable) This will give instant logging feedback and detail any errors or connection slowness as it happens.

Setting up ProGet in what is essentially a load balanced environment is detailed here: http://inedo.com/support/kb/1073/load-balanced-and-high-availability-installation-of-proget. Note that this type of setup requires at least 2 ProGet Enterprise licenses (one for each server node). That being said, ProGet itself does not handle synchronization in the manner you described and symbol/source serving is not designed to work for connected feeds. If you wanted to sync ProGet servers manually, all you need to do is copy the packages on disk from one feed to the other.

To install ProGet, you must be an administrator and have db_owner privileges against the target database.

I will copy my answer to another question "PROGET ALLOWS LOGIN ONCE USING LDAP AUTH, THEN CRASHES UNTIL IISRESET" here since i'm pretty sure they're tightly related: --- snip ----------------------------------------------------------------- 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 --- snap -----------------------------------------------------------------

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!