cc @smadam813
click here for bot help

I suggest trying to use app_parameters_free_form it seems to be more forgiving than app parameters.

Not really a fix but I have used win_ regedit to put the app parameters in place, then just used a minimal win_nssm configuration to set up the rest of the service.

Thanks, @jhawkesworth . I ended up doing that as a workaround. It seems the value of $appParameters in the function ParseAppParameters, is literally just 'System.Collections.Hashtable'. Subsequently, the ConvertFrom-StringData cmdlet is giving me the name=value error.

So I don't have this 100% working; it's just a matter of fine tuning the parameters for my specific application, but the app_parameters are now parsing.

Right out of the gate, this does not work in win_nssm.ps1 $appParameters = Get-AnsibleParam -obj $params -name "app_parameters" -type "str". I think the assumption here is that the value passed to $appParameters will be powershell code like @{ "key" = "value" }, but instead app_parameters is a hashtable and getting the string value of that is just the name of the type (which is useless).

So I changed the initial assignment of $appParameters from
$appParameters = Get-AnsibleParam -obj $params -name "app_parameters" -type "str"
to
$appParameters = $params.app_parameters

Because of this change, there is no point in parsing the app parameters, just use the hashtable directly. So I commented out:
$appParametersHash = ParseAppParameters -appParameters $appParameters
and changed $appParametersHash.GetEnumerator() to $appParameters.GetEnumerator()

Finally, I noticed an issue with the singleLineParams concatenation, where a subsequent key would follow directly after the previous value without a space. So I added a space after $val""
"$singleLineParams = $singleLineParams + "$key ""$val"" "

I'm awful at pull requests. If someone needs to me work on one I'll give it a try, but I'm hoping I provided enough info to fix the issues.

that's funny, I've used it extensively without problems (apart from the stuff fixed with free_form). I'll take a closer look at this. Thanks for the code, sohuld be quick enough to create a PR from it

Maybe Get-AnsibleParam changed? I'm sure the win_nssm.ps1 would work as-is if that cmdlet returned the app_parameters as @{ "key" = "value" } but all it's returning for me is System.Collections.Hashtable

Even with Get-AnsibleParam fixed, I still think the key/value concat needs to be fixed. It might work with some apps, but my scenario needs a space between switches.

Yeah it did change. optional parameter typing was added during 2.3. -type "str" must have been added erroneously.

Yup, looks like this commit may have changed too much stuff: ff1efb2#diff-5ba1945628b98dfd2ff1c1893772b39a
@dagwieers , care to have a look?

Right, the parameter became a string, and it should become a dictionary (with support for key=value in old syntax). Support for dictionaries is not implemented for Windows modules, it's on my list of things to do.

I will remove the -type "str" for this parameter. Sorry for the inconvenience.

So I fixed the app_parameters parameter in win_nssm, it now has -type="dict" which is unimplemented (so that is the same as before when it did not have that statement).

I noticed that dependencies is in fact a list, and we should probably simplify win_nssm to understand -type "list".

And more importantly, we should add integration tests making use of these options, so we can fail on regressions. See our plan at: https://public.etherpad-mozilla.org/p/Ansible_Windows_Community_Plan

The win_nssm module also lacks check-mode support.

Pretty sure we're talking about the same thing but just in case:
I've added a PR which adds a "psobject" to the list of possible param types. I've tested this against the win_nssm module and it works. imho, there are two "basic constructs" in Powershell objects: psobject and Hashtable. A hashtable is a key+value pair list, and a psobject is more akin to the python dict (its just an object with a random list of attributes). The reason I named it "psobject" is to make it easier for Powershell developers (ie non-python devs) to understand the model, as a "dict" is not well-known type in Powershell lingo. Open to suggestions.

I would make both one and the same thing. But I would not make it a PSObject. I dont't see a compelling reason (but could be persuaded).

My reasoning is the difference in how they are transformed into a string object (as win_nssm clearly shows, although I'll agree that the implementation is a bit clunky). A hashtable serialized into a string will simply be the string "System.Collections.Hashtable". A string-serialized psobject translates into something like "@{name=trond}" (for a psobject with a single "name" property). I'm pretty sure it would be a good idea to have "type parsers" for both types in powershell.ps1, but we should be careful to treat them as the same, because they're not.

@trondhindenes We will have to support what win_nssm supported earlier. (which is a YAML and a key=value pair if I understand it correctly). I still don't see what a PSObject brings us, so I would simply stick with -type="dict", but let's discuss it in a WWG meeting.

Totally agree. Just for clarity: If you supply a "key/value-type" parameter (as of Ansible 2.3.0) and don't specify the type with "Get-AnsibleParameter", then the resulting type is a Hashtable. Win_nssm expects a serialized psobject instead, which is why it's choking (and how Ansible was working prior to 2.3.0). One might argue that it would be better to refactor win_nssm (and I'm all for it), but in the meantime it's my opinion that we just need to get this working. I'm not sure if we're discussing the same thing, because like I mentioned above "dict" is really not a basic type available in PowerShell.
Short story, #25356 would allow us to:

1. get win_mssn working without a major refactor
2. Allow powershell devs to have a "psobject" type available without having to parse it inside each module needing it
3. Help Powershell devs by using "powershell lingo" instead of python-lingo. (If someone told me to create a "dict" before I started dabbling in python, I'd have no idea what that meant :-) )

Hi

I sort of think we need to have dict and psobject, and not just so there's something familiar for both 'people coming from powershell' and 'people coming from python'. Why? because they are (slightly) different things.

My understanding is that powershell hashtable is a basic key-value structure, with its main purpose being storing and retrieving values by their key as fast as possible. A psobject is a more object-oriented thing with at least 2 extra qualities that a raw hashtable (and I think a python dict) don't have.

The first thing you get with a psobject is ability to add methods into the object (not sure how useful that is in the context of ansible modules) and the second is optional ability to preserve the order in which keys were added. (Just to add yet another language to the table, this would be analogous to a java LinkedHashSet).

I think for win_nssm (as it stands) we need the insertion order preserved (otherwise those args could get deserialised in a random order).

If anyone has capacity for refactoring win_nssm I would do my best to review it.

@jhawkesworth Good point, we discussed it briefly yesterday, but I really wanted to defer a decision to the next meeting (which has more favorable hours for @trondhindenes and others).

Related to command-line arguments and preserved order, that is why for python lists are being used for the same purpose, or it remains a string (depending on the exact syntax). Although in theory you could use an OrderedDict, but that is not implemented as a type (I have a feature request open for this).

@jhawkesworth The name "dict" or "dictionaries" is not very specific to Python, it's been called associative array, hash, map (e.g. in YAML) or mappings, key-table, or tables and by Powershell hashtable. https://en.wikipedia.org/wiki/Associative_array

BTW If we plan to add ordered dictionaries, I would propose to call this type "omap" (YAML). And would then map exactly with the !!omap typing in YAML.

PS It makes more sense to me to migrate over time to the YAML type names, rather than the Python type names. A lot or similar, and we could add the YAML types http://yaml.org/type/ Maybe something to discuss on a Core meeting ?

Any chance this one will be fixed in 2.3?
I see different pull request on this matter but all of them for 2.4

At 19:00 UTC on Tuesday 19 September 2017 this ticket will be processed during the second Windows Sprint,
https://github.com/ansible/community/wiki/Windows:-sprints
we would appreciate if you could join the Sprint to help out with understanding/fixing/closing this issue.

Discussed at the sprint, @dagwieers will attempt to refactor this module.

cc @jborean93
click here for bot help

cc @themiwi
click here for bot help

cc @georgefrank @h0nIg
click here for bot help

cc @nitzmahone
click here for bot help

Ran into this problem in 2.5.5

I also encountered the same issue in version 2.5.4