Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Prerelease VS stable versions



  • This might be a more general question and not in particular related to ProGet, but maybe someone in this forum has some ideas.

    We are creating pre-release versions of our nugets until we reach a stable state, then creating a stable version. Hereafter we start with a pre-release of the next version and so on.

    After having begun creating pre-release nugets we are experiencing unexpected behaviors in Visual Studio when trying to install our own pre-release nuget.

    To simplify the problem I have created a nuget in both a pre-release and a stable version which has only one dependency on Ninject.MVC5 v3.2.1.0.

    When installing the pre-release of this nuget by using the Visual Studio nuget package manager dialog choosing "Include Prerelease". We get the following error in the output:

    Attempting to resolve dependency 'Ninject.MVC5 (≥ 3.2.1.0)'.
    Attempting to resolve dependency 'Ninject (≥ 3.2.0.0 && < 3.3.0.0)'.
    Attempting to resolve dependency 'Ninject.Web.Common.WebHost (≥ 3.0.0.0)'.
    Attempting to resolve dependency 'Ninject.Web.Common (≥ 3.0.0-unstable)'.
    Attempting to resolve dependency 'Ninject (≥ 3.0.0.0 && < 3.1.0.0)'.
    Updating 'Ninject 3.2.0.0' to 'Ninject 3.0.1.10' failed. Unable to find a version of 'Ninject.MVC5' that is compatible with 'Ninject 3.0.1.10'.
    

    When installing the stable version of the nuget it succeeds with the following output:

    Attempting to resolve dependency 'Ninject.MVC5 (≥ 3.2.1.0)'.
    Attempting to resolve dependency 'Ninject (≥ 3.2.0.0 && < 3.3.0.0)'.
    Attempting to resolve dependency 'Ninject.Web.Common.WebHost (≥ 3.0.0.0)'.
    Attempting to resolve dependency 'Ninject.Web.Common (≥ 3.2.0.0 && < 3.3.0.0)'.
    Attempting to resolve dependency 'WebActivatorEx (≥ 2.0 && < 3.0)'.
    Attempting to resolve dependency 'Microsoft.Web.Infrastructure (≥ 1.0.0.0)'.
    

    I was not expecting the resolve of dependencies for Ninject.MVC5 to be different when choosing to install a pre-release nuget which depend on a stable version of Ninject.MVC5.

    Is the observed behavior expected?

    Installing my pre-release nuget from the package manager console with the command:

    Install-Package <packagename> -Version 0.1.0-alpha179

    The resolve process succeeds as expected.

    Product: ProGet
    Version: 3.3.4



  • I've tested this and reproduced that behavior with both ProGet and NuGet.org, so you're right that this isn't really a ProGet issue. I'm not completely certain, but I can guess as to what's happening here:

    It looks like there are two conflicting dependencies on Ninject: One package requires that it be between 3.2.0.0 and 3.3.0.0 and another requires that it be between 3.0.0.0 and 3.1.0.0. These ranges don't overlap at all, so this dependency can't be resolved.

    So why does it work when Include Prerelease isn't selected? Enabling that option causes all dependency resolutions to include prerelease versions in the results - and installing a package from the package manager always grabs the latest version. There is probably a prerelease package version somewhere in that dependency graph that is adding that Ninject (≥ 3.0.0.0 && < 3.1.0.0).

    The Install-Package command uses different queries than the package manager dialog, so it isn't too surprising that there is different behavior there. Without knowing more about the packages themselves, I can't really say for sure which is the "correct" result. Sometimes the only way to figure out what's happening is to do a fiddler trace of what the NuGet client is sending up to the server.

    Not sure if this helps at all. Sorry I couldn't give you a more definitive answer!



  • Thank you for investigating the issue. I will assume that the observed behavior is due to a problem with the dependency graph specific to the Ninject nuget package.


Log in to reply
 

Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation