XML File Runtime Element Placed Incorrectly

[Collins]

Hello,

I have a project that uses XML File and when a new element is added under the runtime section, on upgrade it is placed under another element instead of its own, even with "Is Identifier attribute" set.

The elements before the upgrade:

<runtime>
<generatePublisherEvidence enabled="false" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

The elements after the upgrade:

runtime>
<generatePublisherEvidence enabled="false" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

The way it should be:

<runtime>
<generatePublisherEvidence enabled="false" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
</assemblyBinding>
</runtime>

To recreate, use the AIP without the "System.Threading.Tasks.Extensions" elements to install and then add the "System.Threading.Tasks.Extensions" elements and upgrade.

[Catalin]

Hello Collins,

Thank you for providing the project files.

I have had a look over them and they look configured just fine.

Taking in consideration your project is quite complex, could you please try to replicate this behavior in a test project and forward that to me so I can build and test this on our end?

Best regards,
Catalin

[Collins]

Hi Catalin,

I have attached simple projects and files for your testing.

[Catalin]

Hello Collins,

Thank you very much for the provided resources.

I have tested this on my end and I was indeed able to reproduce the behavior.

After further investigations, I believe I found the culprit.

The last element you have added to the XML file had the following option enabled for it: "If the element is found" --> "Update"

Update.png (70.37 KiB) Viewed 21958 times

Basically, during the update, the setup will find the first "dependentAssembly" element, which in our case is:

<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>

and update it, resulting in:

<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>

To avoid this, please use the following option instead: "If the element is found" --> "Add a new sibling" (as in my screenshot above)

This way, the element should be added as a separate one, as you desire:

Result.png (79.87 KiB) Viewed 21958 times

Hope this helps!

Best regards,
Catalin

[Collins]

Hi Catalin,

That only works if the dependentAssembly doesn't exist. On every upgrade thereafter once it exists, it creates a new one.

New Install:

<runtime>
<generatePublisherEvidence enabled="false" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

On Upgrade:

<runtime>
<generatePublisherEvidence enabled="false" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

Also, if the bindingRedirect version changes in the future, it would not get updated, correct?

[Catalin]

Hello,

Please note that this is the correct behavior.

If your older setup already creates that element, you should set the "Remove element on uninstall" option for it.

RemoveElement.png (122.9 KiB) Viewed 21028 times

This way, on upgrade, the element will be removed and it will no longer be duplicated.

Also, if the bindingRedirect version changes in the future, it would not get updated, correct?

If the behavior is not set to "If the element is found --> Update" then the answer is no, the element should not be updated.

Best regards,
Catalin

[Collins]

Catalin,

I'm still seeing the same issue on upgrades as well. I emailed the install logs.

[Catalin]

Hello,

First of all, please note that I did not receive any log files via the email. Could you please double check the email address?

Anyhow, the log files are not necessary here.

Later edit: Please disregard the above as I found the email.

I'm still seeing the same issue on upgrades as well

Could you please give me some more details about this?

Do you mean that the element is duplicated on upgrade?

Did you do the changes I mentioned in the older version of the setup? if so, this should be working as expected since I tested this using the two sample projects you previously provided. Basically, this is what I did:

- in the older version, copied the XML element that is also created during the newer version installation

- check the "Remove element on uninstall" option

- installed the setup

- built the newer project and installed it

I then checked the file and the element was not duplicated.

I have also tested this without the option and I could indeed notice the behavior you described.

Perhaps I misunderstood your scenario. If that is the case, please forward me a step-by-step test case which I can follow in order to reproduce the issue.

Best regards,
Catalin

[Collins]

Do you mean that the element is duplicated on upgrade?
Yes, it was duplicated on the upgrade.

Did you do the changes I mentioned in the older version of the setup? if so, this should be working as expected since I tested this using the two sample projects you previously provided.
Yes, I set the dependentAssembly, assemblyIdentity and bindingRedirect to use "Add as new sibling" and "Remove element on uninstall" for the installed version and the upgraded version projects. I've attached the project just the way I tested them.

Going from v1 to v2 created this:
<runtime>
<generatePublisherEvidence enabled="false" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

[Catalin]

Hello,

First of all, please accept my apologies for the delayed reply.

Thank you for the provided files.

I have managed to build them on my end and I was able to reproduce this behavior.

Considering your speecific scenario, I believe the only solution would be conditioning the installation of that node to only be installed if it doesn't already exist.

You can see whether the node already exists through either an XML search or a custom action.

Hope this helps!

Best regards,
Catalin

[Collins]

Hi Catalin,

Sorry for the late response, I have been on vacation. This seems like a workaround. Can this be fixed so that entire sections can be removed and added on upgrades? One of the main reasons we migrated and used XML config is for this capability and to easily upgrade these sections, but so far they have not worked as expected.

[Catalin]

Hello Les,

No worries about the delayed reply!

I hope you enjoyed your vacation.

Regarding this, I do not believe this is a bug, but rather a corner case.

I will try to discuss this with the development team to see if we can somehow improve the behavior, but I do not see what we can do in this specific scenario.

Best regards,
Catalin

[Collins]

Hello Les,

No worries about the delayed reply!

I hope you enjoyed your vacation.

Regarding this, I do not believe this is a bug, but rather a corner case.

I will try to discuss this with the development team to see if we can somehow improve the behavior, but I do not see what we can do in this specific scenario.

Best regards,
Catalin

Hi Catalin, I understand about the "Remove element on uninstall", but for the dependent assembly being placed under the wrong section, that is a bug because none of the other depended assemblies do that nor do I have to add them as a new sibling, which creates duplicates on upgrade.

Also, there is no way to condition those elements without having to use a custom action to resolve what should be working. We have other applications with runtime sections that have more than double the dependent assemblies and they don't have this issue.

Having the "Remove element on uninstall" outside of the component requirement would be a huge improvement.

[Catalin]

Hello Les,

Please allow me some more time to further discuss this with the development team and I will followup on this thread as soon as I will have a conclusive answer.

Best regards,
Catalin

[Catalin]

Hello Les,

I further tested this last Friday, but unfortunately I wasn't able to obtain the desired behavior.

I created a ticket so the dev team can further investigate this.

I will followup on this thread as soon as I will have more information.

Best regards,
Catalin