That's a display issue in pgutil. It's not supposed to show the build number as part of the version at all, so we'll fix that. Note that we do include the build as part of the tag, but the actual release title on GitHub is just 2.1.1, 2.0.6, etc. Thanks for reporting this!

@atripp Thanks so much for the information

@rhessinger I added the requested info to the opened ticket. Best Regards, Pedro

Hi @dean-houston, thanks for the reply. That solved the problem. In addition I finally had to configure my Visual Studion correctly by adding /v3/index.json to the feed address. I had missed this for quite some time, unfortunately. Now everything is running fine. Best regards Uwe

Hi Alana. Thanks for your feedback. I will try it like that. Best regards Paddy

@jipianu_mihnea_1277 said in Creating Users with Native API: ant to use the Native API to create users and groups, but I do not know how to generate the password because I am unaware of th Thanks for the shout-out @atripp! Yes, you can do Set-ProGetUserPassword -Credential (Get-Credential) and supply the username of the account you with to set the password, as well as the new password. The New-ProGetUser function will do this internally for you when you pass in the credential object that function expects. If you run into trouble, please do file an issue so I can try to fix it!

@atripp , Guess you are right. thank you.

@layfield_8963 great news, that was a really strange error. The UI upload uses some kind of chunking and file appending, so it sounds like that was it.

Thanks for the reply, we on our end have to take a discussion and see if there is a budget increase option or if we just throttle traffic.

Hi @enrico-proget_8830, So we have fixed multiple issues with npm, specifically the npm connectors in the versions since you installed. I think upgrading to ProGet 2025.26 should resolve your issue with the ECONNRESET issue. Could you update to 2025.26 and rerun your test and let us know if you are still seeing the issue? Here is a link to the change list since your version of ProGet: https://my.inedo.com/downloads/upgrade?product=ProGet&fromVersion=2024.22 Thanks, Rich

@dan-brown_0128 thanks for clarifying 2500 is a lot more than I'm thinking... I was envisioning a handful of frequently-updated / highly-trusted packages (like AWSSDK, ). I think the UI would struggle a bit. Thinking about this further... a blanket "all future versions are OK" policy seems like it will cause more problems than benefits. That's a lot of decision-making burden to shift to developers, and they're just going to hit "update" the moment they're prompted. Best case scenario, that update delivers Zero Business Value... but there's a chance it'll introduce a regression, etc. I'd really need to study the data before recommending a practice like this (let adding a supported usecase for it) I'd be open to some sort of "automatic approval" feature, but I'd want to see some other factors in there, other than just "name matches X". As it stands, "package approval/promotion" isn't very widely used as it's solving a problem most organizations don't believe they have. Instead they drop $300K+ for Clownstrike or another security tool and believe it just "does everything for them". At that price, how could it not! So I think it's best to pin this for a bit. It's still a pretty "frontier" discussion/feature, and I don't want to "invent" something that's not going to get a lot of widespread use.

@stevedennis I understand not wanting to go in blind on something so low-level. For what it is worth, the monkey-patch I applied has been stable, so far, in my lab environment. Let me know if you need me to test a build, prior to Otter 2025.

Hi Dean, Setting RaftItemType_Code = 7 in this instance worked for me. Appreciate the list of valid types. Thanks for all of your help! Scott

Hi @steviecoaster, Thanks! We will take a look as soon as we can! Thanks, Rich

@kc_2466 thanks for the heads up, we'll target reviewing/fixing this for the following maintenance release (i.e. 2024.27 / Feb 21) via PG-2893

We've added both of these properties to the index - you should see them in this week's release of 2024.26 on Friday. Thanks for the feature request!

Hi @jimbobmcgee , Thanks for all the details; we plan to review/investigate this via OT-518 in an upcoming maintenance release, likely in the next few two-week cycles. -- Dean

Thanks Dean, that makes it clear for me.

@cooperje_6513 that error means that the Windows service account user does not have access to the SQL Server database; you'll want to grant NT AUTHORITY\NETWORK SERVICE access You can do this with SQL Server Management Studio, or a scritp like this should work: CREATE LOGIN [NT AUTHORITY\NETWORK SERVICE] FROM WINDOWS WITH DEFAULT_DATABASE=[ProGet] CREATE USER [NT AUTHORITY\NETWORK SERVICE] FOR LOGIN [NT AUTHORITY\NETWORK SERVICE] ALTER USER [NT AUTHORITY\NETWORK SERVICE] WITH DEFAULT_SCHEMA=[dbo] ALTER ROLE [ProGetUser_Role] ADD MEMBER [NT AUTHORITY\NETWORK SERVICE]

@dean-houston said in PSEval can be called as $PSEval, @PSEval or %PSEval, but null/empty returns only make sense for $PSEval: a variable prefix ($, @, %) is more of a convenience/convention, and the prefix isn't really available in any useful context. I'm almost certain you can do stuff like $MyVar = @(1,2,3) for example. For what it is worth, if this is the intent, then it does not match what actually occurs. The execution engine throws exceptions when you mismatch the variable types: # mixed sigils { set $ok = ""; set $no = ""; try { set $a = "blah"; set $ok = $ok: scalar; } catch { set $no = $no: scalar; force normal; } try { set $b = @(1,2,3); set $ok = $ok: vector-as-scalar; } catch { set $no = $no: vector-as-scalar; force normal; } try { set $c = %(a: 1, b: 2); set $ok = $ok: map-as-scalar; } catch { set $no = $no: map-as-scalar; force normal; } try { set @d = "blah"; set $ok = $ok: scalar-as-vector; } catch { set $no = $no: scalar-as-vector; force normal; } try { set @e = @(1,2,3); set $ok = $ok: vector; } catch { set $no = $no: vector; force normal; } try { set @f = %(a: 1, b: 2); set $ok = $ok: map-as-vector; } catch { set $no = $no: map-as-vector; force normal; } try { set %g = "blah"; set $ok = $ok: scalar-as-map; } catch { set $no = $no: scalar-as-map; force normal; } try { set %h = @(1,2,3); set $ok = $ok: vector-as-map; } catch { set $no = $no: vector-as-map; force normal; } try { set %i = %(a: 1, b: 2); set $ok = $ok: map; } catch { set $no = $no: map; force normal; } Log-Information Mixed sigils: success${ok}, fail${no}; } DEBUG: Beginning execution run... ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Vector value to a Scalar variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Map value to a Scalar variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Scalar value to a Vector variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Map value to a Vector variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Scalar value to a Map variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() ERROR: Unhandled exception: System.ArgumentException: Cannot assign a Vector value to a Map variable. at Inedo.ExecutionEngine.Executer.ExecuterThread.InitializeVariable(RuntimeVariableName name, RuntimeValue value, VariableAssignmentMode mode) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteAsync(AssignVariableStatement assignVariableStatement) at Inedo.ExecutionEngine.Executer.ExecuterThread.ExecuteNextAsync() INFO : Mixed sigils: success: scalar: vector: map, fail: vector-as-scalar: map-as-scalar: scalar-as-vector: map-as-vector: scalar-as-map: vector-as-map There are also syntax elements which require specific context, such as foreach requiring a @vec (Iteration source must be a vector value). I can certainly understand why you would not want to update the base classes so they provide the context (scalar, vector, map) to implementations but I expect it is probably the safest solution for maintaining backwards compatibility with existing authored scripts (if that information is available to you at parse-time). The alternative is to let the script author pass it along as an optional property to $PSEval() (similar to $GetVariableValue()), but this introduces another character which would then need to be escaped within the embedded Powershell (i.e. ,), and that probably would break authored scripts.