Support better iterative development of the XDT
davidebbo opened this issue · 4 comments
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 thedefaultDocument
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 thefoo.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 :)
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:
- Start with a base config before any xdt is applied
- Apply the xdt's from all the pre-installed site extensions (e.g. like Kudu)
- Apply the xdt's from all the
D:\home\SiteExtensions
folders - 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?
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.
- Read from
applicationhost.config.base
(applied pre-installed extension) - Apply the xdt's from all the
D:\home\SiteExtensions
folders in IIS Manager - Read from
D:\home\site\applicationhost.xdt
and apply it. - Display IIS Manager calculating AppHost, and current XDT
and need "All Reset" button 😸
I published "IIS Manager" 1.0.2 in Site Extension Gallery. Should this issue has been greatly improved :)
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 :)