Updating always resets mvc.sitemap

[Germs2004]

Every time I update via NuGet, it resets my mvc.sitemap file, which contains all my XML that lists and organizes my mvcSiteMapNodes. I'd like the updater to leave that file alone unless the new version requires changes that aren't backwards compatible.

Most recently, this problem happened when I updated from 4.4.0.0 to 4.4.1.0.

[Germs2004]

It looks like this problem still occurs with when I updated from 4.4.0.0 to 4.4.1.0.

The new file that replaces my existing file looks like this (except brackets instead of parenthesis):

(?xml version="1.0" encoding="utf-8" ?)
(mvcSiteMap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://mvcsitemap.codeplex.com/schemas/MvcSiteMap-File-4.0"
xsi:schemaLocation="http://mvcsitemap.codeplex.com/schemas/MvcSiteMap-File-4.0 MvcSiteMapSchema.xsd")

(mvcSiteMapNode title="Home" controller="Home" action="Index")
(mvcSiteMapNode title="About" controller="Home" action="About"/)
(/mvcSiteMapNode)

(/mvcSiteMap)

[NightOwl888]

Sorry, I didn't get a chance to answer before because we now have a problem pushing the NuGet symbols.

The latest version of NuGet validates to ensure the files are not overwritten if they have changed since the installation. You should upgrade your NuGet version to fix this.

Also, you should never upgrade MvcSiteMapProvider.Web as it contains only configuration files to get you started. But as mentioned, if you upgrade NuGet it will not automatically overwrite files even if you do upgrade MvcSiteMapProvider.Web. And if you upgrade from the package manager console, you can pick and choose which files to overwrite (if any).

[NightOwl888]

I am afraid the fix for this broke the new install process, so I have to revert and reopen this issue.

But as mentioned, this only happens with old versions of NuGet so most people will not be affected by this.

[Germs2004]

I am currently using NuGet 2.7.40808.167 in Visual Studio 2012. Today, I updated from 4.4.1 to 4.4.3. It asked me if I wanted to overwrite my sitemap file during the update. I clicked No. My sitemap was not affected this time. Ideally, it shouldn't ask me if I want to overwrite the file because it should just assume that nobody will ever want their file overwritten. But if you believe that clicking "No" like I did is a good enough solution, then I agree that we can close this ticket. It's not a big deal to me since I can click "No" from now on to prevent the problem from happening. I appreciate your quick turnaround time and attention on this. It's very impressive, sincerely.

[NightOwl888]

Well, you are preaching to the choir. This isn't a problem with MvcSiteMapProvider - it is a limitation of NuGet.

The biggest problem isn't the Mvc.sitemap file, it is the DI configuration files for people who have installed one of the DI packages.

I have posted a question on StackOverflow and also opened a ticket Latest version of dependency not installed on new install so hopefully this issue can be resolved in a future version of NuGet. There is a new version scheduled to be released in November. Unfortunately, that doesn't help us now.

However, I have added a warning to the upgrade documentation that we don't support NuGet prior to version 2.6.

It is theoretically possible to fix this using scripting, but it would require duplicating a lot of logic from NuGet to support multiple framework versions and replace tokenized variables in the files. It seems like a long way to go just so you don't have to click "no".

Anyway, I am going to leave this open until either I hear back from the NuGet team or someone can present a solution so that the packages are never upgraded AND the latest version is installed in a new project. At the very least, this will make the issue more visible so people are aware they should upgrade NuGet to the latest version when using MvcSiteMapProvider.

[maartenba]

Didn't get response from the NuGet team on this so far :-(

[NightOwl888]

I have opened 2 issue reports at NuGet regarding this issue. PLEASE VOTE UP the issues so they get attention from the NuGet team sooner rather than later.

Feature Request: Allow package author to specify a file as not upgradable
Latest version of dependency not installed on new install

The first one I believe is the correct way to fix this - adding support for non-upgradable files to NuGet which is something that it is currently lacking.

[Germs2004]

It seems this problem has been fixed for a long time now. Closing this old ticket.