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?

You can just back-up the database, and then restore it in the new SQL Server.

Hello Tom, You are correct that this is caused by the npm feed type not being found. I've filed this as PG-1073 and submitted a fix for review, so it should be fixed in the next version of ProGet.

Hello Srinivas, The Push to ProGet extension is specifically for Universal feeds. That error message appears to be coming from a NuGet feed. You can use a generic NuGet Visual Studio plugin to push to a NuGet feed on ProGet.

Oh god, worked ! Thanks a lot ! Would be super great if there could be a message or a log that says why the operation ended in a brutal closure of the program ;) Just a last remark: I may be wrong but it looks like you did not generate the "Full installer build" since a long time ago. If you look at the download page (http://inedo.com/proget/versions), event if full and small installer links do not lead to the same endpoint, the download size is the same wherever you click. It looks like the small version is deployed on all the endpoints. Thanks again for your help ;)

Thank you for the report - this issue (BM-2370) was fixed in a later version.

Hello I installed it using your integrated database installation.

Great! Thanks for the update Ben.

Tagging would indeed be the solution, now it's clear how we should have been working. Thanks for the fast feedback!