In my company I'm running Visual Studio 2015 Enterprise and just recently upgraded to Windows 10. Unfortunately, now I can't run any web project using versions of asp.net earlier than 5 (owin/katana) - always getting error :
"Could not load file1or assembly 'XXX' or one of its dependencies.
The process cannot access the file because it is being used by another
process. (Exception from HRESULT: 0x80070020) ".
Now, I've found a few posts like this and the answer is mostly that some other application is running on port 80, 8080 etc blocking visual studio's iis express. The problem is that I get this error regardless of port I'm using (even on some random 34535 etc).
The interesting part is that when I run kestrel (app on asp.net 5) it works and runs fine without any error.
Anyone has any ideas ?
Okay, so I had this issue and resolved it by uninstalling Panda antivirus, which presumably was locking the assemblies for just long enough to interfere with loading them some of the time.
If anyone else is having this issue, and there is definitely an assembly that won't load (as opposed to a port that's already been bound to) then try checking your antivirus!
Related
I have been having a hard time getting Visual Studio 2015 CE and IIS express to run on my windows 10 machine. Even when I make a default MVC5 web application and attempt to run it without making any changes I usually see the error below.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: Could not load file or assembly 'Business, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)
I have read a few posts that talk about using the netstat -ano command and finding the PID of the process using the same port, it always ends up being PID 4 aka "SYSTEM". I have tried uninstalling IIS Express and enabling the local IIS under "Windows Features" and what happens is I receive the same error, but after like 10 page refreshes the site loads.
Has anyone else come across this?
I hate to say it, but the way I resolved this issue was by reverting back to Visual Studio 2013, I can't state for certain the the issue was with the 2015 Community Edition of Visual Studio, but at this time VS2013 is what works.
I have an ASP.NET web site created with WebMatrix 3. I do have the option in VS2013 checked to use the 64-bit version of IIS Express since I am running on 64-bit Windows 8.1. When I try to launch the project I get the error "An operation is not legal in the current state". Does anybody know how to fix this?
I got this same error "An operation is not legal in the current state" when running a project on Google Chrome, Stopping the project then closing all chrome instances fixed the problem.
I think it's related to visual studio not being able to attach to chrome instance for debugging.
Closing Chrome and restarting IIS (e.g. in IIS Manager) should solve the issue. It helped in my case.
Just had the same issue on VS (Visual Studio) 2017 this morning.
The steps that will resolve this are:
Stop project that runs in VS
Clean all IIS instances that VS temporarily created
Compile project and start that service again
As of right now, I'm unable to debug any of my ASP.NET web application projects on a completely fresh machine because of the error message above. I'm trying for hours now and it's driving me completely nuts because I'm getting paid for working, not for debugging strange environment errors. :/
Installation Procedure / Environment
Installed Windows 8 Professional x64
Installed Visual Studio 2012
Installed Visual Studio 2012 Update 3
Installed IIS through Windows Programs And Features
Nothing else has been done - no addins, no further configuration etc. Administratior permissions are available...
Error message
Unable to attach to application 'webdev.webserver40.exe_00001254_
01ce76431af5c900_dc2119bc-2761-480f-b975-4fab7ad27f390'
(PID: 4692) using '*myhostname*'.
Operation not supported. Uknown error: 0x80040d10.
Do you want to continue anyway?
Same error occurres with Local IIS Web Server (IISExpress too...)
Solutions
In other forums / threads, various solutions have been mentioned, but none of them really fixed it.
Rebooting machine
Reinstalling VS
Terminating running web server instances
Has anyone else faced this annoying error?
I have debug=true both in the web.config and in the requested file but it still won't stop.
Thanks...
There might be several reasons:
There are changes to the assembly and the debugger didn't get updated - try cleaning the solution and the building it again
You are building in release mode - in this case you would get a warning message from the studio
The rest options depends on weather you are using local iis or the Visual Studio web server.
I'm having a problem when browsing a published site on local iis7 (on windows 7).
When browsing the asp.net site through VS2008 with F5 (dev iis) it works fine. When publishing it and browsing, I get a:
Server Error in '/MySite' Application.
The specified module could not be found. (Exception from HRESULT: 0x8007007E)
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: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Stack trace offers no clue on the problematic dll either. I copied the same published folder to a different machine (also with windows 7 32bit and iis 7) and it works.
Since this is a fresh install of iis on my machine, I verified the matching selected items in "Turn Windows Features on/off". After noticing the issue I also ran the "aspnet_regiis" util, but the problem remains.
The web site includes several external dlls (native and managed) and they all appear in the published bin folder (which is identical to the development bin folder)
Any insights?
Cheers,
Shay
As gleaned from this thread: http://social.msdn.microsoft.com/forums/en-US/netfx64bit/thread/f609f52e-00f6-4ada-9d6e-7129b85d3d4d/, as mentioned toward the bottom of the thread (second to last post as of right now), our problem was a "rogue" dll, Microsoft.SqlServer.Replication.dll. We simply removed the dll and no more error. Additionally, as no project in the solution referenced this dll, I simply removed it from the bin file and subsequent builds/publishes do not add the dll. I have no idea how the dll got in the bin file in the first place. A college prank, maybe.
Native dlls are supposed to be locatable in the PATH. Problem was they were under the User PATH and not the System PATH, so it worked fine through the VS but not through the IIS. I added the dll folder to the system PATH and everything worked...
A long shot in most cases but check you have good .NET Framework libraries. Was getting nothing from old Framework 2.0 website maintained with VS 2005 running on IIS 6 except plain text in browser window stating the error. Fiddler and Firebug reveled nothing. Started checking this, that and the other thing. Perhaps when wondering about using aspnet_iisreg that the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder was discovered to have only a handful of files. Doesn't make a lot of sense, the applications were 2.0 but there is some cross application communication and several libraries so maybe some are run as 4.0 or it might be that IIS will try to use some things from the highest version of .NET Framework available.
A co-worker more knowledgeable about servers repaired the 4.0 Framework with the stand alone installer from here.
Runs well now.
This error occurred for me when the .Net Framework on the target server was only 4.5.2 and a recently upgraded Nuget package required 4.7.2. To temporarily solve it, we downgraded the Nuget library to a previous version that did not require 4.7.2 until we can upgrade the server library.
This was in spite of our project properties having .NET Framework 4.5.2 selected as a target framework.