Upgrading Web.config dependent assemblies

[Antarctica]

This is the Web.config part that defines the assemblies that I depend on:

Code: Select all

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
	  <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>

A dependency has just been added; the old Web.config was

Code: Select all

      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>

The Web.config is generated by Advanced Installer's XML generator. I have defined all "name" attributes as identity, and all dependentAssembly and assemblyIdentity and bindingRedirect elements as "update existing". Web.config is generated correctly if I make a new one, but if I update an existing Web.config, the generated Web.config looks like this:

Code: Select all

      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>

So it seems that the name attribute is only used as identifying attribute for the assemblyIdentity element, not for its parent dependentAssembly element. The tree structure as I have defined it is not kept intact. Is this correct? If yes, how do I fix this?

I am using Advanced Installer 12.5.1.

[Eusebiu]

Hi,

Please take a look on the XML edit modifies when it shouldn't thread which debates a similar problem.

Best regards,
Eusebiu

[Antarctica]

The problem is similar, but not the same. The main difference is that I have defined an identifier attribute on the node that I want to update. The node with the path "dependentAssembly assemblyIdentity[name=System.Web.Pages]" already exists.

But I think you are searching for the first "dependentAssembly" node, and then you are searching for the "assemblyIdentity[name=System.Web.Pages]" node under that path. Which fails, because the first "dependentAssembly" node is not on the path to "dependentAssembly assemblyIdentity[name=System.Web.Pages]".

Another thing is that "dependentAssembly" does not have an identifier attribute by default. I can change that in my XML generation, but whenever a user edits the dependentAssembly list using Microsoft's IIS Management console, identifier attributes are removed and subsequent updates via Advanced Installer will fail.

[Eusebiu]

Hi,

Indeed, the "dependentAssembly" nodes should also have an identifier attribute set to them, otherwise the search will always stop to the first node that has that name and only that will be updated.

Best regards,
Eusebiu

[Antarctica]

I can't change the format of the Web.config XML file that Microsoft has defined. So for IIS setups I cannot use Advanced Installer. Is this what you want to say?

[Eusebiu]

Hi,

Unfortunately, this problem can be overcome only using the "Is identifier attribute" option. However, if you do not have to much changes to make in the XML file, you can use the "Text File Update" operation to find a string and replace it with a new one.

Best regards,
Eusebiu

[Antarctica]

Thanks for your clarification.

We have managed to overcome the issue by removing all dependentAssemblies during uninstall/reinstall, before adding the subtree again. This should be the cleanest solution.

[Eusebiu]

You're welcome. I'm glad you got this working.

Best regards,
Eusebiu

[raghu.00a@gmail.com]

Hi Antarctica,
How you are removing and adding the dependentAssemblies to web.config file while installing the application?
please advise.


Regards
Raghu

[raghu.00a@gmail.com]

can any one suggest me how to access the web.config file content while install is in progress
and modify the <dependentassembly> section in web.config.


Regards
Raghu

[Daniel]

Hello Raghu,

You can see my response in the "Re: search in app dir and launch conditions" forum's thread.

All the best,
Daniel

[AndyL]

I know I'm reviving an old thread here, but I think the issue in the original post is still a problem and there ought to be a better answer to it.
Any ASP.NET MVC or ASP.NET web API application is going to need to update the contents of the <assemblyBinding> web.config section when doing an upgrade, if dependencies have changed. There will be a bunch of <dependentAssembly> elements in that section and they do not have any key to identify the right one to update. There needs to be a way to identify an element by its contents rather than an attribute.

I'd love to know how @Antarctica achieved the workaround. I'm finding if I try to delete the whole <assemblyBinding> section and then recreate it in the same XML transform, it fails with the error "CustomAction AI_XmlConfig returned actual error code 1603" in the log. The best I've been able to do is to use an inline Powershell script action to remove the section from the web.config file and save it, before the XML transform gets applied. That feels like a kludge.

[Catalin]

Hello Andy,

It's been quite a while since this thread was created and my colleague Eusebiu who initially answered it has some time off currently.

As the scenario is not really clear for me, it would really help if you could give us some more information regarding it. For instance, if you could create a sample project that reproduces this and forward it to us together with a step-by-step test case which we could follow, that'd be great.

Best regards,
Catalin

[AndyL]

Hi Catalin. Let me see if I can explain.

In the XML web.config file of any .NET web application, you will likely have an <assemblyBinding> section that contains version information about external libraries (assemblies) that the application depends on, similar to this:

Code: Select all

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.7.0" newVersion="5.2.7.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

The problem comes when I release a new version of my application, which now uses updated versions of one or more of these libraries. When a user runs an upgrade install of my application, I want the installer to, for example, find "System.Web.WebPages" and then change "3.0.0.0" to "4.0.0.0"

I can't just replace the whole web.config file because it contains a bunch of other settings that I don't want to overwrite. So what we ideally want to do, is put an XML transform in the installer that just finds the "oldVersion" and "newVersion" attributes and changes their values.

However, because of the structure of this XML schema (which is baked in to Microsoft .NET), I can't do that. My XML transform needs to find the right <dependentAssembly> element, but there's no way to do that currently, because that element doesn't have a key attribute. I'd need to be able to identify the <dependentAssembly> based on the name attribute of the child <assemblyIdentity>, and then move to the sibling <bindingRedirect> to get to the attributes that I need to modify. I've tried to illustrate this below.

dependentAssemblyConfig.png (57.78 KiB) Viewed 12529 times

This is something the existing XML file transform functionality can't do - it can't pick the right <dependentAssembly> because it doesn't have a key attribute itself. This is the fundamental problem that Antarctica was describing in the original post.

You might need to add or remove <dependentAssembly> elements as well.

Updating <assemblyBinding> must be a common requirement when upgrading .NET web applications, so there ought to be a documented best way to do it, and it doesn't seem there is at the moment. If the workaround is to remove and recreate the whole <assemblyBinding> section, then that is probably tolerable, but we still need to know how to do that, because the only successful way I've found (using PowerShell) is pretty kludgy.

[Catalin]

Hello Andy,

Thank you very much for the explanation, your scenario is clearer for me now.

Given your scenario, I just remembered I had a similar ticket in the past, from another user. Please have a look over it here:

XML File Runtime Element Placed Incorrectly

and let me know if it helps in any way.

The scenario is not the exact same, but the root problem was the same - identifying the correct dependentAssembly node.

I remember I had a really long talk with the developer about this, but we did not really manage to find a proper solution, unfortunately.

Best regards,
Catalin