I got an issue working with Nuget packages and local projects.
I am working on a .Net Framework solution, with many projects and many of them are packaged with Nuget in a private repository. I am using PackageReferences to resolve nuget packages. I am working on solution with that kind of dependency tree.
StartUpProject
Project1(LocalProject)
Project2 v1.0.0(NugetPackage)
Project3 v1.0.0(NugetPackage)
Project3 v1.0.1(LocalProject)
When I want to debug or upgrade functionality of packaged project, I remove Nuget package and add that assembly as local project.
When I am navigating in the source code if I try to go to some function from the modified project, Visual Studio open the code as external assembly and does not resolve like local project.
Maybe the problem is other Nuget package (Project2) depends from I removed Nuget package (Project3) and Visual Studio still resolving that assembly as Nuget package.
The error that Visual Studio throws at compilation is CS0433: The type 'MyType' exist in both'Project3 , Version=1.0.0, ...' and in 'Project3, Version=1.0.1, ...'
What is way to work in that cases?
Is any way to force to use local project than dependency nuget package?
Thank you!
Related
We have a solution with 7 to 8 different projects including class libraries and mvc apps. We are using .net 4.6.2 and netstandard 2.0.
We are trying to convert class libraries to nuget packages and instead of referencing the projects directly in our web apps, use nuget packages. We have created the packages and added them in packages.config and the packages are getting installed perfectly fine.
Now, when I remove previous reference and add a new reference and point it to the nuget package, my web apps doesn't work and give assembly not found error.
I think I'm not adding the reference correctly , and need help on this.
If you are using NuGet packages now then you would install the package into each project which needs the assemblies and NuGet will add the references for you. You don't add the references by adding them from the packages directory.
E.g. Install-Package MyPackage MyProject
Background: I am using Visual Studio 2019 Professional Version 16.11.15, and NuGet Package Manager 5.11. I was provided some 3rd party assemblies to use for my .NET Standard 2.0 class library. These dlls were installed locally on my machine by an installer. I added them to my project via "Add Project Reference". Here's a screenshot of them working.
Goal: Create a NuGet package for my .NET Standard 2.0 class library to be used internally by our dev team. It should encapsulate these 3rd party dlls as part of it. But I keep running into dead ends.
Important note: Xceed does not host these .NET Standard assembly versions on nuget.org, purposefully making my life difficult it seems...
I have tried:
Using the "Generate NuGet package on build" in the Package section of the project properties. This option does not attach the 3rd party assemblies with it. This includes setting the Copy Local option to "Yes".
Adding these 3rd party dlls to their own NuGet packages via NuGet Package explorer following this answer. I tried several different flavors of folder structures:
placing the dll at the root
placing the dll inside a "lib" folder
placing the dll inside a "lib/netstandard2.0" folder
None of these options worked when adding the NuGet packages to my project. The references to the assembly namespace weren't resolving in the code.
Has anyone had any success doing something like this before?
It turns out I was running into the problem of the NuGet packages not refreshing when updating it. I followed this the first part of this answer to solve that.
When using the folder structure "lib/" inside the NuGet package, I was running into this warning:
Warning NU1701 Package 'Xceed.Document.NETStandard 2.3.2' was restored using
'.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2,
.NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1,
.NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8'
instead of the project target framework '.NETStandard,Version=v2.0'.
This package may not be fully compatible with your project.
Once I updated to use "lib/netstandard2.0/" inside the NuGet package, I was able to add the NuGet packages to my library successfully and compile. Great success!
I installed some ASP.NET packages (FirebaseStorage.net if it matters) via Nuget in my game's project in Visual Studio.
Visual Studio itself shows no errors, as it probably understands using Firebase.Storage internally, but when it comes to Unity, it says
The type or namespace name 'Firebase' could not be found (are you missing a using directive or an assembly reference?)
I believe this happens because I installed this package through the Nuget Package Manager, inside Visual Studio, and it probably has nothing to do with Unity, so Unity doesn't find it.
How can I make Unity understand packages from Nuget?
If you want to use a Nuget package in Unity you have to add it manually.
How you can do this:
create a separate temporary Visual Studio project
install the Nuget package
copy the dll's from the temporary project to a "plugins" folder in the Assets folder of Unity.
Unity now builds the project with the dll's of the Nuget package
However, now comes the hard part of having to do it manually: if the dll has dependencies on other dll's, these will also have to be added manually. That is the big advantage of Nuget package manager.
I have a solution with two projects - a primary project, and a unit test project. When opening in Visual Studio 2015 all references are found and project builds successfully. When opening in Visual Studio 2017 several but not all NuGet package references are not found and compile fails. Some of the failed references are...
System.Data.Common
System.Net.Http
System.Net.Http.WebRequest
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates
... but other NuGet references are found with no problem. This solution was created with VS2015. When viewing the .csproj file nothing out of the ordinary is jumping out.
I am thinking of rebuilding it from scratch in VS2017 to try to identify the problem.
Has anyone else experienced this problem, and/or has anyone any suggestions on why this is occurring and what should be done to facilitate a fix?
Update:
I created a brand new VS2017 WebApi project referencing .NET 4.7.1, and compiled successfully. I then added NuGet package System.Data.Common 4.3.0. The NuGet install process appears to have completed with no errors, but still I am left with an invalid reference. That was pretty easy to replicate.
OK, answering my own question.
I found what I believe is the answer. This particular project was originally developed in VS2015 using .NET 4.6.2. When changing to VS2017 we elected to upgrade .NET to 4.7.1. The problem is with the .NET version, not the VS version.
The newer version of .NET has many of these NuGet assemblies added to standard libraries. The NuGet packages were in conflict with the native .NET 4.7.1 namespaces. For example, in .NET 4.7.1, the namespace System.Data.Common is found in the assembly System.Data.dll. No longer is it required to add a NuGet assembly System.Data.Common.dll. In fact, if I do add System.Data.Common NuGet package assembly, I now have two assemblies having the namespace System.Data.Common - one in System.Data.dll and another in System.Data.Common.dll - hence the reference problem.
The solution is to use the .NET 4.7.1 version and remove the extra NuGet assembly. This was also true for System.Security conflicts. The conflict with System.Net.Http was actually moved into a NuGet assembly called Microsoft.AspNet.WebApi.Client.
I hope all of this helps someone else...(uhhhgggg)....
BTW - it appears that when using VS2015 with .NET 4.7.1, these conflicts are suppressed and never display. This feels like a shortcoming of VS2015. Glad VS2017 shows them to reveal the true problem...
Check your packages.config file to make sure the Nuget packages are actually listed as dependencies for your project.
Also, open the solution in VS 2015 and double check the file path for the references in question. Make sure the DLLs are not referenced from a file path unique to Visual Studio 2015.
I had to create a new project and transfer all the necessary files from the old project to new project to fix this.
I am creating a NuGet package from one of my projects using -IncludeReferencedProjects.
When I check the nupkg afterwards with the NuGet Package Explorer I see all referenced libraries inside the lib folder.
After installing the package in another project one of the before mentioned projects is not referenced.
I don't get any error messages when installing or packaging. Does anyone have an idea, what might cause this or is there a way to debug it somehow?
The Nuget package is hosted in our Team Services repository.
I found the answer. The problem was that the assembly name was ending with .Resources for some reason .Net or Visual Studio or NuGet can't handle that.