XML file corrupted message **SOLVED**

[WebMaximus]

After applying the latest hotfix from LM (2.5.12945.0) I noticed how the Addon Manger entry in the Addon menu was missing so I decided to re-download the latest version of the Addon Manager and install it but resultet in the following error message.

https://dl.dropboxusercontent.com/u/94801887/FSDT%20Addon%20Manager%20installation%20error.JPG

[virtuali]

Your error message has been already discussed here:

http://www.fsdreamteam.com/forum/index.php/topic,11473.msg88386.html#msg88386

Since these reports of corrupted XML files are coming with an increased frequency, it's very likely that's another product that has been recently released must have a defective installer somehow, which is changing the file encoding of the default XML files.

The Addon Manager installer is only reporting the issue, because it first ask to Windows to check the legality of the XML files before trying to do any changes to it.

[WebMaximus]

Interesting, will give it another try after first re-saving the file in ANSI format.

Would of course be great if we could find out what other addon is responsible so we can alert the developer.

[WebMaximus]

Re-saving into ANSI did the trick so that's great!

What about the dll.xml file, what's the correct encoding for that one...ANSI as well or UTF-8?

[virtuali]

What about the dll.xml file, what's the correct encoding for that one...ANSI as well or UTF-8?

The encoding can be any legal one, but it's important the actual encoding AGREES with the XML file header, which is the first line of the file. This is how it looks like on any default FSX/P3D install:

<?xml version="1.0" encoding="windows-1252"?>

This means, the XML file itself is telling to Windows that it has been encoded in ASCII using the Windows-1252 Codepage, also referenced as Latin 1.

Now, since the header is saying that, if an installer CHANGES the *actual* encoding to something else, like UTF-8 for example, it MUST also change the header too, otherwise any official parser that will respect the XML standard, will report this as an error.

I cannot see why an installer would want to change the encoding, unless it was trying to install into a pathname containing non-Latin characters (that's the only place the encoding might matter, since the name of the addon is not displayed anywhere in FSX), so the most likely explanation is just a mistake because, if it really had the need to do this, it should have changed the file header too.

Of course, another possible cause of this issue, is user editing without taking care of the issue but, since we got several reports in the last few days, it looks like to be more of a problem caused by some kind of rogue installer that has been released recently.

[WebMaximus]

I think I found the culprit yesterday but doesn't feel right to "hang out" another developer's product in here. I've reported my findings and I'm still waiting for an answer.

Anyway for now good for anyone who experience this issue to know it's easy to fix by simply re-saving the file in ANSI encoding/format before doing the Addon Manager installation or any other addon for that matter that does changes to the exe.xml file and/or dll.xml file.

[WebMaximus]

Looking at my dll.xml file I noticed how that one don't have the encoding in the header. Does that mean my dll.xml file is corrupt or maybe that file for some reason don't have the encoding in the header like the exe.xml file?

This leads me to another question, if the header don't have to include the encoding would that mean that if the encoding isn't included in the header you can save the file using any encoding without upsetting any installation programs?

[virtuali]

Looking at my dll.xml file I noticed how that one don't have the encoding in the header. Does that mean my dll.xml file is corrupt or maybe that file for some reason don't have the encoding in the header like the exe.xml file?

After your previous reply, I made a test and purposely changed the encoding to UTF-8, but left the header to be Windows-1252, and run the GSX installer. AND IT WORKED, no errors.

This means, just having the actual file encoding not agreeing with the XML header is not enough to generate the error, the MS XML parser we use can still handle this situation.

This leads me to another question, if the header don't have to include the encoding would that mean that if the encoding isn't included in the header you can save the file using any encoding without upsetting any installation programs?

Per XML specifications, the "encoding" parameter is mandatory, if the actual file encoding is anything other than UTF-8 or UTF-16. Which means, if there's no header, and the file is encoded in UTF-8 or UTF-16, the XML is legal. If there's no header, but the file is encoded in ASCII/ANSI, the file is outside the official XML specifications.

If you have a look at the XML sample files provided with the FSX SDK, they ALL include the line with the header specified as Windows-1252, and that's how FSX is installed by default.

However, I made other tests, in all these situations:

- Removed the header and saved the file as UTF-8. Ran the GSX installer, no error, and the default Windows 1252 header was put back.

- Removed the header and save the file as ASCII. Ran the GSX installer, no error, same as above.

Which seems to indicate even these not entirely legal situations are all handled correctly, so it seems your original XML had OTHER problems too, in addition to missing the header.

[WebMaximus]

Wow, this is getting a bit confusing 

This is what my exe.xml file looks like in original and which will have the Addon Manager installation generate the error message. This file is encoded using UTF-8. If I however start by re-saving the file using ANSI encoding before starting the Addon Manager installation it will go through successfully.

Code: [Select]

<?xml version="1.0" encoding="windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
  <Descr>Launch</Descr>
  <Filename>exe.xml</Filename>
  <Disabled>False</Disabled>
  <Launch.ManualLoad>False</Launch.ManualLoad>
  <Launch.Addon>
    <Name>Couatl</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>fsdreamteam\couatl\couatl.exe</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>as_btstrp_config_manager</Name>
    <Disabled>False</Disabled>
    <Path>as_srv\as_btstrp_config_manager.exe</Path>
  </Launch.Addon>
</SimBase.Document>
And this is what my dll.xml file looks like and as you can see the header is missing the encoding information and this file too encoded in UTF-8 unless I manually re-save it using ANSI encoding instead.

Code: [Select]

<?xml version="1.0"?>
<SimBase.Document Type="Launch" version="1,0">
  <Descr>Launch</Descr>
  <Filename>dll.xml</Filename>
  <Disabled>False</Disabled>
  <Launch.ManualLoad>False</Launch.ManualLoad>
  <Launch.Addon>
    <Name>Migration Tool Plugin</Name>
    <Path>MigTool.dll</Path>
    <DllStartName>module_init</DllStartName>
    <DllStopName>module_deinit</DllStopName>
  </Launch.Addon>
  <Launch.Addon>
    <Name>Addon Manager</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>bglmanx.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>ObjectFlow</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>P:\Program Files (x86)\Lockheed Martin\Prepar3D v2\ORBX\FTX_AU\FTXAA_ORBXLIBS\Scenery\ObjectFlow_P3D.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>PMDG HUD interface</Name>
    <Disabled>False</Disabled>
    <Path>PMDG\DLLs\PMDG_HUD_interface.dll</Path>
    <DllStartName>module_init</DllStartName>
    <DllStopName>module_deinit</DllStopName>
  </Launch.Addon>
  <Launch.Addon>
    <Name>VAInterface</Name>
    <Disabled>False</Disabled>
    <Path>Modules\VAInterface.dll</Path>
    <DllStartName>module_init</DllStartName>
    <DllStopName>module_deinit</DllStopName>
  </Launch.Addon>
  <Launch.Addon>
    <Name>FSUIPC 4</Name>
    <Disabled>False</Disabled>
    <Path>Modules\FSUIPC4.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>as_connect</Name>
    <Disabled>False</Disabled>
    <Path>as_srv\as_btstrp.dll</Path>
  </Launch.Addon>
</SimBase.Document>

[virtuali]

As I've said in my previous message, I already tested with the Windows-1252 header and the file encoded in UTF-8, and I can install GSX just fine so, there must be something else.

But you shouldn't post your XML files as forum message, because in the forum software will act on the encoding so, it's no use for me to test with your files when copying them from the forum, because everything might change.

ZIP both files, and attach it, so I can check them as they are.

[WebMaximus]

I believe you but fact remains when I try to install the Standalone Addon Manager and without first re-saving the exe.xml file using ANSI-encoding I get the error message. You said you're able to install GSX but I'm not installing GSX but the Standalone Addon Manager, not sure if that's of importance here.

Also remember I'm using P3Dv2.5 and not FSX.

Anyway, attached are my exe.xml and dll.xml files but since I'm able to install Standalone Addon Manager just fine as long as I first re-save the exe.xml file this really isn't a big issue so don't invest too much time into it.

[virtuali]

Anyway, attached are my exe.xml and dll.xml files but since I'm able to install Standalone Addon Manager just fine as long as I first re-save the exe.xml file this really isn't a big issue so don't invest too much time into it.

You only sent the versions encoded in ANSI which, according to your report, are those that works. I would need the "before" version, the one encoded in UTF-8 that gives you the error.

[virtuali]

You said you're able to install GSX but I'm not installing GSX but the Standalone Addon Manager, not sure if that's of importance here.

There's no difference, that part of the installer is 100% identical, and it hasn't changed in years.

Also remember I'm using P3Dv2.5 and not FSX.

That's not an issue either. XML handling is exactly the same. And the sample XML files in the P3D included with the official SDK are encoded as ANSI, with a Windows 1252 header, same as FSX.

[WebMaximus]

Oups. sorry - here are the files again now in UTF-8 format/encoding...and at this time I think the troubleshooting might be easier if I tell you what will re-encode the files...this happens as soon as I launch Active Sky Next.

Doing that will immediately change both the dll.xml and exe.xml files into UTF-8 encoding and if I at that point launch the Addon Manager installation program it will fail in the way described above and will continue to do so until I manually re-save the files into ANSI encoding. Not sure if I need to re-save dll.xml but I'm sure about the exe.xml file and that is also the file the error message is referring to.

[virtuali]

Ok, now I had the error too so, it wasn't enough to save the file in UTF-8, it was the BOM ( Byte Order Mark ), which are the first 3 bytes that you don't see if you open it with Notepad, for example.

So yes, this case of an UTF-8 file with a BOM at the start, but with an header that says "Windows-1252", which means ANSI, is what makes the MS XML parser we use for the installer to complain with an error. And rightly so, I'd say...that XML file is basically lying about itself...

I cannot see any reason why the Active Sky Next program would need to change the encoding of the file to UTF-8 (and why when launching the program, the XML file should only be used by installers ), because I cannot see the need to use non-Latin characters in their pathnames or product names in the file.

But even if they *had* a good reason to do so, they SHOULD have changed the header too.

If you change the header, and REMOVE the encoding="windows-1252" parameter, it WORKS with the Addon Manager installer, because when there's no encoding specified, the default is UTF-8 so, the file is not lying about itself anymore...and the Addon Manager installer correctly deals with this. Well, it's not really "dealing" with it, it's just letting the official MS XML parser to do its job, and report of any errors when they are found.

So, this concludes the whole issue, to confirm the problem is caused by Active Sky Next, which changes the file encoding of the FSX XML files from their default to UTF-8, without properly updating the XML header to reflect the change.