You may want to check hte IIS error logs to see if anything pops-up; there is no additional configuration needed on the ProGet side (just run the installer), and it's most likely the case the request isn't even being routed to PorGet software. IIS has so many configuration options, that it's possible something was inadvertantly misconfigured at a root level. As an alternative, you can just use the Integrated Web Server, and then try to later upgrade to IIS once you get things working.

It's scheduled for release later today. in the mean time, you can use PowerShell or not set that particular property that requires a timespan.

Alana, I knew they are in the legacy side but I couldn't find a easy way to find/use them if I'm creating a new plan but I didn't think of creating a new legacy one then converting it later (firm smack to my forehead!) Thanks!

After upgrading both the ProGet VM and our (potentially underpowered) Active Directory VM to more cores/more RAM, we seem to have worked around the issue. Thanks for the tips!

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today. Thanks for the detailed report!

Well, there is literally no js error since the browser loads forever and never returns. There is also no logs in the admin section.

FYI - that's the "Operation" for our Otter product, but the BuildMaster Action works about the same... But in either case you will need to have an agent installed in order to stop the app pool on that server. Alternatively, you could use powershell script to do it, but that would require additional ports and the like be open on the remote server (RPC, maybe?)

FYI one of our developers posted an answer on the linked question.

Update! This has been fixed in ProGet 4.0.6

To migrate ProGet to a new server is as follows: If you're using a local database, back it up and restore it on the new server If you're using a local package store, copy those to the new server (ideally same exact path) Install the same version of ProGet on the new server, pointing to the new database Change whatever IIS settings you desire From the web app, edit whatever settings may have changed from the Admin section

This would be very easy to do with a PowerShell script, so as an immediate solution, I'd suggest to do that. It'd also be very easy to patch/modify that particular action (CreateIisAppPoolAction.cs) That being said, this all applies to the "v4 execution engine", which will very soon be replaced with an indescribably better execution engine (the one that Otter currently uses). When we migrate the "v4 App Pool Action" to the "v5 App Pool Operation", it will basically look like the Ensure-AppPool Operation. So, as you continue to explore BuildMaster, do keep this in mind :) If you're doing server/infrastructure configuration (which, creating applications is definitely a part of), I'd strongly recommend looking at Otter as well!

ProGet on IIS is only supported as a root level web site of IIS - it cannot be a virtual directory of another application. If this is not an option, you'll have to go with the built-in web server option.

Yes. Currently different versions of our websites get deployed to the server to a directory based on the version number. Was interested in just changing the directory the website was pointing at after the artifact was deployed. We currently do have a builds/deployments using a bunch of PowerShell scripting but it is getting challenging to maintain. Thanks for pointing out the Windows Extension.

Your best bet will be using either a Delete files action, or simply just the Transfer/Synchronize files action, along with some negative/exclusionary masks. For example... * !images !cache !web.config

If you're seeing this message, then you'll need to ensure ASP.NET4 is installed -- not just .NET4 and .NET4 Extensibility. It's a separate option (that's kinda hidden).

So upon doing a fiddler trace and seeing nothing coming through when I used nuget.exe against our internal repo, I tried it against nuget.org and lo and behold that failed too. It turns out for prior things I had HTTP_PROXY and HTTPS_PROXY environment variables set and nuget.exe didn't like it. This carried over to Visual Studio as well. After removing those variables everything started working again. So, sorry this wasn't ProGet at all (thankfully).

I had mistakenly stopped the ProGet service after I switched to IIS hosting mode, so that caused the problem.

yes I am in the right instance (we have only one proget) so we found out our proget had some issues with the db and can't show all package in the ui now we delete from proget and reinstall everything and reindexing all packages I think this will work

I just installed v 3.4.6 Build 6 and it is now working. I used SQL Express installer this time instead of connecting to a stand alone sql server. Not sure if that made any difference.

This error is related to the UploadReadAheadSize value that is configured in IIS. For IIS7+, see: http://www.iis.net/configreference/system.webserver/serverruntime For IIS6, see: http://msdn.microsoft.com/en-us/library/ms525310(v=vs.90).aspx