Fixes for param validation, forwarding, and exit behavior - #265
Conversation
| [Parameter(Mandatory=$false, ParameterSetName = "SearchPath")] | ||
| [Parameter(Mandatory=$false, ParameterSetName = "SearchPathAndProjectManifest")] | ||
| [uint]$SearchDepth = 3 | ||
| ) |
There was a problem hiding this comment.
I'm not familiar with these validation attributes. Since we're moving towards the use of either a $ProjectManifestPath OR $SearchPath + $SearchDepth I am assuming that you can create different validation rules for different Parameter sets?
Does this set of rules express that if $ProjectManifest is provided, then $SearchPath and $SearchDepth become mandatory (depth optional), while if the search parameters are provided, the manifest parameter must be null?
There was a problem hiding this comment.
Currently what I have requires that you specify either ProjectManifestPath or SearchPath or both, and it ensures that you cannot pass SearchDepth unless SearchPath is provided. The logic seemed to be that both was allowed, but we can make it be strict 'or' if that's the behavior we want.
Michael Smith (Exolun)
left a comment
There was a problem hiding this comment.
Look like good fixes, I think these are okay to merge - I have a test script that I use to validate changes, but given the new parameterset validations I think I will also test some possible parameter combinations.
AzureSubscriptionto support use ofguidPATLifetimeandSearchDepthtouintto enforce valid rangeProjectManifestPathorSearchPathor both to be provided via parameter set name groupings.SearchDepthifSearchPathis provided.ProjectManifestPathis a valid file in aValidateScriptattribute.ProjectManifestPathwas used as the search path ifSearchPathwas provided.SearchPathvalue was previously unused...