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).

Thanks for the heads up; the moment I saw this, I immediately responded. Now we're just waiting for responses on the other side of some corresponding questions. Again, thanks so much for the hand!

This is on our list to update eventually, but very low priority. If you need it right away, it might be easiest just to download the NuGet.Server package and extract the contents over the matching \bin DLLs of the v2.8.6 installation. Note that it requires .NET 4.6 (which you likely have already, but worth noting).

Thanks for your answer! We'll gladly wait for it and in the meantime keep using proget for our other sources. Thank you!

Unfortunately we don't have a good example case for this, because each scenario is kind of complicated. what's the best way to divide responsibility between the 'parent' and 'child' applications. Do I have to build the create releases for the child apps manually first and then have the parent look for those? You could certainly use the Create-release operation to create releases, but that may not be what you want. One factor to consider is, how different are each of these releases? Do you have a lto of variables you want to set? That will impact the ease of the interface you create. I'd like to have the parent orchestrate the whole thing to make the process easy for the operator (i.e. other team members) but I'm not sure I'm thinking of all of this correctly. For instance, I may only want to deploy 2 of the 5 child applications. If you only have 5 applications, then it's a lot different than 50 applications. One thing you could do, is five different variables (DeployApp1, DeployApp2, etc). You could also do a list variable that has all five of those in there. The more you generalize, the more complicated it gets... and with only five, maybe yo dont need to generalize that much. Just a thought, but one idea I have... You could write up your proposed-setup (and why you set it up this way), and we could review it. This could be something we do as a blog-post, so we could share it with others. Writing it up will help give you clarity on it as well.

There is a DoNotClearTarget option on the Deploy-Artifact operation that, I believe, will accomplish what you are looking for. We don't have masking (which would allow you to deploy only some files out of an artifact), but you certainly could deploy the artifact to the working directory, then copy or transfer files to the target.

Otter wouldn't be the right tool to track the why of those changes, but at a minimum, you could use a Git-based raft to track changes. But you'd certainly be better off bundling these changes, and running them through a pipeline that gives you approvals, visibility -- basically all the things you'll want when implementing an ITIL-based workflow. This is where a tool like BuildMaster would come in.

Please request a key at https://my.inedo.com/. No internet access is required; obviously you won't be able to connect to feeds hosted on the internet, like NuGet.org..

That actually worked out very well, thank you for the information. Looking forward to the next release.

Currently variables are not evaluated in pipelines. I'm not exactly sure on the pipelines/application setup you have, but you might be able to get away with using the Variable Value Promotion Requirement which forbids deployment past a certain stage if a Package Variable named IsReleased is not true. Combined with the Set-ReleaseVariable operation in the plan assigned to the release stage, you should be able achieve what you want, e.g.: Set-ReleaseVariable( Variable: IsReleased, Value: true, Release: $ReleaseNumber, Package: $PackageNumber );

I'm a bit of a loss, because we haven't seen such an error before... and it's not something that ProGet would be doing. You may have some IIS setting enabled, that's intercepting requests and ... doing "something" with them? It's really hard to say, because it simply doesn't make any sense, and the solution will not be found looking in ProGet settings/installation. Would suggest to use the integrated web server in this case. Or, use a fresh IIS installation.

There are some bugs using map variables within OtterScript in v5.5.3; these have since been resolved.

This is not a known issue with ProGet or our tools. But I'll note, there is a little bit of a "warm-up" time needed for .NET-based applications; it should be pretty quick (5-10 seconds), but it sounds like your server might be a bit underpowered? Or maybe there is some other thing preventing .NET applications from "warming up" in a fast enough time?