I have a solution with about 5 projects including a Silverlight client.
Through NuGet, I add the Async Targeting Pack for VS 11 at the solution level and select all projects.
It adds a reference in all the non-Silverlight projects, but not the SL one. The workaround is to add the reference by hand.
Is this a failure of NuGet? A failure of the NuGet package? Or am I doing something wrong?
Same thing occurs with Caliburn.Micro and the SL package.
Yet if I start from a fresh clean project, it all works as expected.
I tried deleting the .nuget and package folders, and manually removing the project reference, and that seemed to clear everything out, but I still had the above issues when adding the packages back in.
Greg
Which version of Silverlight are you using? I noticed the NuGet package only targets NET40, NET45 and SL5, so if you're using Silverlight 4, the reference won't be added to your SL4 projects.
Related
I have 2 projects: A & B that I want to publish as NuGet Packages but I don't know how to develop efficiently in Visual Studio.
Solution 1
Project A
Project B - references Project A as NuGet reference
When I make a change to Project A that is needed in Project B do I have to publish Project A? Is there a way to get the project reference functionality during development? Maybe Project B shouldn't reference Project A via NuGet?
There must be a good way to handle this situation, no? I've reviewed the NuGet docs but I couldn't find anything. There must be docs/blogs/SO posts to read more about this... I'm struggling to come up w/ the right keywords.
You might want to look at this extension: NuGet Reference Switcher for Visual Studio 2017
This allows you to switch between NuGet packages and project references during development.
Check out this blog post: https://markheath.net/post/multiple-nuget-single-repo
Basically, dotnet pack handles this for you automatically. You use regular project references when developing.
There must be a good way to handle this situation, no?
The best solutions is that the project-to-project reference should be recommend when the referenced project is modified frequently, the nuget reference is more appropriate when share the reference project to others or publish it. Just like NuGet Reference Switcher doing.
For some more detailed info, you can check following thread:
nuget packages in local work
NuGet has many advantages as a package manager for the Microsoft
development platform, this does not mean that it is not flawed. Just
as you encountered, if the referenced project is modified frequently,
we have to rebuild it, build nuget, publish it for each modification.
That will bring a lot of boring work. To resolve this disadvantages,
the Project-to-project references should be a better way.
The
advantage of a project-to-project reference is that it creates a
dependency between the projects in the build system. The dependent
project will be built if it has changed since the last time the
referencing project was built. A file reference does not create a
build dependency, so it is possible to build the referencing project
without building the dependent project.
You could add following Post-build event command to pack your project after building.
"the nuget.exe path\nuget.exe" pack "project path\NuGetPackageLibrary.csproj" -OutputDirectory "Your target path"
When your build successful, the package in target path will be replaced by the latest version.
I'm using the very latest ServiceFabric SDK (v1.4.87.9494) with VS2015 Update1 and the latest ASP.NET 5 RC1 update (v1.0.11125.0).
When I add an ASP.NET 5 WebApp to my ServiceFabric solution I am seeing an error in project.json that looks like this:
Unable to locate Dependency Microsoft.AspNet.Server.WebListener >=
1.0.0-rc1-final
I'm a super noob to ServiceFabric and ASP.NET 5, how do I go about debugging this?
This is a known (intermittent) issue that will be fixed in an upcoming SDK refresh. In the meantime, you should be able to work around it in one of two ways:
Option 1: In the web project, open project.json, make some kind of cosmetic change (add a space or a newline) and save it. This will force a package restore, which should bring down the WebListener.
Option 2: Explicitly add the WebListener package to the web project. Right-click on the web project, choose Manage NuGet Packages, then search for Microsoft.AspNet.Server.WebListener and install it.
If neither of those work, we've occasionally seen cases where having numerous NuGet package sources exacerbates this problem. You can try de-selecting all sources except nuget.org and that generally fixes it.
Add AspNetVNext to your NuGet package sources pointing to https://www.myget.org/F/aspnetmaster/api/v2/
I recently migrated all my Visual Studio 2013 projects to Visual Studio 2015 and followed the steps documented in this article by Nuget to make sure that automatic package restore is still working, in short
I deleted the Nuget.exe and Nuget.target files from source control and disk
I updated all project files and deleted the sections related to Nuget
I'm experiencing a problem when I'm updating Nuget packages, it is not updating the project references to point to the newest dll versions. I can see that the newest packages was installed though. This problem is also not related to specific packages.
Has anyone else experienced a problem like this?
NuGet package restore does not modify the project files. It just downloads and extracts the NuGet packages to the packages directory.
If you are trying to edit the packages.config file and then have the project's updated you would have to use the Package Manager Console and run:
Update-Package -reinstall
Which will uninstall and install the packages again and update the project's references.
We realized that some of our junior developers only installed the required Nuget packages for ONE project in the solution, they then added references to the required dll's for all other projects by browsing to the physical location of the dll's on disk. This obviously caused the problem because only ONE of the projects in the solution contained entries for Nuget packages in it's packages.config file while the remaining projects in the solution contained none.
When all packages were updated using the Update-Package command only the ONE project containing entries in it's packages.config file were updated with the correct project references.
Even though this is not a Nuget bug and rather a problem caused by inexperience, I logged an issue with Nuget to see if they can improve the software to prevent these types of problems.
So I recently had a very similar issue as well, unfortunately uninstalling and reinstalling did not work. Hopefully this helps anyone else as it was very frustrating.
Steps:
go to or launch the quick launch feature.
type package manager
select "tools->Nuget PackageManager-> Package Manager Settings"
In the options window that pops up. click "Clear All Nuget Cache(s)"
Right click solution and select Restore Nuget Packages.
Hope this helps.
I was facing an issue with NuGet package of Newtonsoft.Json as shown below:
I tried all possible solutions but none of the below mentioned ones worked:
Cleaning solution
Rebuilding solution
Clearing NuGet package cache
Finally I realized it had something to do with .NET Framework version targeted by my C# project. There was some mismatch it seems. The moment I upgraded the .NET Framework version of my project to latest, the Newtonsoft.Json package dependency and its reference came alive instantly.
Something I just noticed, and I'm not sure if this will help you or anyone else reading this, but this issue literally wracked my brain. The problem was that I was installing packages that I had created myself using NuGet Package Explorer on Windows.
It turned out that, I believe after updating NuGet Package Explorer, it was no longer putting DLLs that I included into the lib folder. Once I started manually adding the lib folder back into the package within Package Explorer, and then uploading to NuGet and reinstalling in the consuming project, that the reference would once again start to appear.
I'm not sure what caused this behavior - it could have been my own fault, but I literally just now figured this out - and consequently have to go back and re-do a whole bunch of NuGet package goodness that I've done over the past month. OUCH.
Hope this saves someone at least an ounce of pain.
None of the above worked for me.
What did work, was to edit the project file directly and delete the existing reference. When I reloaded the project, the package then showed up in references as a Nuget package.
I happened to come across the same problem. i tried all the possible solution but found the solution - just open the .proj file in an text editor and check the package Version and the HintPath in the Reference tag. Sometime there is an mismatch correct it then Visual studio will recognize. I hope everyone can save lot of time. Here is an sample to refer
<Reference Include="nunit.framework, Version=3.4.1.0, Culture=neutral, PublicKeyToken=2638cd05610744eb">
<HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
Migrating to PackageReferences worked for me for the projects that allowed it. My Asp.Net project could not be migrated, so I resorted to manually adding the references to the .csproj file
So I decided to take a look at this new Visual Studio 14 CTP. When I tried to add a package from Nuget library (Raven Database Server precisely) to my ASP.NET vNext Web Application, it felt like nothing really happened. Not a single piece of solution has changed, and the References remained the same.
I tried adding it manually using my "Project.json" file (as seen in this article), but IntelliSense didn't provide me with any fill. I actually tried it in a lot of different ways, with a whole lot of Nuget packages, with the same result.
Can anybody explain this situation?
ASP.NET vNext supports two targets: .NET 4.5 and CoreCLR. When targeting .NET 4.5 (net45) you can add any existing NuGet reference. When targeting CoreCLR (k10) you can only add NuGet references that support it; today, only some packages support that.
The package that you mention is only available for net45. To add a reference to it, add the package as a dependecy in the net45 section of project.json - just like autofac is added in this file
The entry should be: "RavenDB.Server":"2.5.2879"
PS: the manage NuGet references dialog is not functional for ASP.NET vNext projects in this version of VS
I just applied the Nuget patch for ASP.NET MVC4 DisplayModes and with it came a bunch of web dll dependency updates from 2.0.20505.0 to 2.0.20710.0, which have been updated just fine in my packages folder which is in my solution tree, the packages.config file and the .csproj file.
Trouble is though, the build and deploy don't pick up the new versions and just copy the old 20505 versions out of the GAC. Is there something I'm missing about how the packages are referenced? This is VS2010 SP1 and MVC4.
Thanks
Martyn
The NuGet packages themselves probably have little to do with the behavior you're seeing. The package.config file does have a version number for each package, and if that information is up-to-date, then NuGet is going to restore those versions of the packages when it's asked.
The problem is more likely to be with the deployment settings you're using, of which I know little. Of course, I should point out that build 20505 -- the build you have in your GAC -- is a release candidate version of MVC 4, and that it's probably in your interest to go ahead and upgrade to the final build, which has since been released.
HTH,
Clay