Page 2 of 3

Re: 161 compile no longer working

Posted: Mon Apr 15, 2019 5:13 pm
by Lembasts
I am not dotsourcing but what do you mean by resolving scripts please?
And where do I find the encoding?
When I get a chance to reinstall 161 I will try the command line host.

Re: 161 compile no longer working

Posted: Mon Apr 15, 2019 5:28 pm
by Lembasts
So it appears to be parsing by 161. These are the errors when running the exe as command line:

Line 10499: At line:10498 char:3
+ {
+ ~
Missing closing '}' in statement block or type definition.

At line:10499 char:158
+ ... vertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force)
+ ~
The Try statement is missing its Catch or Finally block.

At line:10488 char:23
+ $buttonApply_Click = {
+ ~
Missing closing '}' in statement block or type definition.

At line:10337 char:1
+ {
+ ~
Missing closing '}' in statement block or type definition.

At line:10499 char:158
+ ... vertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force)
+ ~
Unexpected token ')' in expression or statement.

At line:10501 char:3
+ }
+ ~
Unexpected token '}' in expression or statement.

At line:10536 char:2
+ }
+ ~
Unexpected token '}' in expression or statement.

At line:13442 char:56
+ $errmsg = validate $textboxServiceCall.text "notempty;sdnumbe ...
+ ~
Missing closing ')' in expression.

At line:16489 char:27
+ $TypesData.add("Staff (+non DSTG)", ($usersenabled | where { ...
+ ~
Missing expression after unary operator '+'.

At line:16489 char:27
+ $TypesData.add("Staff (+non DSTG)", ($usersenabled | where { ...
+ ~~~
Unexpected token 'non' in expression or statement.

Not all parse errors were reported. Correct the reported errors and try again.

Re: 161 compile no longer working

Posted: Mon Apr 15, 2019 8:18 pm
by Lembasts
When I did an export to file, these are lines 10494 to 10504:
try
{
Set-ADAccountPassword –Identity $textboxUser.Tag.objectguid -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force)
Set-ADUser -Identity $textboxUser.Tag.objectguid -ChangePasswordAtLogon $true
}
catch
{
Write-ErrorLogs $_ "Cannot apply password to account [$($textboxUser.Tag.name)]"
$errorprovider1.SetError($buttonApply, 'Error in applying password information')
return
}
if that helps.

Re: 161 compile no longer working

Posted: Mon Apr 15, 2019 9:34 pm
by Alexander Riedel
The encoding is shown on the status bar. Clicking on it opens a menu that allows to change encoding.
PrimalScript and PowerShell Studio can resolve, include that is, any dot sourced files into the packaged executable.
Obviously if the encoding of dot sourced files and the main file differs, it can create problems. Hence my asking.

Neither 161, nor any previous build, will parse your code and output the errors you see, only PowerShell itself will ever parse your code and that is also where these error messages come from.
If you look at "vertTo-SecureString -AsPlainText "$($textboxpassword.text)" –Force" it would seem there is some problem in this section.
According to the code snippet that should be - (minus) as in -Force but is probably some other character.
I suggest to manually delete that character and replace with a proper '-' character.
It seems you pasted the code and when I look at the post above, the dash in front of 'Force' is visible longer than the one in front of 'AsPlainText' (at least on my screen)

I am at this time not certain why this has not caused a problem before, assuming that was there before, but it nonetheless appears not to be a proper parameter character.
Which leads me back to the encoding question. This is one thing we changed slightly to address another issue and maybe there was a conversion that previously fixed that problem without alerting to it.

I have not tested that yet, but it is quite possible that PowerShell itself has added code that corrects such characters when you run it as a script.

Re: 161 compile no longer working

Posted: Mon Apr 15, 2019 9:46 pm
by Lembasts
...and if you were wondering - I did a command line compile under 160 and it worked fine - no parsing errors.

Re: 161 compile no longer working

Posted: Mon Apr 15, 2019 10:16 pm
by Alexander Riedel
I wasn't really wondering :D I was pretty sure that was the case.

Re: 161 compile no longer working

Posted: Tue Apr 16, 2019 2:35 pm
by Lembasts
Very interesting. Obviously got away with it in the past.
The encoding is UTF-8-BOM.
I replaced the hyphen in front of the Force and Identity and compiled it and it worked fine!'
By the way I did a hex dump of the two characters:

- 0x2D 45
– 0x2013 8211

The first one is a normal hyphen and the second one is what was originally in front of Force - HTH

What should the normal encoding be? Should it be ASCII? I have no idea about those things.
And is there any way to search for non standard characters which is apparently what this Force 'hyphen' was?

Thanks for your efforts
Cheers
David

Re: 161 compile no longer working

Posted: Tue Apr 16, 2019 8:59 pm
by Lembasts
So I noticed that 160 doesnt have UTF-8-BOM. So I suspect that maybe my encoding prior to 161 was just UTF-8 and when 161 was installed it changed the encoding automatically to UTF-8-BOM which caused it to fail?

Re: 161 compile no longer working

Posted: Wed Apr 17, 2019 4:31 pm
by Lembasts
And I also noticed that a few fancy fonts that I was using, like old english, no longer displayed.
I'm thinking that the fact it appeared to change UTF-8 to UTF-8-BOM automatically after installing 161 was a bad move.

Re: 161 compile no longer working

Posted: Wed Apr 17, 2019 5:04 pm
by Lembasts
So Im going through and manually changing dozens of psf file encoding from UTF-8-BOM back to UTF-8.
I have some common files used in various projects.
What I noticed was that when I changed one of the common files to UTF-8, and then opened that same file in another project, the encoding said Windows-1252.