Why isn't .NET looking in my output path for any binaries?

Question

I've inherited a Visual Studio web project and the Output Path is specified as objd\amd64\. When I build, all the files (both compiled project files along with packages, such as MVC) show up there. However, when I hit F5 to run the app, I get the following exception:

Could not load file or assembly 'System.Web.Mvc, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

The exception goes on to list places where the system is looking for that (and other) files. The first place it looks is bin, which is the normal output folder. Why isn't .NET looking in the specified output folder, and how can I make it look there?

CLARIFICATION: Just to be clear, this exception is not unique to MVC. If I manually create the bin folder and copy the MVC DLL there, then I get past this exception, but get another one for the next file it looks for. If I copy all the files to bin, then the app runs fine. The runtime just isn't looking in the specified output folder for the files.

UPDATE: If I change the Output Path to bin, NO files are output there. There is no post-build event defined that I can see.

UPDATE: Here are my build settings. The bin folder isn't even being created when I build the project (I'm trying to use bin for test purposes), let alone getting files copied into it. Debug is definitely the selected build type when I hit F5.

UPDATE: Here are the Solution config settings:

So just to clarify. It is actually copying the MVC assembly to the destination specified but it is not looking there to find it? I know this is random but if it is the case, can you go to that assembly and check the version of it to make sure it matches 5.2.3.0? — Travis Acton, May 24 '17 at 15:03
That's right. Everything that would normally go into the bin folder is going to the specified output folder. If I create a bin folder and manually copy all those files there, it finds them there and runs. So, it's definitely the right version of everything. It's just looking somewhere other than where it outputs all the files. — birdus, May 24 '17 at 15:11
In your list of references, is there a little yellow icon next to this reference? You may need to just fix the reference by locating it manually? I don't recall if this is a NuGet reference or not. If it is you can reinstall it and that should fix it too. — KSib, May 24 '17 at 15:12
If I manually copy the MVC DLL to the bin folder, then I get past that error and get another one. That happens for each file. If I copy all the files to bin, then the project runs fine. So, the files are all there and are correct. The runtime is just looking in the wrong place for them. — birdus, May 24 '17 at 15:13
@KSib No. All the references are fine. And the files are all output fine. The runtime is just looking in the wrong place for them. — birdus, May 24 '17 at 15:22
You said you have inherited this project. And how it worked before? Or developers never debugged it with F5? — Evk, May 24 '17 at 15:23
At least one of them said he published it locally. I guess he attached to the w3 process. Not sure. That just seems like a silly way to do it, though, when I should just be able to hit F5. — birdus, May 24 '17 at 15:25
Well wait, there is a difference between build output location vs how visual studio resolves assemblies during run time. This setup would only work if you had a local IIS site and were dumping your output to it's directory then attaching to it. Can't really imagine an instance where that would be a great debugging setup but whatever. You need to flip it back to just use the bin folder on the debug configuration (project > properties > build > output path: "bin\" or else you are goignt o be forced to write a custum assembly loader or just attach to process every time. — Travis Acton, May 24 '17 at 15:52
Just saw your updated comment about changing to bin and no files being output there: Make sure you changed it to output to bin on your debug build and that you are actually building the debug build — Travis Acton, May 24 '17 at 15:56
It is stated everywhere (for example: https://stackoverflow.com/a/12685431/5311735) that bin is a special folder from IIS security perspective, so you cannot change this behavior, though I didn't find any confirmations to this (but makes some sense). — Evk, May 24 '17 at 16:01
weird, hit rebuild instead of build to make sure it is building the solution from scratch. — Travis Acton, May 24 '17 at 16:36
Check this: Right click the Solution > Properties > Configuration Properties. Check that the Build checkbox is checked under 64 platform — Travis Acton, May 24 '17 at 16:53
@TravisActon Rebuild didn't make a difference. It still didn't create "bin" and after I created bin manually, building didn't put any files there. Also, I just added a screenshot to the post of the solution config screen. — birdus, May 24 '17 at 16:58
@TravisActon One other thing regarding something you said earlier. The other dev does, in fact, have IIS installed locally and is running it from there. He publishes the site. Anyway, I'd like to run it more conventionally (from a dev perspective), but it's not turning out to be as easy as I had expected. — birdus, May 24 '17 at 17:14
@Evk You mentioned IIS have special security requirements with respect to the bin folder. Well, I really just want to run the site using IIS Express. I don't think there should be any special requirements to get this to run locally with IIS Express. — birdus, May 24 '17 at 17:17

NightOwl888 · Answer 1 · 2017-05-24T17:30:30.520

Could not load file or assembly 'System.Web.Mvc, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

The error is a compile error. This means the build is crashing before the MVC runtime is launched.

This is easy to prove. Delete the bin folder and try to compile again. If it is not re-created and/or there are a lot of files missing, it means the build is not making it all the way through.

Some things that could be causing this are:

Mismatching MVC (and/or MVC dependency) version numbers between 2 different .csproj files in your solution.
Mismatching MVC (and/or MVC dependency) version numbers between your .csproj file and web.config and/or /Views/web.config.
One or more .csproj files has an invalid <HintPath> for an MVC (and/or MVC dependency) DLL reference location.
NuGet package restore is not set up at all or is not set up properly. The easy way to check this is to look in your packages/ folder to see if the reference in the error message exists on disk.

The best (safest) way to solve this is to go through these files manually. Visual Studio doesn't always make the right decisions when upgrading dependency versions or changing file locations.

Typical MVC 5 references and versions should look like this in the .csproj file (you may need to adjust the version numbers and net45x version in the <HintPath> accordingly):

<Reference Include="System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <Private>True</Private>
  <HintPath>..\packages\Microsoft.AspNet.Mvc.5.0.0\lib\net45\System.Web.Mvc.dll</HintPath>
</Reference>
<Reference Include="System.Web.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <Private>True</Private>
  <HintPath>..\packages\Microsoft.AspNet.Razor.3.0.0\lib\net45\System.Web.Razor.dll</HintPath>
</Reference>
<Reference Include="System.Web.WebPages, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <Private>True</Private>
  <HintPath>..\packages\Microsoft.AspNet.WebPages.3.0.0\lib\net45\System.Web.WebPages.dll</HintPath>
</Reference>
<Reference Include="System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <Private>True</Private>
  <HintPath>..\packages\Microsoft.AspNet.WebPages.3.0.0\lib\net45\System.Web.WebPages.Razor.dll</HintPath>
</Reference>

Update

I see you have posted Visual Studio's project properties. The configuration is highly customized and I don't recommend you use Visual Studio's project property designer to edit it, because it could cause the configuration to become corrupted.

My suggestion is to use the following procedure to review your .csproj file references. This is much safer than deleting references and re-adding them, since Visual Studio doesn't support a way to edit everything in the .csproj file that could be there.

Right-click on your project node in Solution Explorer and click Unload Project.
Right-click the project node again and click Edit .csproj.
Search the file for references to each of the above assemblies and update the version and the HintPath accordingly. Make sure the HintPath you use actually points to an existing file on disk.
Repeat these steps for all dependent projects in the solution (and any that are in DLLs that are not part of the solution).

You should also review the assembly versions (especially those of MVC) in your web.config and Views/web.config and update them, if necessary. See the link for more detailed information.

score 0 · Answer 2 · answered May 24 '17 at 15:57

Update the Application web.config File

Be sure to make these changes in the app web.config file, not the web.config file in the Views folder.

<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
           <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
           <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
        </dependentAssembly>
   </assemblyBinding>
</runtime>

Why isn't .NET looking in my output path for any binaries?

2 Answers2

Update