If the web.config is open in the XML editor when a NuGet package is applied that performs a web.config transform, that transform may fail to update the XML properly. Subsequent automation (e.g. an extension that applies a NuGet package and then expects to modify XML added to web.config) may then fail. Looking briefly through the code (and correct me if I'm wrong) it appears that the transform is applied to the file on disk rather than the contents of the text buffer created when the file is opened within Visual Studio. Hence, if the file is open and/or modified but not saved, the contents of the file and the contents of the text buffer may not be in sync. Modifying the file on disk may cause Visual Studio to prompt the user to reload the file (but at the risk of losing changes already in the text buffer), but depending on when this happens (and the user responds), the reload may not be soon enough for automation executed after installation of the NuGet package to obtain the correct file contents.
A safer way to make changes to a file in a Visual Studio project is to (if an XML file) use the XmlEditorService which handles document management and allows you to pretty much worry only about the XML DOM, or to use the Running Document Table to determine what files (if any) are open and an Invisible Editor to pull/push changes from/to an open document.
Comments: This is a duplicate of https://nuget.codeplex.com/workitem/3417
A safer way to make changes to a file in a Visual Studio project is to (if an XML file) use the XmlEditorService which handles document management and allows you to pretty much worry only about the XML DOM, or to use the Running Document Table to determine what files (if any) are open and an Invisible Editor to pull/push changes from/to an open document.
Comments: This is a duplicate of https://nuget.codeplex.com/workitem/3417