@rhessinger Thank you!

Hello; Thanks for reporting this bug/layout issue! I just made a simple change (PG-1956) to fix this, and it will be available in the next maintenance release (5.3.29)

Hi @flavio-campana_0936, BuildMaster 7 currently supports SDK 1.12. When running in Docker, it supports a minimum SDK of 1.9. On Windows, it supports a minimum SDK of 1.0. Thanks, Rich

@rhessinger Thanks

@joshuagilman_1054 that's really large chocolatey file (nuget package), so you may want to rethink your approach. It'll cause some pain across the board, as you try to download and install that file as well. Instead, perhaps have your chocolatey package download an asset that you've stored in ProGet instead? In general, large files are tricky to publish over a single HTTP request reliably. This is across the board, even when uploading files to places like Amazon S3; those rely on a chunked uploading process... but the NuGet API doesn't support that. Otherwise, there's no limit imposed by ProGet itself, and you've found the settings that ASP.NET imposes. There could be some other limitation happening, but it's hard to say where; apparently it varies by operating system version, and it might even be middleware (like a proxy/firewall). The message "there must be exactly one package" is unexpected; I would instead expect 'request length exceed". In any case, that message just means that no valid files were attached to the request, which can happen if it was suddenly cut off. All told, when it comes to really large files (even asset directories), a Drop Path approach may be easiest to use.

Hi @flavio-campana_0936, An ExecuteOperation is the most simple Operation class available. You just implement the ExecuteAsync method, and that code by the execution engine when the Operation is invoked in your OtterScript. This (and all operations) have a ExecuteCommandLineAsync helper method, which is sent to the server in context. To interact with the server in context, you need to use the Agent property on the executionContext that's passed into the ExecuteAsync method. Because there are a lot of agent types and versions (Inedo Agent, Inedo Agent on Linux, PowerShell Agent, SSH Agent, Local Agent, etc.), you can use the TryGetService method to see if the agent supports what you want to do. Not all agents support all services. I think you've already seen how this works. One of the agent services available is IRemoteJobExecuter. This essentially just performs a long-running task on the remote server, via the agent. For this service to be supported, the agent must support .NET; I think all agents do at this point (even SSH) thanks to .NET core. A RemoteJob is the class used to describe what this long-running task is. It contains information about what you want to do, has its own ExecuteAsync method that will run on the server, and can stream log messages back to BuildMaster/Otter. When defining a RemoteJob, you need to serialize/deserialize everything on your own. For example, if your job simply wanted to add two numbers together, you'd need to Serialize the two numbers, then Deserialize them, then serialize a response, and deserialize the response. It's a bit complex. This is where the RemoteExecutionOperation comes in. It has a "lifecycle"of three methods: BeforeRemoteExecuteAsync (optional, happens on BuildMaster/Otter server) RemoteExecuteAsync (required, executes on remote server) AfterRemoteExecuteAsync (optional, happens on BuildMaster/Otter server) Hope all this helps!

That message is basically a result of a bug in error-handling logic; basically, an error is occurring while displaying the error. This can happen due to certain IIS or server settings, and in later version, you should see a more appropriate message. It's hard to say what the problem is, but if you didn't change anything, I would just reboot, and the problem might go away. Changing App Pool settings can also help (like Classic -> Integrated or viceversa). You can also try upgrading to see the underlying message. v4.6 is pretty old anyways.

Hello, colleagues. Could you tell me: is something was changed in API in order to create a user with password? Regards, Roman

I created an account to +1 this issue. We recently upgraded to 5.3.24 and started seeing the same errors. Proget: 5.3.24 Category: Web Message: An error occurred in the web application: Invalid username or password. Details: URL: https://our-host/nuget/our-org/ Referrer: (not set) User: (unknown) User Agent: NuGet Command Line/5.8.1 (Microsoft Windows NT 10.0.19041.0) Stack trace: at Inedo.Web.InedoHttpModule.AuthenticateRequestAsync(HttpApplication app) at Inedo.Web.InedoHttpModule.ProcessBegin(Object sender, EventArgs e, AsyncCallback cb, Object extraData) at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) The worst part is the errors are not actually 'logged'. They are written to proget's database which only retains the last 1000 entries per category. Extremely hard to debug on our end.

Hi @Stephen-Schaff, I was finally able to recreate this error and I believe I fixed it in PG-1948. This is set to be released on Friday in ProGet 5.3.28. If you would like to apply the fix now, I have attached a SQL script to PG-1948 and you can run it against your ProGet database. If you run this script, it will not affect future upgrades of ProGet. Thanks, Rich

At the very least, a bulk operation would help.

@atripp said in [Otter 3] Upgrade Inedo Agent failed: m here, I recommend to just reinstall v49 on the serve Reinstall the v49 directly is working but as the config file move and its format change I have to modify my autoregistration deployment script Thanks for the reply

@apxltd Thank you, problem fixed

@ashah_4271 can you share your OtterScript? and show specifically what you'd like to do? Happy to help if we can!

@Stephen-Schaff let us know! If that works, then we can just inject that in the package, and read it in on the history page, similar to this NuGet package: https://proget.inedo.com/feeds/NuGetLibraries/Inedo.ExecutionEngine/100.1.1/history

Hi @Stephen-Schaff , Thanks for the suggestion! So we had considered the "auto-generated one-time key" in our initial design, but decided against it for several reasons. This enables the less-secure "API Key Spreadsheet Antipattern" - basically people want to store keys they generate -- and since the software doesn't allow it, they go this route. It's the same problem with "change your password every 30 days" policies that create easier-to-guess passwords. This tends to create a lot of stale keys due to a fear to delete them. Administrators can "back-up" the API Keys if they can see them, and add-them back if cleaning up causes a problem. Allowing keys to be entered allows users to more easily migrate from one instance to another - just do a DNS change, and all old automations /old keys will work fine. API Keys are similar to passwords, but different; passwords are entered by a human to log-in, and in theory should only be "in that human's head" -- where as API Keys are always entered somewhere (usually in a script). In general, in ProGet, we recommend keeping API Key as limited as possible. This simplifies things for everyone. There's no practical security problems in allowing all users to publish packages to feed.... you should be using package promotion to test/verify packages anyway.

Hi @Stephen-Schaff , We already have "Personal API Keys" coming, so I think this will address those concerns. The User Impersonation is really only used by the "Feed API" Endpoints anyways, and the only "problematic" endpoints might be "Feed Management API" (they could delete feeds) or "Native API" (they could do anything). Otherwise, I think this would best be handled by training and documentation. Perhaps just a warning to put on the Create API Key page? We've learned the hard way that advanced settings like this are really hard to support -- everyone forgets they exist (including support team). steve

Hi @atripp thank you for your fast fix! We just installed the version 5.3.27-rc.15 and will monitor the behaviour the next days. Greetings, Michael

Hi @Michael-poutre_3915, It's strange indeed. I wonder if it's related to a locally cached version you have? I can't seem to find any documentation, but I believe PowerShell expects to only receive the latest version available unless a specific version is specified(This is based on the fact that if more than one package is found, it errors). Looking further into ProGet returning two results, we see that it is returning the latest non local version as well as the latest local version. I think if ProGet were configured to only return the latest version that that would work better Behind the scenes, PowerShell is calling the FindPackagesById() NuGet API method which is supposed to return all versions. You should see almost identical results to: https://www.powershellgallery.com/api/v2/FindPackagesById()?id='ExchangeOnlineManagement' https://proget.company.com/nuget/PowerShell/FindPackagesById()?id='ExchangeOnlineManagement' You'll notice the same with InvokeBuild as well; all versions are returned from the API, as expected. So this is why I think there's multiple repositories (a local one?) or caching, or some other thing with the client. I know you can install a module locally, in powershell, by copying the module file to a directory? Sorry I'm not really good with degubbing the PowerShellGet client, but hopefully we can figure it out.... Cheers, Alana