New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NuGet 3 does not handle errors in packages.config like 'incorrect allowedVersions', 'duplicate entries of a package' or just plain invalid xml and so on #481

Closed
willemduncan opened this Issue Apr 23, 2015 · 6 comments

Comments

Projects
None yet
6 participants
@willemduncan

willemduncan commented Apr 23, 2015

Using VS2015 (CTP6) and NuGet 3.0.60225.100, having a Packages.config with an allowed version filter crashes Nuget, which in turn kills Visual Studio.

This seems to happen when the allowedVersions="..." attribute contains a version number without at least one period (.).

  • Works: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" />
  • Works: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" allowedVersions="6.0.8" />
  • Works: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" allowedVersions="6.0" />
  • Crash: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" allowedVersions="6" />
  • Works: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" allowedVersions="[6.0]" />
  • Crash: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" allowedVersions="[6,7]" />
  • Works: <package id="Newtonsoft.Json" version="6.0.8" targetFramework="net45" allowedVersions="[6.0,7.0]" />

From the event log:

Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: NuGet.Packaging.PackagesConfigReaderException
Stack:
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)

This issue is also described on Codeplex here: https://nuget.codeplex.com/workitem/4456

@yishaigalatzer

This comment has been minimized.

yishaigalatzer commented Apr 23, 2015

Thanks for reporting this. Note that we are not looking at codeplex issues for quite some time (and it's documented everywhere at this point). For now there is no way to block opening new issues on codeplex without hiding all the old issues.

In powershell you just get an error, and when opening the nuget dialog, VS now hangs. but the version of just 2 without dot is not supported (nor it was in Visual Studio 2013)

@willemduncan

This comment has been minimized.

willemduncan commented Apr 23, 2015

I assumed so, which is why I duplicated the issue here (a quick search came up with Codeplex first).

Using a version limiter of `"[1.9,2)" (a common requirement for jQuery) seemed to work fine so far with multiple projects in vs2013. Definitely no crashes, but maybe the actual version limiting was down to good developer instructions rather than nuget, not sure about that.

Interestingly, the nuget manual suggests single digit versions should work. Copied from Constraining Upgrades To Allowed Versions:

<?xml version="1.0" encoding="utf-8"?>
<packages>
    <package id="SomePackage" version="2.1.0" allowedVersions="[2,3)" />
</packages>

Ideally a malformed version string would be reported in the Package Manager console or something, but I suppose that is a feature request and out of scope for this bug report.

@yishaigalatzer

This comment has been minimized.

yishaigalatzer commented Apr 23, 2015

It is actually reported in the package manager window (even for vs2013). Looks like this never really worked. Perhaps some versions of it do, we will verify.

Thanks for taking the time. Great bug report!

@yishaigalatzer

This comment has been minimized.

yishaigalatzer commented Apr 30, 2015

We should also consider behavior in console, and he case where we have multiple keys like in #511

@deepakaravindr deepakaravindr changed the title from NuGet 3 crashes on some `allowedVersions` attribute values. to NuGet 3 does not handle errors in packages.config like 'incorrect allowed versions', 'duplicate entries of a package' or just plain invalid xml and so on Apr 30, 2015

@deepakaravindr deepakaravindr changed the title from NuGet 3 does not handle errors in packages.config like 'incorrect allowed versions', 'duplicate entries of a package' or just plain invalid xml and so on to NuGet 3 does not handle errors in packages.config like 'incorrect allowedVersions', 'duplicate entries of a package' or just plain invalid xml and so on Apr 30, 2015

@deepakaravindr

This comment has been minimized.

Member

deepakaravindr commented Apr 30, 2015

As discussed with @feiling , assigning this to him

feiling pushed a commit to NuGetArchive/NuGet.PackageManagement that referenced this issue May 14, 2015

feiling pushed a commit to NuGetArchive/NuGet.VisualStudioExtension that referenced this issue May 14, 2015

feiling
Before creating the package manager doc window, the packages.config o…
…f the projects are first validated.

If it's not valid, the package manager doc window will not be created.

Part of the changes to fix NuGet/Home#481.
@leonmeijer

This comment has been minimized.

leonmeijer commented Jul 15, 2015

You can use the Powershell script below to find all duplicate packages in your solution. It finds all packages.config files recursively and per packages.config file, it checks for duplicate package ids.

$solutionFolder = "C:\MySolution"
$nugetPackageFile = "packages.config"

$files = Get-ChildItem -Path $solutionFolder -Filter $nugetPackageFile -Recurse

foreach ($file in $files)
{
    [xml]$xml = Get-Content $file.FullName
    $nodes = Select-Xml "/packages/package/@id" $xml
    $packageIds = @{}

    foreach ($node in $nodes) {
        $packageId = $node.Node.'#text'
        try
        {
            $packageIds.Add($packageId, $packageId)
        }
        Catch [System.ArgumentException]
        {
            Write-Host "Found duplicate package in " $file.FullName ". Duplicate package: $packageId"
        }
    }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment