NuGet product used: VS UI
NuGet version: 4.2.0
VS version: 15.2 (26430.13)
OS version: win10 v1703 (15063.296)
I've done this with a class library project I had updated from .NET 4.5.2 (created in earlier versions of Visual Studio) to .NET 4.6.2 (running in Visual Studio 2017).
Create a .NET Framework class library targeting .NET 4.5.2. Create an app.config for the project and save the app.config. Note the encoding for the file. It should be either UTF-8 with signature or UTF-8 without signature.
Add a NuGet package to the project that will update the app.config file. Make sure the app.config file is updated and saved. I suggest EntityFramework 6.1.3. Use the packages.config method (not sure if this happens with <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
).
Using the Visual Studio 2017 project properties page, change the Target framework to .NET 4.6.2. Make sure the app.config file is updated and saved. The <supportedRuntime>
tag should be updated. Note the encoding for the file and the way the XML has been reformatted. My experience says the encoding will be UTF-8 without signature and the self-closing tags will not have a space before the slash (e.g. <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
).
Now force the NuGet package to be reinstalled using the package management console in Visual Studio 2017. I used the command Update-Package -Reinstall -Id EntityFramework
. Note the encoding for the file and the way the XML has been reformatted. My experience says the encoding will be UTF-8 with signature and the self-closing tags will have a space before the slash (e.g. <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
).
The effect of the encoding changing for no reason is annoying and often the updates are nothing significant, just the UTF-8 signature added or removed and the self-closing elements changing for no good reason. It's annoying to have to have check these changes in and more annoying to have to review them.
NiGet should have the same behavior as Visual Studio does when it edits config files. Stay with a consistent encoding and XML formatting style.
For reference binding redirects are handled here: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.PackageManagement.VisualStudio/Runtime/BindingRedirectManager.cs
NuGet is using XDocument to handle reading/writing the file.
This causes a ton of unnecessary pending changes that need to be reviewed or undone. It also hoses intentionally arranged attributes by glomming a bunch on to one line. Given the example of
<section name="entityFramework"
type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />)
nuget will cause it to end up like this
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />).
requiring perma-scroll to the right. Its _really_ frustrating with system.serviceModel
entries.
The code file linked above also seems to be where all the useless class library app.configs are coming from.
@mishra14 - this thing is a _daily_ drag for the working programmer. Cleaning up after it can cost me up to 30 minutes per day. Can this be moved up in priority?
I'll second this. I'm manually going through and undoing the formatting so as to not throw false positives in change logs.
I agree. This messes up the change log unless you take the time to go through the config diff and reset all the formatting changes, which has to be done carefully so you don't accidentally reset some of the actual config changes.
cc @PatoBeltran who is working on xml changes.
Any updates on this? No major input since @emgarten more than 2 years ago. This issue has impacted the projects I've worked on in the past and is still present in VS2017.
This is, hands down, the single largest problem with Visual Studio / NuGet. It's a constant, never-ending source of massive, false-positive change logs. It trains developers to ignore change sets, because literally every line of the document is changed, and it's impossible to tell what meaningful changes are actually present int the file among all these random spacing changes... sometimes there's a space before a closing tag "(space)/>" and sometimes it removes them "/>". The ideal behavior, honestly, would be if it would detect the spacing on each line and LEAVE IT ALONE.
If you're using XDocument for the save, just disable the reformatting!
Its even more frustrating when you have given a working example of how to do this.
So how is this thing coming along? I still have to manually undo web.config and app.config files because they get changed for exactly no reason any time I update a library. The other comment said @PatoBeltran was already working on this like 2 years ago, did anything come out of that?
Most helpful comment
This causes a ton of unnecessary pending changes that need to be reviewed or undone. It also hoses intentionally arranged attributes by glomming a bunch on to one line. Given the example of
nuget will cause it to end up like this
requiring perma-scroll to the right. Its _really_ frustrating with
system.serviceModel
entries.The code file linked above also seems to be where all the useless class library app.configs are coming from.