Initial creation of paket.config produces malformed file

[jdpage]

Description

Running paket config add-credentials with no existing paket.config file produces a malformed paket.config file (encoding in XML header does not match actual file encoding) which subsequently cannot be read in by paket. Seems to be related to #1954

Repro steps

1. Delete (or otherwise remove) your paket.config file
2. Use paket config add-credentials <somedomain> to add to the credential store
3. Run some paket command that hits the NuGet server (e.g. paket update)

Environment: Windows 10 Pro, 64-bit, paket 3.26.3 (also seen in 3.23.2).

Expected behavior

Command run in step 2 creates valid paket.config file; command run in step 3 uses the credentials entered in step 2.

Actual behavior

Command run in step 2 writes out a UTF-8 encoded paket.config file, but the <?xml ... ?> declaration at the top specifies it to be UTF-16. Command in step 3 is unable to read the file and exits with an error.

Known workarounds

Edit the paket.config file after creation so that the <?xml ... ?> declaration specifies UTF-8, or have an existing valid paket.config file.

[forki]

@yannisgu IIRC the config feature was your contribution. Are you up for taking a look at this? thx

[yannisgu]

@forki, no time right now - maybe @adamralph which possibly "introduced" the bug in #1954?

[adamralph]

I did draw attention (twice) to the addition of the header, but no one seemed to care.

[forki]

yeah I got, but I didn't see that it will result in issue ;-)

[adamralph]

I guess what probably needs to happen is the addition of overloads for both normalizeXml and saveFile with an encoding parameter, so that saveConfigNode can explicitly dictate the encoding to both.

[adamralph]

(If overloads are even a thing in F# - this is where my F# knowledge fails me and prohibits me from sending a no-brainer PR.) 😄

[adamralph]

Or perhaps normalizeXml should be changed to omit the encoding from the header?

[forki]

why is it specifying UTF-16?

[forki]

what do you guys think about d1d06b7 ?

[adamralph]

I guess that would work too

[jdpage]

Doesn't System.Xml.XmlWriter handle formatting and XML declarations and formatting and stuff properly for you? Going through that is probably safer than just assuming the file encoding.

If nobody minds I can author a pull request that uses that API instead, which should head off any possible future encoding-related problems.

[forki]

Sure you can try that.

Am 08.11.2016 2:39 vorm. schrieb "Jonathan David Page" <
notifications@github.com>:

Doesn't System.Xml.XmlWriter handle formatting and XML declarations and
formatting and stuff properly for you? Going through that is probably safer
than just assuming the file encoding.

If nobody minds I can author a pull request that uses that API instead,
which should head off any future encoding-related problems.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2003 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNI0r77lx7AfWs2BgBCruVMniHqRFks5q79LWgaJpZM4Ko3y2
.

[jbaehr]

Apparently, d1d06b7 does not fix the problem in all cases. I've got a machine here where paket hasn't been ever used; running v3.30.2. When I first run paket config add-credentaials https://...... I still get the "UTF-16" processing instruction in the config file. Any later call to paket fails with "Unable to parse Paket configuration from packages.config." (Note: wrong file name here; shuold be "paket.config"). When I delete the file (letting the parent folder in place) and run paket config add-credentials ... again, I get the correct file and paket works as expected after wards.

[jdpage]

Finally got a chance to come back around and do the System.Xml.XmlWriter version.