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

Hi Richard, Unfortunately it doesn't look like the exact error is being reported, but it definitely happening when the database schema is being initialized. Based on the error code, it looks like it's happening at the database driver level has something to do with updating the database schema. Perhaps there's an error connecting to the database, or something? Your best bet might be to tryagain, or use try the manual install process for the database.

Thank you for the kind words, PJ. No, LOCAL SYSTEM is not a requirement at all, and obviously not recommended for most installations (which is why it is not the default). If you had followed the instructions in the error message that you received, you would know that you could grant the user account hosting the web application the specific ability to control the service by selecting the AllowServiceControl menu option when running bmservice.exe. I've also gone ahead and censored the email address that was entered into the public-facing "Name" field to prevent spam bots from scraping it.

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

It sounds like the files are being marked read-only from the source checkout; I would try to use the Set File Attributes action, and set read only = off.

This is caused when BuildMaster cannot determine the CPU ID or MAC address of the server it is installed on. Here is a detailed description: http://inedo.com/support/kb/1005/this-machine-cannot-be-uniquely-identified Typically, restarting the server fixes this problem. If that still doesn't work, you can also try the following steps to resolve: Stop the Windows Management Instrumentation service. Go to the %SystemRoot%\System32\Wbem\Repository folder. Delete all of the files that are in the %SystemRoot%\System32\Wbem\Repository folder. Restart the computer. The files that were deleted are recreated when the computer restarts. The Windows Management Instrumentation service will start automatically when you restart the computer. (These steps were taken from: http://minasi.com/forum/topic.asp?TOPIC_ID=5772)

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.

Hey Tod, Its when we execute the workflow, it hungs after the execution is started. the very first step after it starts, still I kept the work flow going on.. and it took 208mins to execute all the steps which generally shall take not more than 2mins... A simple app pool recycle on the target system takes more than 30mins. I verified the communication with the target system and the agent .. they are working fine... the ports and communication between both the servers is good did the telnet and its responding... I can transfer the data between both the servers using normal copy within seconds... so no network issues. I can see the agents as ready for the target system.

Great, thanks for your help !

Hello Please ignore my question. The downloaded nupkg file was faulted. Thanks

If you look in the Service subdirectory of the BuildMaster installation, you'll find BuildMaster.Configuration.AdminTool.exe which can clear the set of licensed users. Since licensed users are added back as soon as they log in, that should be all you need.

See Q&A 947. This will be fixed in 3.7.1; but a patch is available. Just email support - at- inedo - dot - com, and we'll send it over. In the mean time, I've emailed you the patch.

This message is coming from an IIS-hosted agent, and means that the agent is misconfigured in IIS - perhaps this is pointing to a different host name, has proxy issues, etc. Perhaps try the self-hosted agent instead.

Thanks for the update; we do have a work item (PG-130) for improving indexing of .pdb/source on large packages. This will come in a future version, hopefully soon.

We actually have two use cases for delete: maintenance scripts (we have beta packages published for each commit so we need to perform periodically cleanup) automatic validation of new ProGet releases (so we can quickly "validate" a new release before move it into production) I know they aren't common use cases but it will be useful.

Does this happen with all packages, or just one package? Can you try pulling a package to the feed (like JQuery), and then deleting it? Can you disable friendly error messages (webCustomErrors=off in advanced config), and post stack trace?

I am sorry. The package that still caused problems had a version number like 3.40.0000.0. This seems to bother a nuget 2.7 client, but not a nuget 2.6 client. The problem disappeared when rebuilding the package using the 3.40.0.0 version number.

This will be fixed in 3.7.1; but a patch is available for those on 3.7.0. Just email support - at- inedo - dot - com, and we'll send it over.

Wow! Talk about agile, thank you for the quick turn around.

Hello, We've identified a bug that's causing this.... it will be fixed in ProGet 2.1.3. In the meantime, if you email support at inedo.com, we will send a patch to resolve this. Thanks, Steve