I've got an ASP.NET Web Application (in the formal sense, it's not a "Web Site" project). It references some number of NuGet packages (let's call them all v1.0).
If I edit packages.config to reference a newer version of one of the NuGet packages and build, restore packages, or attempt to update the packages everything seems fine. It downloads the new package, creates a folder for it and the whole deal.
The problem comes when I attempt to reference newly added classes or properties within that package. (Let's call it v2.0.)
IntelliSense doesn't know about them. When I start trying to figure out why, I find that it's still referencing v1.0. It has downloaded 2.0, and the package file asks that it should use 2.0, but unless I explicitly remove the reference to the package and re-add it, VisualStudio seems content to stick with v1.0.
I feel like I must be doing something wrong, or at some point in time something has been configured incorrectly, but I'm at a loss as to what that might be.
Any advice?
You shouldn't update packages.config to get new package versions. Package Restore simply downloads the package files. It doesn't update references, etc.
To update a package you can use the Manage NuGet Packages dialog to install updates or use the Package Manager Console and type: Update-Package
Related
I can get my .net standard 2.0 package working in a .net framework 4.7.2 dll if I do the following steps
In my standard project VS2019 61.4.4 right click the project and select pack to create the .nupkg
Then I set up a nuget package source for the package
In my framework project I install nuget package
I get the following dialog
I choose PackageReference in project file
I answer yes to accept licensing
Then I can see the following
And I can get my project working.
However on a different machine running VS2019 16.5.0 Preview 2.0, I do not get the dialog asking me to choose the package manager format.
Instead the references look like
and I can not get my project working.
[Update]
After following Lance's link to migrate packages.config to PackageReference
The project looks like
I was able to remove the unwanted packages by right clicking references and choosing Remove Unused References
The program worked!
Go Tools=>Nuget Package Manager =>General => Package Management You can control the behavior by Allow format selection on first package install. Enable the checkbox and restart VS, this change will take effect.
And note the dialog only appears when we install first package in current project. So if you create a new project and install package, it will appear. And since you once installed packages in that project, the dialog won't appear in WindowsFormApp2 any more.
(But you can easily migrate packages.config to PackageReference, see this).
I'm using TFS for the first time and attempting a build. I'm getting the error:
This project references NuGet package(s) that are missing on this computer. use NuGet Package Restore to download them.
I realize that there are many similar posts on StackOverflow and I've searched through quite a few of them. What I've gathered is that the two boxes under Package Restore in Package Manager Settings should be checked (but that this is also irrelevant now because they're checked by default). I verified that mine were both checked anyway.
The next piece of advice I considered is deleting the /packages folder from the Source Control version of my application. There is no packages folder there OR in my local (pre migration to TFS) version of the application. Instead, there's a ../packages/ folder (up one level) from the application folder. It seems that, at some point, I've opted to store the packages for all of my applications in the same folder? If so, where is this setting and what do I need to change it to either in my local version or in Source Control Explorer?
Thanks!
Good evening,
Recently I started to use .Net Core. One of the things I am trying is an API with external controllers referenced as a dll. I found that RC2 dont allow you to reference directly .dll so I created my own nuget package, deployed on build using:
"scripts": {
"postcompile": [
"dotnet pack --no-build",
"C:\\Builds\\nuget.exe push \"%project:Directory%\\bin\\%compile:Configuration%\\%project:Name%.%project:Version%.nupkg\" -source C:\\Builds\\Packages"
]
}
Then on my API solution, I referenced my local folder as a nuget source, and included my local nuget package to the solution. It works perfectly but when I do a change on my external controllers package and rebuild, it update the .nupkg file (or create it if I remove it from the folder) correctly, then I restore the packages on my API solution, but for some reason it keeps loading the old version. I even removed the package, and added it again but keeps using the old code. I found that the only way to make it works, is to change the package version from 1.0.0 to 1.0.1, rebuild, and change the version on the api project.json. So my question is.. what I have to do to overwrite a local nuget package version when I build the changes so just restoring packages (or auto) it get the changes?
I'm trying to figure out a) if I'm going about this in the right way and b) how to update a solution level nuget package.
The core problem is that when a package is installed at the solution level (rather than in any particular project) and you try to update it, it doesn't remove the old reference. It just adds a new package reference, and imports both version. Which typically means (what with how powershell modules work) that the earlier powershell modules override the newer ones.
So what I have to do is uninstall the package and re-install it, which grabs the newer version. Seems inefficient.
Also, I can't seem to install or uninstall a solution level package from console. I have to do it with the Manage Nuget Packages utility, which I hate to use.
Here is some background on what I'm doing, if it helps:
I've set up a system at our company of using solution level nuget packages to add custom powershell script modules to the solution, as well as some more generalized scripted solutions I've written (like deleting TFS work items or changing a project name on the file system as well as within code).
So one project might have the DataServiceUtilities package and another would have the FrontEndUtilities package.
So, how can I update these packages without it adding two references? And can solution level operations be done in the Package Manager Console, which always defaults to targeting a project?
It appears that some of this comes from bugs in the Package Manager GUI tools, and Nuget in general
The Package Manager GUI tool doesn't handle updates properly for solution level packages. But if you run Update-Package from the package manager console it will correctly uninstall/re-install the solution-level package.
As for installing from command line, if a package has only a tools folder and no dependencies you can run install from command line and it sill install in the solution and ignore the default project.
However, as of now (Nuget 2.8) Nuget has a bug in it that causes it to treat solution-level packages with dependencies on other solution-level packages as project-level packages. It's apparently been in for about a year, and they claim it will be fixed in VS 2015. You can see the bug here: https://nuget.codeplex.com/workitem/3642
What this means is you cannot currently create a solution-level package with ANY dependencies. Please note that this is legal according to the documentation. Hopefully it will be fixed next year.
*Update
Just a quick update. It appears that in VS 2015 they have deprecated (or, more accurately, removed) solution level/tools only packages. After some out outcry they also decided to re-implement them in a future version, but it may be awhile before they do so.
Progress on re-implementing the feature can be found here: https://github.com/NuGet/Home/issues/1521
Discussion on how to work around the missing feature can be found here: https://github.com/NuGet/Home/issues/522
I've got problem with version of dependency that I set manually.
Note: I use Automatic restore within Visual Studio.
When I set Version="1.3.12.5" for my dependency in packages.config I expect that restore will install package and it will be referenced in next build I trigger. But it is not true. Package is installed and placed in packages directory but build does not use this downloaded packages (as csproj is not changed automatically).
Do you know possible scenarios to workaround this problem?
I tried to use Proget Client Tools but it turned out that it is not possible to use local directory feed with this. I need local and remote feeds support also, so it is additional requirement.
So, paraphrasing my question is...
How to easily change referenced version of package without touching csproj? (which is hard to edit in visual studio) Editing version twice (one in packages.config, two in csproj) is also an overkill.
Remember Package Restore simply downloads the package to the packages folder. It does not update project references as NuGet expects that the package had previously been installed. It's simply downloading the missing package files.
Package Restore is not a replacement for Install-Package. You can specify a specific version when installing. This will add the project references properly.