I've recently started using NuGet in VS2015, and I have come across the problem where when trying to use 'NLog' I am getting a missing assembly error in my project.
I have previously used NLog via NuGet in another projects with no problem but this time it is not working.
In my using statements
NuGet package manager;
NLog correctly appears in my references
As you can see, I'm also using other packages such as Oracle data access, and this works fine with no issue, it is just NLog where it does not work.
Now I have tried to;
Uninstall and re-install of NLog package (with shutdown of VS inbetween, and cleaning solution, and even reboot of machine) - multiple times
Uninand re-install of NuGet packagae manager (with shutdown of VS inbetween, and cleaning solution)
I have looked in the following files, but can't see any differences compared to last use of NLog in another project which was successful.
App.Config
my project.csproj
packages.config
And NLog does appear in the \packages folder
Any ideas what the issue could be and what I need to do to fix the error?
Ok, so it seems that after spending hours on this over 2 days I finally managed to resolve the issue myself within a few minutes of posting on here!
The problem was confounded by the fact that I had one solution with 2 projects.
Project 1 didn't have NLog installed
Project 2 did have NLog installed
I thought that NLog was only being used from Project 2, and hence why the package was only installed here. But Project 2 had a dependency on project 1 and it turns out that it was through this dependency that NLog was also used in project 1. As it was a static reference then it didn't help me to track it down.
So I had to install NLog for both projects. Once I done this, then the issue went away.
Thanks anyway to all your help
Try using Shell , you must Open the solution :
1)`Uninstall-Package NLog` : Don't forget to delete Obj Folders manually
2)`Install-Package NLog` : Be sure you install the NuGet on the project you are working on
Related
I'm currently running into an issue (on Visual Studio 2022) where the test project within my solution is referencing a few other projects in my solution; however, trying to build the test project results in errors for these project references. Even more interesting is that this test project used to be working fine.
So far I've:
Double checked the pathing of the project dll's being referenced
Removed and re-added the project references.
Editing the file, Intellisense is able to find the references, but when building the console output shows errors.
Cleaned the solution
Seen recommendations online of clearing the Temp folder and AppData\Local\Microsoft\VisualStudio\17.x\ComponentModelCache for my user account and have done so
None of this has helped. Any guidance on what to research or things to try/insight to the problem would be much appreciated!
Thank you
-Austin
EDIT 1 (7/5/2022)
Error List Image
The error seem to resolve themselves when I click on them from the Error Lists (after viewing the place in the file where the reference error is occurring, the error disappears after a few seconds, removing it from the Error List and also the removing the red squiggle underline). However, the error does not actually resolve as there are still the same reference errors when trying to Build the test project.
For example, STEP.Entities is a project in the solution that is referenced by the test project. However, the test project can't find the referred Entities project.
I realized the issue was caused by packages used in the other projects of the solution were targeting different .NET versions than the same packages within the Test project.
(Firstly, to determine this I went to Tools > Projects and Solutions > Build and Run > select MSBuild Project Build Verbosity as Diagnostic. (I believe this generates more a detailed report of the status to the Output Console when building projects)).
Specifically, a lot of these packages in my test project were targeting .NET v 4.8 as opposed to v4.7.2 being targeted by packages in the other projects, and the Test project itself and other projects targeting v4.7.2. I updated my Test project to target v4.8 and everything works/references can be found.
I've had this problem recently with a project from GitHub, my best sugestion is to try checking the version you are using and maybe select an older version of the said references.
It took me a while to get it done but it worked.
I think I worked around this with following global.json in the root of my drive:
C:\global.json
{
"sdk": {
"version": "6.0.300",
"rollForward": "latestFeature",
"allowPrerelease": false
}
}
Or there might be a global.json in your solution somewhere, with a .NET SDK version that doesn't exist...
To list all installed .NET sdks on your computer, run
dotnet --list-sdks
and pick the correct version.
I have some trouble with running my project. When I try to run, the following error appears:
FileNotFoundException: Could not load file or assembly 'Dapper,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. The system cannot find the file specified
Context:
I have a Class Library X and a Web Application Y which have dependencies on X. When I try to run my API project, it throws the above error.
BUT, when my colleagues try to run the same API project, it works fine (no errors, and in /bin folder, it loads all the .dll libraries..)
I did those approaches:
Restart Visual Studio, clean and build a solution
Remove the class library references and add it again
Tools > Import and Export Settings Wizard > Reset all settings (maybe some setting was not well configured). I also tried to import colleague settings and didn't work either.
I tried various approaches(even in a different machine, but same VS settings) but none of these worked for me.
Visual studio 2019 16.4 Enterprise.
I'd also try:
1) Deleting your bin and obj folders in your solution before a rebuild.
2) Check that you've not got multiple versions of the same package across the solution (right click on solution in solution explorer -> manage nuget packages for solution).
3) Check that the properties of the reference (right click in solution explorer on the reference in question) shows a path to the package that you'd expect relative to the solution (eg not in mydocuments/nuget packages or something!).
4) Try a fresh clone of the repo (this should in effect replicate your co-workers' set up) and see if the problem still exists then.
I suppose another cause could be that your coworkers have a locally installed package / dll that they're happily referencing without realising, but you don't have?
When you copy a project from someone or another system, you need to download and install all components. normally VS will give you the option to "restore packages" when you load a newly imported from git but not sure if it does when you open an existing solution from a different system.
Right Click your project, Manage Nuget Packages
Browse -> Search for Dapper. Install
In the error you receieve, it tells you what version of the package should be installed as well. Installing a significantly different version might cause other unexpected errors.
thank you for your solutions but I found the problem:
The project solution has some projects with .net standard 2.0 and some with .net framework 4.8. Somehow, when I run the app, some packages are not loaded correctly and it throws an error.
That line below solved my problem:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Put it in all .net framework 4.8 projects on first XML tag.
Thank your for all.
Regards.
I had exactly the same Dapper error message today when referencing a .Net Standard 2.1 class library in a .Net Core 3.1 WinForm app. My resolution was to double-click the class library name in Solution Explorer to open the .csproj file, and then add a CopyLocalLockFileAssemblies tag to the PropertyGroup tag and setting it to true.
Some background:
At my company, I have been working the last few months with converting our C# libraries to function on .dll references instead of project to project references. To do this, we have created a local NuGet server which contains NuGet packages for all of our libraries projects. We have Jenkins jobs set up for every project which build new NuGet packages and add them to the server every time a change is made to one of them.
For working on a single project, this system works great. You only have to worry about updating your packages folder through Visual Studio's NuGet manager, and then the rest is just writing code and building.
The issue:
When you add a new reference, or update your packages through NuGet, NuGet automatically specifies that specific version of the project that you selected in NuGet. With the current system I have setup, rebuilding a project locally will then replace it's .dll in the packages folder so that all projects that reference it can see these new changes you're testing. However, the issue come in that locally built projects have a different version than our Jenkins built packages. Our local builds use a different versioning system from our Jenkins builds so that you can easily tell whether something was built using Jenkins, or if some of the .dlls came from a developer's build. Because of this different versioning scheme, the reference of projects to the project breaks, because the new .dll that was built locally has a different version than the .dll that was retrieved from the NuGet server.
Current Solution:
For the moment, I have resolved this through the addition of a pre-build step. Before every project builds, the project calls one of my PowerShell scripts, which goes through and adds <SpecificVersion>False</SpecificVersion> to every project reference in the project being built's .csproj file. This resolves the issue, but only in the sense of putting a bandaid on it. Instead of dealing with the consequences of the system, I wanted to prevent them ahead of time so that this isn't needed every time a project builds. I have tried researching a lot about NuGet packages specific versioning issues, but have not been able to find anything online even remotely close to what I am asking. This makes me think that I'm going about this wrong.
The question:
What can I do to solve this issue? Or am I doing something very wrong and dumb that could be easily avoided by using another system? Any suggestions or tips would be greatly appreciated
I'm creating a .NET Core xUnit test project library in VS2017. I accidentally installed the System.Collections.Immutable NuGet package, and now I want to uninstall it.
First, I tried editing the csproj file and removing this line:
<PackageReference Include="System.Collections.Immutable" Version="1.3.1" />
That didn't work, since the types from that package were still highlighted in the editor. So I tried running Uninstall-Package System.Collections.Immutable in the Package Manager Console.
The console said it couldn't find the package, so I tried putting the <PackageReference... line above back and running Uninstall-Package again. The console said the uninstall succeeded, but VS still recognized the types.
I tried closing VS, deleting .vs/, and reopening. It still recognized the types.
I tried git stashing my changes, running git clean -xdf, and running dotnet restore from the command line. Somehow, it still outputs
$ dotnet restore
Restoring packages for C:\cygwin64\home\james\Code\cs\BlockList\src\BlockList\BlockList.csproj...
Restoring packages for C:\cygwin64\home\james\Code\cs\BlockList\src\BlockList.Tests\BlockList.Tests.csproj...
...
Installing System.Collections.Immutable 1.2.0.
Installing System.Collections.Immutable 1.3.0.
...
I also tried restoring from Visual Studio instead of the command line. Still no luck.
When I searched all the files in my repo for the word Immutable, the only thing popping up is project.assets.json in the obj directory. Not a single source file contains the word Immutable. I'm confused, then, as to how it's still being referenced. How can I uninstall it?
A few other things:
I checked the 'Dependencies' drop-down for my project in Solution Explorer, and it's not listed there.
I don't want to delete my local copy of the repo and re-clone it, since I have other work stashed.
System.Collections.Immutable.dll doesn't show up at all in the bin/ directory, yet when I use one of the types in my library and run it, it works fine.
Thanks!
edit: Adding this line to the library:
System.Diagnostics.Debug.WriteLine(typeof(ImmutableArrayExtensions).GetTypeInfo().Assembly.Location);
And running it says that the assembly is located in this location:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.1.2\System.Collections.Immutable.dll
After about an hour, I found out what the problem was. My .NET Core library referenced Microsoft.NETCore.App, which referenced System.Collections.Immutable. I looked at the dependencies for the former, but overlooked System.Collections.Immutable because that package references maybe 50 other packages. I ended up finding this out by creating a brand-new xUnit test project, and trying to see if ImmutableArray<> was present without installing anything. Sure enough, I could use it out of the box.
I had a similar issue with VS2017 and a different nuget package that wouldn't fully uninstall. I ultimately had to create a new project and cut and paste all my code into it. Kind of a sledge hammer approach, but faster than crawling through dependencies.
I'm having a particularly difficult refactoring session involving a C# solution with multiple projects in Visual Studio 2012. I needed to pull out a bunch of code into their own assemblies so that code could be shared across several projects, all in the same solution. However, no matter what I try, I get warnings for the projects that reference the new shared projects that "All projects referencing {shared project name} must install nuget package Microsoft.Bcl.Build".
I have been over the dependent projects and the shared projects with a fine-tooth comb, verifying in detail that they all use the same version and exact same DLL for the Microsoft.Bcl version 1.0.1.19 and Microsoft.Bcl.Async version 1.0.16 packages:
System.Runtime
System.Threading.Tasks
Microsoft.Threading.Task
Microsoft.Threading.Tasks.Extensions
Microsoft.Threading.Tasks.Extensions.Phone
The DLL paths are all resolved and identical. The XAP file does build but I still get that warning telling me that Microsoft.Bcl.Build is not referenced in the dependent projects, despite the fact that I can see that it is.
If I try instead to uninstall and then reinstall those two packages using NuGet for each project involved, I get references with empty paths and the warning icon for the 5 DLL references involved. For some reason NuGet adds the references but can't find the DLLs. Also, if I do this, I find myself with the problem frequently of having projects where I get the "Can't add reference" error when trying to add a reference. Then I have close and re-open the solution, and that leads to a "project failed to load" error. So I have to edit the project file manually, remove the faulty package import statements, and reload the project.
How can I fix this problem and what is the general technique for avoiding this headache in the future? Letting NuGet manage missing packages didn't help at al.
In case anyone else comes across this and #Swell's solution made you go "wtf":
I recently went through an older MVC project and updated it (updated razor, asp, http, etc. nuget packages). The project, independent of itself, built fine, but when i went to publish it failed with the OP's errors.
It turns out it's because I didn't update the *.Tests project associated with it (should have figured, though not sure why Tests is that closely tied to the project). So, to fix:
Right-click the Solution and manage nuget packages.
Go through all the packages that were updated in the web project and apply them to the other projects as well (each "Update" will display a tree with the applicable projects, I was fine just OKAY-clicking through).
Rebuild.
You should now be good and it shouldn't bark at you. Hope that helps others.
I just came throught the same issue and a bug is opened here: http://nuget.codeplex.com/workitem/3268
What I've done is the following, I added to the solution level the package Microsoft.Bcl.Build
In my dev env if you don't have the package loaded, just right click the solution and select manage nuget packages, you see a yellow bar with a restore button, just click it and you will be fine.
In my build script before compiling the project I run this command:
.\myproject\.nuget\NuGet.exe install .\myproject\.nuget\packages.config -OutputDirectory .\myproject\packages
This will restore solution level packages and you will be fine.
This should be fixed by the end of this summer in version 2.7 according to the issue report