Nuget MvcSiteMapProvider.Web v4.6.20 is Empty

[rikrak]

After upgrading MvcSiteMapProvider (MVC5) from 4.6.18 to 4.6.20 via Nuget i noticed that all the display templates have been deleted as well as the Mvc.sitemap, and MvcSiteMapSchema.xsd. After a bit of investigation I noticed that the NuGet package for MvcSiteMapProvider.Web is entirely empty.

Is this correct?

For info: I obtained the package from https://www.nuget.org/api/v2/package/MvcSiteMapProvider.web/4.6.20

[NightOwl888]

@maartenba

Maarten, this appears to be some issue with the MyGet build. When the MvcSiteMapProvider.Web package is built locally, it contains the content directory, but when doing so on MyGet, it does not.

I have a feeling this has something to do with the fact that I inadvertently deleted the build source. I was trying to stop the build. My brain saw a red icon and registered as stop rather than delete, and before I knew it, the build source was gone.

I created a new build source. The build succeeds, but for some reason it is not packaging this NuGet package correctly.

[NightOwl888]

@rikrak

Until this is resolved, you can safely use the 4.6.19 version of MvcSiteMapProvider.Web with 4.6.20 of the other packages. There were no changes between 4.6.19 and 4.6.20 of this package and 4.6.19 contains all of the files.

[rikrak]

Ta. Thanks for the swift response :-)

[maartenba]

@NightOwl888 just restored the original build source

[NightOwl888]

@maartenba

Thanks. However, it didn't help this problem.

I have done some steps to troubleshoot:

1. I confirmed that if I clone the repo locally, it works.
2. I checked to see if it could be a difference in NuGet.exe version, but the binary is checked into the repo. The full path to the NuGet.exe is included in the build script, so it isn't affected by system variables.
3. I confirmed that this issue is also happening in the DI packages as well - whenever there is a content directory, it is not being included in the NuGet package.
4. I found this answer (read the comments) that seems to suggest that convention-based configuration is not supported anymore. However, the version of NuGet that is in the source control is 2.7.0 (file version 2.7.40906.75). And this doesn't explain why it is working here locally, but not on the MyGet server.

My guess is that there is some configuration for NuGet on the MyGet server that I don't have that makes it exclude the convention-based functionality from the pack command.

NOTE: There also seems to be an issue with the MyGet status badge, but at this point I don't know if it is related or not.

According to the documentation, convention based file inclusion is supported.

If you follow the conventions described in Creating a Package, you do not have to explicitly specify a list of files in the .nuspec file. Note that if you specify any files, the conventions are ignored and only the files listed in the .nuspec file are included in the package.

Is it possible the MyGet server is adding a file to the pack command, forcing it to ignore the conventions?

[NightOwl888]

@maartenba

If it helps, the last time this succeeded was October 14, 2015. It first failed on October 27, 2015.

[maartenba]

On status badge: that should be back with the restore of the build configuration (the build id is back to what it was).

For build: MyGet doesn't do a thing when there is a build.cmd/myget.cmd, so that should not be an issue either. And since NuGet is local to the build, I'm perplexed seeing this behavior :-/

Wondering: should the content folder be added to the .nuspec files?

[NightOwl888]

On status badge: that should be back with the restore of the build configuration (the build id is back to what it was).

It still says pending even though the last build succeeded. But then, this issue is much lower in priority than the main one - I was just mentioning it in case it was a clue. The main issue is we have a bunch of broken packages released in 4.6.20 (that people are still downloading) that should be replaced ASAP. It doesn't fail for most people, because the default dependency behavior for MvcSiteMapProvider.Web is to download the lowest minor version.

For build: MyGet doesn't do a thing when there is a build.cmd/myget.cmd, so that should not be an issue either. And since NuGet is local to the build, I'm perplexed seeing this behavior :-/

Not exactly what I meant. I was wondering if there are some system variables that might be hijacking the NuGet command which makes it execute a different version of NuGet or perhaps some global NuGet configuration that is overriding the local behavior.

Wondering: should the content folder be added to the .nuspec files?

Well, one obvious fix would be to abandon the convention-based configuration (meaning we would need to specify every file/folder that gets included within the .nuspec files). But then, the convention-based configuration has been working fine up until about a month ago. It seems like we should first try to fix the problem rather than basically rewrite the build script (which could cause more problems), a lot of which is simply copying files into the right location to include in the conventions (something that wouldn't be necessary if we specify the files within the .nuspec).

[maartenba]

Readme shows "successful" here?

Yes, there is a %nuget% variable that might interfere, but since we specify a proper relative path in the build for MvcSiteMapProvider it should not interfere. Perhaps we can try a build with a renamed nuget.exe in MvcSiteMapProvider?

[NightOwl888]

Readme shows "successful" here?

Ahh - it was a browser cache issue.

Yes, there is a %nuget% variable that might interfere, but since we specify a proper relative path in the build for MvcSiteMapProvider it should not interfere. Perhaps we can try a build with a renamed nuget.exe in MvcSiteMapProvider?

Well, I guess the first step is to check what version is running. This might take a few builds to work out. Would creating a test feed be done on the same server as our original feed?

I am not following your logic as for renaming the executable.

[maartenba]

Latest 2.8.6 is the default on all agents (always the same configuration).

With renaming: in tools folder ,rename nuget.exe to "awesomenuget.exe" and call that one in the build, so that we're not calling anything called "nuget" but "awesomenuget" instead.

[NightOwl888]

I upgraded a copy of the local project to 2.8.6 - it still works.

[maartenba]

And the config on the machines is: <configuration />

[NightOwl888]

I discovered a clue. I was attempting to run a build on a test feed and discovered that it is working fine there. The feed is NightOwl888/mvcsitemapprovidertest.

Perhaps there is a way to reconcile the differences between this feed and that one?

I last ran the build source from the maartenba/MvcSiteMapProvider repo - same code, different result. The version that succeeded is 4.5.1-test0000005 (note that it is not the highest version).

https://www.myget.org/feed/mvcsitemapprovidertest/package/nuget/MvcSiteMapProvider.Web

[NightOwl888]

same code, different result.

By this, I mean it is succeeding on the test feed, but failing on the production feed.

[NightOwl888]

@maartenba

I made another test feed and it worked there. Then I ran again on the production feed and it is also working now. I made absolutely no changes to the repo. Any ideas? Did you repair something (or reboot something) or is this a mystery that will go unsolved?

[maartenba]

That feels mistery to me. Nothing has changed to the build machines, except for a reboot on some (not all)

[NightOwl888]

Well, whatever the reason was, it seems to be resolved now. Hopefully it stays that way.