I'm referencing System.Web.Http.dll, full path:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Http\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Http.dll
However, I'm getting a compile exception saying that it can't find ExceptionHandling in the System.Web.Http namespace.
The type or namespace name 'ExceptionHandling' does not exist in the namespace 'System.Web.Http' (are you missing an assembly reference?)
Looking in the file, it is indeed not there.
I have been updating NuGet packages, so I'm assuming it's been moved\replaced with something.
Where do I need to go now to get this namespace? The internet seems quite quiet on this.
OK, the solution was odd. Not sure how the project ended up in this state.
The fact that the reference was pointing to C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Http\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Http.dll showed that it wasn't using the assemblies provided by the package, which were in the packages folder.
I had to explicitly delete the references, then roll back the version of Microsoft.AspNet.WebApi.Core as VS wouldn't let me uninstall it as the project wouldn't compile (at least I assume that was why, never had that before though).
That re-added the assemblies with the correct paths, that being, paths to the packages folder.
I also stuck and your suggest solve my problem
my step is here
remove Reference System.Web.Http
remove Nuget Microsoft.AspNet.WebApi.Core
restart Visual Studio
try to install Nuget Microsoft.AspNet.WebApi.Core again
Related
I have a project with assembly which refers to System.Threading.Tasks.Extensions, Version=4.6.28619, It's an old ASP.NET App hosted on IIS. After compilation, the app is running and everything is OK. After some time, the app throws an exception.
"System.Exception: Could not load file or assembly
'System.Threading.Tasks.Extensions, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51.
After the recompilation and restarting the APP, everything works fine, but after a few hours, the exception is thrown again. What could be the problem?
I have tried to change web.config to use System.Threading.Tasks.Extensions in the correct version, but it didn't help.
Version=4.6.28619 is file version, not the Assembly Version. I did goodle on System.Threading.Tasks.Extensions history.
I found the 4.3.0 should be the correct version in your project.
Other version couldn't find 4.1.0.0 version dll like picture above. Package version >=4.4.0, using 4.1.1.0. <4.3.0, using 4.0.0.0.
Now you can follow the suggestions below to check the issue
Find the package System.Threading.Tasks.Extensions like my first picture.
If you have multi project, make sure all the projects using the same version package.
Delete the .vs folder
Check the web.confg/app.config file, and check the version of System.Threading.Tasks.Extensions, if there are duplicates, please delete them.
If the steps above not works for you, maybe the issue related to deployment. You can try the binding redirects.
I have pulled an in-house NuGet package's source into a new class library project of my solution, removed all references to the original package and referenced the class library. The solution builds just fine but when I run it I get the classic...
Could not load file or assembly 'Standards.Environment, Version=12.8.0.0, Culture=neutral, PublicKeyToken=e1f2345a678912bc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I've searched SO and tried the solution here: How to resolve “Could not load file or assembly... to no avail.
What I don't understand is that I get the above error even though the AssemblyInfo.cs of the Standards.Environment class project contains these lines:
[assembly: AssemblyFileVersion("12.8.0.0")]
[assembly: AssemblyVersion("12.8.0.0")]
Have I forgotten to do something when migrating the source code into my solution?
EDIT I have discovered that one of the other in-house NuGet packages is referencing the same package which I have removed (because I migrated its source into the solution.)
How can I force the other NuGet's DLL to accept the DLL of the class library as the dependency it is looking for?
The cause of the problem was that I had removed a NuGet package which contained the DLL which another NuGet package was looking for. When I migrated the original NuGet source into my solution it broke the references.
The solution was to switch back to using both NuGet packages and let them sit happily alongside each other OR import both.
Not particularly happy with this, but reverting back to a previous version of the solution and solving the real problem (an unrelated bug) was easier once I understood this.
I install the SQLite from Nuget as below:
And after I ran the program it throws this error:
I feel strange that it showed the Version is 1.0.109.0 but not the version I installed which 1.0.109.2
What's more, I tried the way what Could not load file or assembly 'System.Data.SQLite, Version=1.0.109.0 - Why does it search for version 1.0.109.0 when I have referenced 1.0.109.1
said
But all the way no works.
In addition, I opened the .csproj and here is the SQLite package reference:
The version in .csproj is right.
What's wrong with it.Would you please tell me how to solve it? Thank you.
Make sure that the SQLite assembly gets copied to your output directory so it can be found at runtime. It should if you install the SQLite package in your UWP app project.
I am running a 4.6.1 .NET Azure API. I'm trying to debug it locally, and I get this error.
The exact error says
Could not load file or assembly 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Now, I have searched for the standard responses. I checked my package config first:
Sure enough, it's the right version of 1.0.2. I then checked my reference to make sure my version is what it says it is.
So I check my local assembly just in case as well. Looks on point.
So what am I missing? Where else could it not match? The only solution I have found is to point the project's build settings to 'bin\' versus 'bin\debug', but that feels way too hacky.
What worked for me was simply uninstalling that package: Microsoft.CodeDom.Providers.DotNetCompilerPlatform
The code worked just fine with out it in my case. I was able to re-install the package and the code continued to work just fine as well. Git seems to think all the package files that came back are different to those that were there before uninstall.
I'm not sure why this worked, but it got me developing again.
I have a web api project that is working fine in my local machine. After I pushed it to GIT on Visual Studio Team Services, created a build definition (with Restore NuGet packages enabled) and queued a build, i get the below error:
The type or namespace name 'Practices' does not exist in the namespace 'Microsoft' (Are you missing assembly reference?)
I have tried building with "Keep Local" property both true and false & "Specific version" property both true and false for the CommonLibrary references. Any combination for these two properties is resulting in the same.
I had a similar problem with VSO build and Azure packages:
The problem was solved by reinstalling the packages for the projects.
In the Package Manager Console:
Update-Package -Reinstall
This is how i resolved it. I made sure that the same libraries referred in packages.config file in all five projects of the solution have same version number. (In most cases, i re-installed from NuGet manager). In the Git branch, i deleted the packages folder so that the libraries are restored afresh. That did the trick. The build passed the next time.
I had exactly the same symptoms, but in my case it turns out that although I could see the package listed under 'References' for my .Web project and all ran OK locally it wasn't actually installed.
Installing the package via the NuGet UI worked for me.