I am trying to run a project on my system (the project is in mvc and azure ).
i am able to build the project but it is showing error on run time .the error message is as following :-
Could not load file or assembly 'System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Check the .net version in your IIS app pool. Also check the target version in your project properties and make sure you are targeting the same version your IIS app pool is configured for. You should be targeting 4.0+.
The likely problem is the target machine doesn't have the target assemblies installed.
You should make sure you have .NET framework v4 installed.
This shouldn't be happening on the same machine which the solution was built, as the assemblies are required during the build process.
This is a common-case that, I don't know who downvoted this question, but just because you don't know what this guy is talking about doesn't mean the question is invalid, of poor quality, etc. fact is this is enough information to solve the problem, barring any crazy, environment-specific problems created by the user.
Hope this helps others out there!
Related
We've been trying to pre-compile the views for our application to improve the render times on initial form display.
We're using Visual Studio 2017, MVC 5, MS Membership for security logins.
When Publishing to the web application site without 'Precompile during publishing' set it all builds and the application runs as expected with a login form shown.
When the 'Precompile during publishing' is set on then it builds ok.
But when starting the application we get a 'HTTP Error 404.0 - Not Found' error
and no login screen shown !
I've checked the folders' security, location paths permissions allow All Users.
When publishing with Precompile set on I get the following warnings;
2>ASPNETCOMPILER(0,0): Warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: Microsoft.ReportViewer.WebDesign, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91. The dependencies are: System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.
2>ASPNETCOMPILER(0,0): Warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: Microsoft.ReportViewer.Design, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91. The dependencies are: System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.
2>ASPNETCOMPILER(0,0): Warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: Microsoft.Build.Tasks.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. The dependencies are: System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.
I've tried to get rid of these warnings by adding assembly lines into the web.config's section but to no effect.
Best guess without seeing any of your .config or .csproj files is that you are missing the following section from your Web.config file:
<system.web>
<compilation>
<assemblies>
<add assembly="System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
</assemblies>
</compilation>
<system.web>
This only works if the referenced DLL is in the GAC. If it is not:
Create a /Bin folder in your website root.
Copy your DLL there.
Do not add a reference in web.config.
References:
Adding System.windows.Forms reference into asp.net website
ASP.NET Compiler complaining of mismatching framework versions with MiniProfiler
If That Doesn't Work
Visual Studio is a great tool. But it isn't so great at keeping dependencies in sync across a solution with multiple projects or even between project files and config files. Usually, when you need to upgrade or downgrade a dependency, something will inevitably end up being inconsistent between the main project's .csproj file and one or more dependent assembly .csproj files, or it may even be out of sync with .config files.
The only 100% reliable way to get past a scenario such as this is to manually review each dependency and ensure the version is consistent throughout all projects and config files.
Visual Studio 2017
Fortunately, in VS 2017 they made this easier to do. You can now simply right click the project and select Edit <projectName>.csproj.
Prior Versions of Visual Studio
Right-click on your project node in Solution Explorer and click Unload Project.
Right-click the project node again and click Edit <projectName>.csproj.
What to Look For
Here is an example of a MVC version mismatch that was resolved this way. It might help to create a fresh project from the MVC 5 template to see what an updated project is supposed to look like and then compare the differences between Web.config, Views/Web.config and .csproj files, and then cycle through each of the rest of the dependencies ensuring the version numbers are consistent and up-to-date.
Make sure to check if the .csproj files are using MSBuild conditions, as Visual Studio has no way to update these and they tend to be a major source of problems when it comes to upgrading.
Edit
In IIS I set up a Failed Request Trace and the first item created contained; ModuleName UrlAuthorization Notification AUTHORIZE_REQUEST HttpStatus 401 HttpReason Unauthorized etc...
The message indicates that your application is setup to use UrlAuthorization, and upon further research it appears it could either be configured as IIS URL Authorization or ASP.NET URL Authorization
If using ASP.NET URL Authorization, you will have a web.config entry like
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />
If using IIS URL Authorization, you will have a web.config entry like
<add name="UrlAuthorizationModule" image="%windir%\System32\inetsrv\urlauthz.dll" />
I created a new MVC 5 project from the VS 2017 template (w/individual user accounts) and neither of these is typical of an MVC 5 application. I am not going to tell you that removing these is the solution, because there might be some valid reason why your application is using URL Authorization. It is apparently still the best way that an application can lock down files so they can't be served without logging in. Although, if it can be proven this is the root cause by removing the module you are using, then it will just be a matter of working out how to configure the URL Authorization module to work with MvcBuildViews enabled.
Cutting out the Membership code and re-publishing didn't make any difference.
So I created a new MVC Project and roughly migrating the application's code into it. And it still publishes and runs compiled views !
So I know how to fix it, still don't know why but software's sometimes like that.
Thanks to all who tried to help esp. NightOwl888.
Our project (.Net Framework 4.6.2) was chugging along just fine on EF Core 1.1.0. Then we decided to upgrade to EF Core 2.0.0. Went through a few days of tweaking the code to use new syntax, getting our unit and integration tests to pass again, and finally they did. So today we deployed onto our QA site, which immediately broke with a DLL Hell message:
Could not load file or assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
During the course of the upgrade I had updated System.Net.Http from 4.3.0 to 4.3.3, so I tried reversing that. Didn't help. I tried commenting out the dependent assembly reference in web.config, and that made the message change:
Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Hello! If I've understood correctly, that means that version 4.1.1.0 of System.Net.Http (which is the correct one) is actually being found by the binding redirect - but there's some other assembly that's coming along with my deployment, which is looking for version 4.0.0.0, and ignoring the binding redirect.
How do I find which assembly is messing me up? And how do I get it to respect the binding redirect?
Apparently I'm not the only person to have been sucker-punched by this issue. See here, here and here.
TLDR: Visual Studio 2017 comes packed with a bunch of the latest and greatest DLLs, which are so very good, that MSBuild will impose them on you if you're working with .NET Framework 4.6.2 or earlier, because why would you want to use those cobwebby old versions that you specified in your binding redirects?
I've tried two solutions that worked:
Quick & dirty: Go into your Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461 folder. You'll find lib and ref folders there. Go into each of these and create a subfolder called HideMe or suchlike. Then move all the DLLs except netstandard.dll into the HideMe folder. Now MSBuild can't impose its ideas of which DLL is best for you.
The proper way: Upgrade to .NET Framework 4.7.1. That will be a little more labor-intensive and might break stuff, but at least you don't have to do hacks like my first workaround.
I'm running into an issue after updating the assemblies in my project. Previously I deployed MVC application which contain a reference of an assembly named Core.dll (One of my class library project).
Now in the newer version, I completely removed the dependency of Core.dll from my project and added new dependency TrainingEngine.Core.dll (new class library project).
But the problem is after deployed my updated application, there are several errors being logged that says
Unable to find assembly 'Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
And after further investigation, I came to know that this error raised from those users who previously had opened website on there browser and now when they refresh on there side, this error logged and the site is not responding to them. But if they delete there browser cache or use another browser, it works fine.
I'm not sure why it still looking for old assembly even though I deployed new version. I restarted the App Pool, also Recycle it and restarted the web server but nothing help.
Please suggest
I've been trying to run my build on TFS and I keep getting an error that kills my build. What's strange is that nothing except code change has been done since the issue started (Or at least that I'm aware about). I keep seeing this:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.WinFx.targets (268): Unknown build error, 'Cannot resolve dependency to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.'
I've googled this and the only thing I see is that it's because there's a Silverlight dll being used in a WPF application. My application is a WPF project, but I haven't been able to find any changes being done in any of my projects in my solution in regards to references.
For more information, this project is a branch from the main code. The main development branch runs fine, but for some reason, this build just fails.
Any ideas?
It seems like you're referencing the Silverlight version of System.Windows instead of the .NET Framework version. Have you tried installing Silverlight on the build server or changing the reference of your project to point to the normal .NET Framework version of that assembly (which .NET Framework exists on your build server)?
My monodroid application builds fine and deploys to the device; however the application dies on start up and the DDMS shows the following error:
01-07 17:04:57.607: E/mono(875): Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Db4objects.Db4o, Version=8.0.224.15975, Culture=neutral, PublicKeyToken=6199cd4f203aa8eb' or one of its dependencies.
I have confirmed I am referencing DB4O and it shows up in the bin/debug directory.
Given this error I would think that db4o does not work with Monodroid but I have another Monodroid project which uses db4o and it works.
I have a feeling something is broken with the project file but not sure what to do. I have tried removing and adding the db4o reference a couple of times.
I am using Visual Studio 2010 and the latest version of Mondodroid as of 1/7/2012. I am deploying to a an Android 3.2 emulator.
Thanks in advance for any insight.
It sounds like you're running into a bug in the current version of Mono for Android that has to do with Fast Deployment. In the project's properties, under the Mono Android Options section, uncheck the box for Use Fast Deployment. You'll probably need to do a clean build as well to make sure it takes effect.