I am using a local nuget server, (built according to your directions on the website) to download my deployable packages, But the download gets a 404 even though the testing the repository shows the package.
the log appears to show that it can find the log but cant download :
2013-06-07 18:30:42 DEBUG Found package SQLDashboard version 1.0.0.1
2013-06-07 18:30:42 DEBUG Downloading to: D:\Octopus\Data\PackageCache\feeds-1\SQLDashboard.1.0.0.1_678C3C297C0692489E1D93763517625E.nupkg
2013-06-07 18:30:42 ERROR Unable to download package: The remote server returned an error: (404) Not Found. System.Net.WebException: The remote server returned an error: (404) Not Found.
at System.Net.HttpWebRequest.GetResponse()
I had the same problem with a package called App_Data. Changing the name to AppData resolved the issue. Hopefully that sheds a little light on the problem.
I created a new empty c# website in Visual Studio as instructed, Added in through the Package manager the Nuget.Server. and deployed. (this was on Thursday, so whichever version was available on Thursday). The Nuget Server site is deployed on a port (:8040) on the general web server.
Can you log in to the server that Octopus is running on, open a web browser, and browse to:
http://your-nuget-server:8040/api/v2/Packages
You should see some XML (you may need to use ‘view source’ in your browser to see it) containing a list of the packages in your NuGet server. Inside the XML there will be a <content> element with a link, e.g.:
<content .... src="http://......" />
If you follow that source link, do you also get the 404 error?
OK, this seems like a problem with your IIS configuration or NuGet.Server. Can you check your IIS features list and see whether ‘Static content’ is installed? The IIS server may be refusing to serve the file.
staticContent is allowed on the server and the web.config has the nupkg mime type installed.
three are no firewall rules, I have opened that port outbound.
the problem is that the /API/V2/package folder is not present and returns 404 when I try to browse to it.
is that served by a handler? there is not handler mapping for nupkg files in the web.config.
OK
If I cant get an answer for this, I will have to forgo the use of Octopus for our program.
I am going to have to find another deployment system.
I would prefer no to do that, but this problem is stopping us from proceeding with Octopus.
Please respond.
Since it’s happening in your web browser the problem seems to be with NuGet.Server, and I’m guessing an incompatibility with how IIS is configured. Do the following links shed any light on a solution?
If we can’t get to the bottom of it I’d suggest looking at an alternative server such as NuGet.Lucene (which is also much faster) or using the NuGet gallery:
I kind of have this working
There were a couple of things going on here…
I looked at the second link you gave me and changed the App Pool to Integrated Mode.
In order for that to work, I needed to run APPCMD to upgrade/ enable the System.webserver. Mandlers and Modules sections which were missing in the Web.Config created by the Nuget.Server build.
Now When I browsed to API/V2/Package I was getting a server error (500) that the website could not load the web.config or find the folder at D:\Packages.
I don’t know where the expectation of that folder comes from.
I can find nowhere any configuration data or settings that have that location.
But it seemed kind of obvious what I could do, so I created a D:\Packages folder and moved my repository to point there, adding a Vdir under the nugetstore site at :8040 for that location.
So now it downloads.
I would still prefer to be able to use my own repository location. Do you have any Idea why Nuget.Server wants to use that package repository?
So now I am having a problem. the package is downloaded and unpacked.
but the tentacle server cant seem to update the IIS…
2013-06-21 19:39:21 INFO [IIS] Updating IIS website named 'http://isbuilda01.pc.factset.com/SQLDashboard’
2013-06-21 19:39:22 WARN [IIS] Could not find an IIS website or virtual directory named ‘http://isbuilda01.pc.factset.com/SQLDashboard’ on the local machine. If you expected Octopus to update this for you, you should create the site and/or virtual directory manually. Otherwise you can ignore this message.
2013-06-21 19:39:22 DEBUG Storing a record of the deployment.
SQLDashboard is an IIS Application under the :80 port and is currently directed at old code. I want this App folder to go to the unpack location