Does NPP cache documents (in-re 64-bit applicationHost.config)?
If I’m in IIS Manager, and I make changes to applicationhost.config, sometimes I just want to examine them in NPP. So I’ll navigate to C:\Windows\System32\inetsrv\config and open the .config file with NPP. I see my changes just fine…good so far…
So I then decide to undo those changes using NPP (as opposed to IIS manager). I hit the Save button. IIS does NOT see my changes because apparently NPP has taken it upon itself to secretly “Save As” into the (32-bit) SysWOW64\inetsrv\config folder!! Why??
Even completely closing NPP and IIS, then re-opening the System32 (the 64-bit folder) version of applicationhost.config – it goes ahead and opens the SysWow64 (32-bit) version of the file???
Can anyone explain why this is happening? This is extremely unsettling, confusing, and frustrating. If NPP for some reason can’t open the file in the System32 folder–then DONT. But don’t do a switcheroo and “coddle” me and open the SysWOW64 version and tell me it’s the real one that I explicitly right-clicked on.
Any clarification, explanation, or workaround would be greatly appreciated.
with introduction of x64 architecture it was necessary to find a way to let x86 code still run, so MS decided to have
the needed dlls (64 bit and 32 bit) divided, which makes sense, but also introduced the mechanism of redirection which
is done for the users transpartenly. One side of the users are happy because they don’t have to think about whether the
file is used within 64bit or 32bit code and therefore whether it is needed to edit this or that file. The other users are unhappy
because of your reported behaviour. From my point of view this cannot be solved to make everyone happy. With current behaviour
of npp, and because it is 32bit application, you need to use sysnative alias in case you want to edit files which are located in 64bit
system32 directory and which have a 32bit version in syswow64 directory or you create a symbolic link to achive this.
Thank you, that’s what I’d feared, and it makes sense–I see why MS did it.
It would be nice if it gave a warning–NPP even shows the (incorrect) System32 directory in the hover-tool-tip on the tab for the doc, so it’s definitely happening at a low level.