In Visual Studio 2012 I created an ASP.NET MVC 4 project where the target framework is the .NET Framework 4.5. When I deployed my project to a web server it gave the following error:
Could not load file or assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file
specified.
Description: An unhandled exception occurred during the execution of the current web request.
Please review the stack trace for more information about the error and where
it originated in the code.
Exception Details: System.IO.FileNotFoundException: Could not load file or
assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The system cannot find the file specified.
Source Error:
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34237
I had the same issue today during deployment. I was able to fix it by marking the assembly to be copied to the deployment file.
In order to do this, in my Visual Studio project, select the System.Web.Http.Webhost assembly in your references and alter the 'Copy Local' property to True. I had to repeat this for a few other assemblies that were missing.
Thanks to this website for the tips - http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx/
Check the bin folder of your deployed project. It should contain System.Web.Http.WebHost.dll.
If this dll is in this folder, check it version. If it isn't 4.0.0.0, then you should deploy version 4.0.0.0 or change your web config to use other version (not really good idea because of dependencies)
Try to reinstall Microsoft.AspNet.WebApi package. Open Package Manager Console and type:
Update-Package Microsoft.AspNet.WebApi -reinstall
Be careful, this command will remove all dependencies and you will have to install them manually.
I had this error with an old project that I was going back to do a bit of work on. It turns out the project wasn't actually using WebApi so I uninstalled Microsoft.AspNet.WebApi using NuGet. That solved the problem for me.
If I'd actually have needed WebApi I'm sure installing it again would have fixed the error too.
I ran into this today after setting up a new Team City Build Agent. The new agent didn't have MVC 4 installed, perhaps part of the problem. Fortunately, I found this article which lead me to the solution. In Team City, I just updated the Build Step for the Nuget Restore so that it doesn't use the local cache.
This works because the cache may have been established by build runners with different (MVC) frameworks installed already.
I know this is answered but I thought I'd add something.
Every time I set "copy local" to true on a file causing the error I'd publish it and just get another one. So I just selected all of the files under references and set them all to true. This fixed the issue for me.
Important: This error message can be caused because you are deploying a 4.5 project to a server that doesn't have 4.0 installed. Make sure you have the .NET Framework version installed in IIS for the project you need. Some of these DLLs by default won't copy up, because it uses the core project DLL normally. Check to make sure your production server has the .NET version you're going with. I experienced this myself with a 4.5 project on a 4.0 server.
Ensure ASP.NET MVC 4 is installed on your server. Check it in the following location -
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4
Related
I have a web in ASP.Net Core (4.6.1 framework) that uses Facebook and MS external login that I created with Visual Studio 2015 and opened in the new Visual Studio 2017 that came out yesterday. VS2017 made a few changes related to the csproj, project.json, etc files.
The site compiled and executed fine except for one part. If I did a Facebook or Microsoft external login, the site displayed this trap:
FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
System.Net.Http.WinHttpHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
AggregateException: Unhandled remote failure.
Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler+<HandleRemoteCallbackAsync>d__6.MoveNext()
The url in the browser showed that it was attempting to return from the external login to the local (https://localhost:44321/signin-facebook?code=... or /signin-microsoft).
The version number of the System.Diagnostics.DiagnosticSource.dll (and System.Net.Http.dll) is 4.6.24705.1.
I started a new VS2017 project from scratch with Facebook and MS login added and it worked fine - getting me logged on without the trap. The dll's were the same versions.
Comparing the two csproj files showed differences but nothing obvious (nothing related to System dlls):
What solved it for me was to add a NuGet reference to System.Net.Http (version 4.3.1) to the newly migrated project.
https://www.nuget.org/packages/System.Net.Http/
The recommended answer did not resolve my issue. I was getting this error when trying to reference a .Net 4.6.2 lib in a .Net Core 2 project.
To resolve the issue I had to add the Microsoft.Windows.Compatibility nuget package.
Credit to: https://medium.com/#ans_ashkan/asp-net-core-and-windows-event-log-75770a80a666
In References 'System.Diagnostics.DiagnosticSource' not included in solution
On installing latest version "5.0.1" of 'System.Diagnostics.DiagnosticSource' in NUget solved my issue. Hope it will fix yours also.
I had the same issue and weirdly enough, problem resolved with updating Microsoft.ApplicationInsights versions. 2.20.0 is the version to go (for me). I don't know the connection between these packages but that's what happened.
People using .NET Core web applications monitored with Application Insights hosted in App Services facing this issue
This when .NET Core web application has a dependency on 'System.Diagnostics.DiagnosticSource%u2019 binary and has this binary file deployed to /wwwroot/ folder, which is rare.
Work Around: Please set previous version of monitoring extension by changing this app setting if you experience the above issue: ApplicationInsightsAgent_EXTENSIONVERSION=2.8.24
After doing this please restart the application.
Here is the source
With developing an custom MSBuild Task with Visual Studio 2017 RC, I have the following problem: As soon as I add other dependencies than just Microsoft.Build.Utilities.Core (using v15.1.0-preview-000458-02 for .NET Core Support), I cannot load the task into another .csproj MSBuild project as the dependencies are not found.
Is there a way to automatically copy all dependencies to the Debug folder?
Or do I have to publish it every time I want to test it?
Update1:
The problem with publish was something local to my environment and has been fixed.
Update2:
It seems that as soon as I change the TargetFramework from netstandard1.4 to netstandard1.6 it isn't even able to load the task at all. As soon as I use netstandard 1.6 it throws a an exception:
The task could not be loaded from the assembly.
Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies.
Is there a way to automatically copy all dependencies to the Debug folder? Or do
I have to publish it every time I want to test it?
By default and for good reasons, .NET Core and .NET Standard projects do not copy referenced assemblies into the build folder. Instead, they are resolved them from the NuGet cache.
But if you really need it, this behavior can be changed by overriding the default with the CopyLocalLockFileAssemblies setting.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Cref: https://github.com/dotnet/sdk/blob/d20405f91a2959fa91fea6285d9a896286727f2a/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.BeforeCommon.targets#L55-L56
Second question
It seems that as soon as I change the TargetFramework from netstandard1.4 to netstandard1.6
To build a task assembly that works on both "MSBuild.exe" and "dotnet.exe msbuild", you should target netstandard1.4 or lower. netstandard1.6 is not compatible with .NET Framework 4.6.1 (which MSBuild.exe runs on.)
If you need API not available in netstandard1.4, you will need to cross-compile your task for .NET Framework and .NET Standard, which is considerably more complex but can be done.
I just installed Ninject.MVC5 into my solution (I have an MVC project and a WebApi project in there and I wanted Ninject for both).
Then I installed WebApiContrib.IoC.Ninject to build on the previous install so that I could use Ninject in the WebApi package.
Then I updated the packages (because NuGet showed updates to install - even though I had updated the packages directly prior to installing Ninject).
I tried running my WebApi project but it failed on var kernel = new StandardKernel(); in NinjectWebCommon.CreateKernel() with this error:
An exception of type 'System.IO.FileNotFoundException' occurred in Ninject.dll but was not handled in user code
Additional information: Could not load file or assembly 'System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Having read several answers on here and contemplated certain relatively complex solutions I tried one more thing which I will share in the Answer in case it helps anyone else...
I removed WebApiContrib.IoC.Ninject from the WebApi project (via NuGet: Manage and then untick to remove) and then added it back.
Project runs and behaves as expected, and no updates are required after adding WebApiContrib.IoC.Ninject back in to WebApi project.
The update that NuGet identified as required overwrote/broke something that was fixed by this answer.
Add the package Microsoft.Aspnet.Mvc from Nuget.
Solved for me.
In my case, MVC4 for Framework 4.0 and Visual Studio 2017
We're having the seemingly common error
Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
in a project that needs to be compiled against .Net 4.0 but is built on a build server running Windows Server 2012 (with .Net 4.5). The project is a web application that gets deployed to a web server running 2003, where installing .Net 4.5 isn't an option. There it runs against "classic" .Net 4.0
From similar questions, we're trying command-line options to MSBuild:
/property:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
We also tried various combinations of
/property:ReferencePath="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
/property:NoStdLib=true
/property:NoCompilerStandardLib=true
The reference assemblies (including the .dll files) are in fact installed in that place on the build server. But when we deploy the website and visit the home page, we get that error. (Interestingly, on a page reload, the error disappears, and the site operates normally.) What are the MSBuild parameters necessary to compile against the .Net 4.0 assemblies?
Update
I turned on ludicrous-level logging on MSBuild, and I see that apparently it is building against the .Net 4.0 reference assemblies:
Resolved file path is "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
and I didn't see any mention of assemblies outside that folder or the build server's working directory. So it appears to compile properly, but when deployed on the web server, it throws the exception.
As to the exception going away on a page reload, I wonder if that's related to the markup pre-compile step. We're running aspnet_compile on the build server. Maybe if there's an exception coming from a generated assembly, the web server will re-compile it. And the recompiled assembly is fine, because it was created with true .Net 4.0.
Well the answer turned out to be borderline embarrassing. After we confirmed from detailed MSBuild output that it was in fact building the website project against the right reference assemblies, we realized that there are several in-house NuGet packages in the project that had been built against .Net 4.5. One of them was chock full of extension methods, which is what causes the exception. Rebuilding them against .Net 4.0 fixed the problem.
Which brings up an interesting issue. If a 3rd-party NuGet package is compiled for 4.0 but using 4.5 references, we'd be in the same situation, but not able to fix it. So the lesson for package publishers is to ensure your 4.0 version is compiled against the reference assemblies.
I have a project that works great on my machine (and production servers).
It's a VS2010 project running C#3.5.
When letting my build server build the solution it can't resolve a couple of my third party dll's.
Error message:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1360,9):
warning MSB3268: The primary reference
"Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" could not
be resolved because it has an indirect
dependency on the framework assembly
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" which
could not be resolved in the currently
targeted framework.
".NETFramework,Version=v3.5". To
resolve this problem, either remove
the reference "Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" or
retarget your application to a
framework version which contains
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a".
[d:\Builds\3\mySolution.sln]
Everything compiles and runs great on my machine, but the build server seem to struggle.
I think the Third.Party.Assembly is written in VB.net.
Since the assembly is third party I can't remove the reference to "Microsoft.VisualBasic.Compatibility" and since I don't get any warnings on my computer could it really be that I'm running v3.5?
Any suggestions?
/Jimmy
If you put your project on the build server manually will it run? Based on the error message, I would make sure you have the latest .net framework installed on the build server machine and give it another try. If that does not work try installing VS2010 on the build server just to get the builds running until you find out just exactly what assemblies you are missing.
So, I was having this issue also on a VS2005 project that we upconverted... The issue is that MS has never had a 64-bit version of the VisualStudio.Compatability DLL. Our issue was that we were targeting 'Any' CPU and building on a new W2008R2 server so it was using the 64-bit version of the .NET 4.0 Multi-targeting pack.
In the build properties under the 'Process' tab under the '3. Advanced' there is a 'MSBuild Platform'. Change that value to "X86" and it might work... assuming of course you aren't depending on any 64-bit libs...