Skip to content
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.VisualStudio.IVsPackageInstaller.InstallPackage raising NullReferenceException #1944

Closed
hugoqribeiro opened this issue Jan 18, 2016 · 10 comments
Assignees
Labels
Priority:2 Issues for the current backlog. Product:VS.Client Type:Bug
Milestone

Comments

@hugoqribeiro
Copy link

The following code is raising NullReferenceException when the value of version is null and InvalidOperationException when the value of version is exactly the same as the latest version of the package being installed.

        try
        {
            this.PackageInstaller.InstallPackage(packageSource, project, packageId, version, ignoreDependencies);
        }
        catch (Exception ex)
        {
            string error = string.Format(CultureInfo.CurrentCulture, Properties.Resources.RES_Error_InstallingNuGetPackage, packageId, project.Name);
            throw new NuGetServiceException(error, ex);
        }

This does not make any sense because installing the same package in Package Manager Console works just fine. It seams like a bug in the NuGet.VisualStudio.* code base.

Any ideas on how to find the reason for this or get some kind of workaround?

Thanks.

Same question on stackoverflow: http://stackoverflow.com/questions/34859647/object-reference-not-set-to-an-instance-of-an-object-with-nuget-visualstudio

@yishaigalatzer
Copy link

This seems like a bug, nothing should throw a NullReferenceException, ArgumentNullException yes

Can you please share more information? What version of NuGt are you using? What version of Visual Studio?

@hugoqribeiro
Copy link
Author

I'm using Visual Studio 2015 and the version of the NuGet extension is 3.3.0.167.
This exact piece of code worked just fine with Visual Studio 2013.
The bug started when we converted our extension, that uses this code, from VS 2013 to VS 2015.

@yishaigalatzer
Copy link

And can you tell us what are you exactly trying to achieve/do?

@hugoqribeiro
Copy link
Author

Our Visual Studio extension includes a multi-project template used to create custom solutions.

That template includes a wizard that performs a set of custom actions.

One of those actions will restore packages defined in packages.config files created by the template . In the end it also installs a set of other packages (not referenced in the packages.config) because these packages need to install content files (that are not created by restore operations, as I understand).

We use the NuGet.VisualStudio.IVsPackageInstaller to perform the installation and we pass the version as null because that is supposed to get the latest version available. The package source argument is "All".

@yishaigalatzer
Copy link

Thanks I can take a look but in general this is something we highly advertise against. Picking up latest version of a package leads to inconsistent and buggy experiences for templates.

Related: You mentioned that specifying the specific version leads to failures as well. I'm suspecting that something else is going on either with your sequence of operations or the specific packages being installed.

What would be really helpful is sharing a sample that walls through the scenario (i.e. Extension project replicating the scenario) and the failed callstack

@hugoqribeiro
Copy link
Author

It is very difficult to share our extension project because that extension has numerous other features and relies on a set of libraries that would make it very difficult for you to debug it. I will try to reproduce the error in a smaller and simpler VS extension with a simple template. I believe that scenario will have the same problem.

Further testing makes me believe that the error is really in the NuGet.VisualStudio package and it has nothing to do with either our ProGet server, or even the package we're trying to install in the template. Off course this can be proven wrong if I find different behavior in the sample.

But let me explain the tests that I ran that led me to believe this:

  • To rule out problems in the package being installed, I've changed the template to try to install the "NuGet.VisualStudio" package instead. The outcome is the same. If version is null it raises NullReferenceException. It version is "3.3.0" it raises InvalidOperationException (unable to find...).
  • To rule out problems due to the fact that we're using IVsPackageRestorer.RestorePackages before instaling packages, I've commented that but the outcome is exactly the same.
  • To rule out problems coming from the nuget.config files being created/used by the template, I've deleted them (no nuget.config at the new solution level), and the outcome is again the same.

May be you have a test scenario that uses the same API to install a package and you can test if it works...

@hugoqribeiro
Copy link
Author

OK, I've managed to reproduce the error in the attached simpler extension.

Please look into the class ModuleSolutionWizard in MyVsix.Wizards.

This extension will install under the name "Sample Vsix". The project template is created under "Templates | Visual C# | ELEVATIONXXX" and the name is "PRIMAVERA Elevation Module".

MyVsix.zip

@joelverhagen
Copy link
Member

I've looked into this and there are a couple issues here.

First, the NuGet code in 3.x (VS 2015) does not have support for the "All" source (of type string) that you are using. This functionality did exist in NuGet 2.x (VS 2013), which explains why your code used to work.

If you really need to rely on the user's configured sources (which can be brittle depending on the user's configuration), you can pass null as the source and NuGet will use the user's configured sources. This has the same effect as the "All" source in 2.x but is compatible with both 2.x and 3.x NuGet extensions.

It should be noted however, that a more predictable experience for your extension would be to explicitly pass in the source and even the version of the package that you would like to install.

The other issue happening here is the NuGet 3.x code is throwing an unhelpful null reference exception when you are passing this "All" source and a null version. We'll fix this. However, you should be able to unblock yourself by using a null source.

@hugoqribeiro
Copy link
Author

Thank you! This solved the problem.

@BilgehanYildiz
Copy link

I have similar issue ,mycode work on vs 2013 but failed in vs2017.I use All and I change it to null but error is same.
var installer = _componentModel.GetService();
installer.InstallPackage(null, myproject, id, (System.Version)null, false);
No latest version found for 'MYPackage' for the given source repositories and resolution context

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:2 Issues for the current backlog. Product:VS.Client Type:Bug
Projects
None yet
Development

No branches or pull requests

6 participants