This seems to be fixed as of the Docker image containing ProGet Version 4.7.14. The Docker image hash is: b7a3d6595c21d34997b4cbe6da9187801f410f17bff8e84228711bf29396a6ab pulled on 9/6/2017

Hi, Krzysztof G., did you ever managed to integrate both Octopus and ProGet? Using just the ProGet URL we can "connect" but it replies with an empty list. Is there anything else needed? Maybe a registry path?

You can download Romp Milestone 1 here! Awesome to hear you're excited about Romp! Cheers!

This was a regression: https://inedo.myjetbrains.com/youtrack/issue/PG-1085 We will have a maintenance release out today to fix this.

Hi Tod That is great news +1 Thanks for the very fast reply and hotfix release, which i look forward to. For now we have stabilised by loading a backup of our Proget server, rolling back to 4.6.7 so we are good for now :-D Regards Thomas

I don't believe the NPM protocol allows for anonymous pushes. You could certainly have your CI put it in a drop folder however, which the ProGet would pick-up.

This is definitely on our roadmap; stay tuned!

This is the first request for such a feature; after v5 ships, we may consider putting this on the roadmap as a feature, depending on if anyone else requests it. These sorts of features may not be worth doing, because they are added complexity, more things to test, and only save a little bit of time during initial set-up.

I mean to add, I do have a Timeout set of 15 minutes which I would have thought would be long enough. I am bumping the timeout to 30 minutes. However, I was just looking to see if anyone else had run into issues with Symantec and/or Windows 2012r2 with artifact deployments.

It installs SQL just fine. perhaps this would help. POST http://inedo.com/proget/activation/request-key HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: inedo.com Content-Length: 80 Connection: Keep-Alive it then has a body containing the fields email fullname trial version

You can use your same license key in this case, it's no problem! The licensing agreement for BuildMaster and Otter explicitly permit dedicated dev/test instances. ProGet requires a separate server... but if it's just a temporary migration then it's also OK too.

Good to know as well on this side. Now I know how not to have configuration errors drive me nuts. Now I just have to figure out how I'm going to do this ... Looks like my network will need two ProGet servers ...

I heard from another user who was experiencing exactly the same issue. The solution they found was to switch otter’s IIS Application Pool to Classic Pipeline (instead of Integrated). Of course it should work in both, but for whatever reason, it didn't here. So maybe it will help you as well!

Hi Matt, If it's not too much trouble, what time did the executions start in the stage that unexpectedly succeeded? It should say in the Deployments section of the package page. (I'm mainly wondering if they started on the same second or on different seconds.)

Looks like the database table NuGetPackageSymbols got corrupted somehow. After restoring it started working as expected.

There's an ongoing thread here; http://inedo.com/support/questions/6445. We still haven't researched it, but it would come after 5.0 (which we are planning to release in Q4).

Thanks Ben! it works now

Surfing Pikachu, That was one of the steps I mentioned in my original post. Did not work for this issue. Alana, Already attached Fiddler before original post. Just showed 404's for symbol requests. Downloading the package locally allows the symbols to be found; but using ProGet's symbol server doesn't work.

The best work-around for this is to create as secondary IIS site that points to the same root, and then configure no Windows Auth on that site. You will need to have two proget urls; one with WIA and one without. Unfortunately there is no other workaround, as NPM simply doesn'ts upport it, and IIS doesn't support having some parts of the site use WIA, and others not.

Hello Jason, I've filed [BM-3081], which will allow you to do this: foreach $ConnectionName in @DatabaseConnectionsInEnvironment($EnvironmentName) { Execute-ChangeScripts ( Connection: $ConnectionName ); } The default value for environmentName is the current environment ($EnvironmentName), so you can also just call @DatabaseConnectionsInEnvironment() with no argument (once this is released).