I've got a fresh Visual Studio 2017 installation with a fresh .NET Core 2.0 installation. I've created a .NET Core 2.0 Web project in Visual Studio. Now, when I try to do almost anything in that project (try to open site.js, try to add some files to wwwroot, try to open site.css etc) I get this error:
Could not load file or assembly 'Microsoft.Owin, Version=3.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
This is a fresh install of Visual Studio 2017, fresh install of .NET Core, and a fresh, untouched project with default settings. What am I doing wrong?
Restarting Visual Studio fixed it. Duh.
Related
After reinstal win 10 I installed VS 2019 (used VS 2013 before). All is running well, only one project with svc service I can't debug using WcfTextClient. Build is OK, but when the WcfTestClient appears, an excption occurs: FileNotFoundException: Could not load file or assembly 'Microsoft.Build.Utilities.Core.dll, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I'm afraid it's because the version of MSBulid according to VS 2019 is 16.8.1. But I can't discover, where it is configured that ver 15.1.0.0. is required. Tried to change relative paths in devenv.exe.config and WcfTestClient.exe.config, with no effect. The project is configured to target framework 4.5.2. If I start debugging in an aspx page (without WcfTestClient), it works fine. If I try it on another machine with both VS 2013 and VS 2019 installed it works also in VS 2019 there.
The project is set with
<Project ToolsVersion="12.0" DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
The required version 15.1.0.0 refers to VS 2017 which I have never installed on my machine.
I tried to change the version and path to the file in all possible configs found under IDE directory of VS, no success.
Then I tried to install vs_buildtools for VS 2017, didn't help (but it is actualy version 15.9).
Finally I've installed MSBuild 15.1, also v12.0, but the error is still the same.
According to the error message, the version=15.1.0.0 msbuild tool should be missing, and the project is created by it. Below are the different versions of msbuild owned by vs and the location of the msbuild.
You can download different versions of msbuild here:msbuild.
You can find Nuget package manager in the tool options, and then select manage nuget packge for solution. In this interface, you can install Microsoft.Build.Utilities.Core.
I have an ASP.NET Core 1.1.2 project targeting .NET Framework 4.6.2. I recently installed the latest version of Visual Studio (15.2 26430.16), and now I can't build the project using MSBuild version 15.1.1012.6693. The error occurs when using a PublishProfile.
The MSBuild command is:
msbuild D:\project\project.csproj /p:DeployOnBuild=true /p:PublishProfile=dist
And the error is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\TransformTargets\Microsoft.NET.Sdk.Publish.TransformFiles.targets(54,5):
error MSB4062: The "TransformWebConfig" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\..\..\tools\net46\\Microsoft.NET.Sdk.Publish.Tasks.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\tools\net46\Microsoft.NET.Sdk.Publish.Tasks.dll' or one of its dependencies.
An attempt was made to load a program with an incorrect format.
Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
[D:\project\project.csproj]
It works when not specifying a publish profile. However when publishing the project from Visual Studio, everything works as expected.
This is known bug of the tooling when building using the 64 bit MSBuild version (build server, command line). See this GitHub issue for details.
Since this issue has been fixed, you need to upgrade to the recently released 15.3.* versions of Visual Studio / MSBuild and probably also 2.0.0 version of the .NET Core SDK.
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
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.
We're using Cruse Control to manage our build process.
AS we convert vs2008 projects to vs2010, we're leaving the target framework set at 3.5 for web and class library projects.
At this point we're not going through and converting all our solutions to vs2010; not if we don't have to.
I recently updated the MSbuild project files that cruise control uses to point at MSBuild 4.0 so our build process would be able to build vs2010 projects.
C:\windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
All was well until a web project that was targeting the 4.0 framework was committed.
At which point this error popped up:
CS0433: The type 'System.Web.Routing.RouteCollection' exists in both c:\Windows\Microsoft.NET\assembly\GAC_32\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll and c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Web.Routing.dll in Global.asax.cs(15, 43)
At which point I became aware of the Windows/Microsoft.NET/Assembly folders.
Now... All the MSBuild projects, even though they were using MSBuild 4.0, still had the tools version set at 3.5.
So why was a 3.5 targeted build looking at the new 4.0 assembly folders and finding this conflict? Probably because I was using MSBuild 4.0. But if I can change the toolVersion that MSBuild uses, you'd think I can tell it to target 3.5 without worrying about these potential conflicts.
To resolve this issue, I went to the relevant MSBuild project files that cruise control uses and changed their toolsVersion to 4.0. This got passed that conflict error. But now everytime it tries to build a project that's in a solution that we haven't yet converted to a vs2010 project, it breaks with an error like this:
MyProject.csproj in SomeFilePath:
LC0000: 'Could not load file or assembly or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.' in LC(0, 0)
If I open the solution that contains that project in Visual Studio 2010 and do the conversion, build it and commit that and force another build, I get passed that error only to find that another not yet converted project is tossing that same error.
So now I am for sure using MSBuild 4.0 and for real targeting the 4.0 framework. Why can't 4.0 build 3.5 projects or vs2008 solution projects?
The issue is that you have migrated part of your projects to to visual studio 2010. Any 2008 project that references a 2010 project (by project reference) will give you this compile time error. Try updating all .csproj files to 2010 and try rebuilding again.