Support better iterative development of the XDT

[davidebbo]

I love this extension, and have been wanting something like it for a long time!

There is one part of the workflow that is not ideal, although it is hard to fix. Steps:

• Start with clean site and run the extension
• Make some change, like add <add value="foo.htm" /> to the defaultDocument list
• Go to xdt tab. Everything looks great.
• Save and Restart
• But now let's say you also want to add <add value="bar.htm" />. Make this change and add it after foo.htm.
• Switching to xdt tab, the problem is that it only has the transform for adding bar.htm. So if you save it, you've lost the foo.html part of the transform

Of course, it's clear why it works the way it does, given that it always starts with the fully transformed config from %APP_POOL_CONFIG%, which already has the foo.htm transform.

It's not an easy problem to fix, but we can brainstorm ideas :)

[davidebbo]

I think to fix this we might need to change the way Azure transforms files to keep track of the state of applicationhost.config before it applies the xdt in the site folder.

The general Azure transform flow today is:

1. Start with a base config before any xdt is applied
2. Apply the xdt's from all the pre-installed site extensions (e.g. like Kudu)
3. Apply the xdt's from all the D:\home\SiteExtensions folders
4. Apply the xdt in D:\home\site\applicationhost.xdt

Let's say that Azure kept track of applicationhost.config after step 3 but before step 4. That would allow your extension to do the following:

• Start with the Step 3 config as a base, instead of %APP_POOL_CONFIG%
• Read the current D:\home\site\applicationhost.xdt, and apply it yourself
• Display the result of that in your config editor
• When calculating new transform, you would diff the Step 3 config with what the user typed

This way, the user could keep going back and tweaking things, and it should do always the correct thing, never losing previous work. At least in theory! :)

What do you think?

[shibayan]

Thank you for the explanation of the behavior of the Kudu. You're right, the last operation is not recorded issue is very important.

I think available applicationhost.config.base file. maybe applicationhost.config.base is created after step 2 has been completed.

1. Read from applicationhost.config.base (applied pre-installed extension)
2. Apply the xdt's from all the D:\home\SiteExtensions folders in IIS Manager
3. Read from D:\home\site\applicationhost.xdt and apply it.
4. Display IIS Manager calculating AppHost, and current XDT

and need "All Reset" button :smile_cat:

[shibayan]

I published "IIS Manager" 1.0.2 in Site Extension Gallery. Should this issue has been greatly improved :)

[davidebbo]

Wow, it works superbly now. Very impressive!!

I actually have an idea to make it even a little bit better, but I'll open a separate issue for it :)