We have a VS 2010 MVC3 project, targetting .NET 4.0 (machine has .NET 4.5), the project contains a WF Xaml file and related classes. We needed to access jQueryValidation on the serverside, so we added the script# jQueryValidation NuGet package (v 0.7.5.0), we get the following compile error without even using script# yet:
Error 1 XC1020: Build error occurred in the XAML MSBuild task: 'Could not load type 'System.Runtime.CompilerServices.ScriptAssemblyAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.....
The Xaml file contains references to the standard mscorlib, we've attempted to strong reference the Gac library in Xaml, via version #...however its to no vail. The project will only compile once we remove the Script# libraries. Then in an effort to narrow down the problem, we installed the nuget package for script# 0.7.5.1, not the jQueryValidation package, and we are able to compile. Installing the jqueryvalidation package afterwards will result in the same error as before, could this be related to the package being based on 0.7.5.0?
Any hints? we would really like to use script# jqueryvalidation and WF Xaml in the same project.
Thanks in advance.
Script# assemblies are meant to be used by script# projects only, i.e. those projects that contain c# code to be compiled into javascript. Your MVC project itself is not a script# project. Likely what you should be doing is creating a separate script# project, to generate script that gets deployed into/via your MVC project.
Specifically script# comes with its own mscorlib with script# specific types not present in the desktop mscorlib assembly.
Related
I'm building a Web API in .NET Core 2. I'm using some custom nuget packages to leverage their built in functionality. These custom packages were built against an older .NET version (4.6.1). The problem is some of these packages have references to the old System.Web dll. I'm getting this warning on some of the custom packages in the solution
package was restored using '.net framework version=v4.6.1 instead of using the proj target framework.
The app is also throwing this exception below when I call code in one of the custom packages
System.IO.FileNotFoundException: Could not load file or assembly System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral,The system cannot find the file specified
Is there any way around this other than re-writing the code in my web Api?
No. System.Web is completely incompatible with Core. While Microsoft opened up NuGet packages that target .NET Framework to be utilized in with .NET Core, it did so based only on .NET Standard 2.0 compatibility, and makes no assurances that the packages will function in part or whole. You'll actually get a warning during compile telling you as much. Also, while you can actually have something like an ASP.NET Core app actually target .NET Framework, again, compatibility of third-party components is not guaranteed, simply because they target the same framework.
Long and short, if there's any dependency on System.Web at all, you can't use it.
Environment
Visual Studio 2017
.NET Standard 2.0
.NET Framework 4.6.1
MyCustomTask.csproj contains custom MS build tasks and has multi targets to generate a separate dll for .NET Full and .NEt Core runtime.
There is a 3 level dependency on the Nuget Package "Microsoft.Extensions.Configuration.Json" which in turn has a dependency to Newtonsoft.Json package. as shown below.
The build is all fine and the Nuget package for MyCustomTask is generated successfully.
When I install my MyCustomTask Nuget package on target project then the custom build task is getting successfully executed on .NET Full runtime from Visual Studio 2017, but for .NET Core dotnet build command fail to execute the custom build task...
System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral.
Even if I package all the dependent DLL and place it in same directory of the .netstandard custom task dll I keep getting same error.
Any thoughts how this can be resolved ?
Posting a solution here for those who are experiencing the same issue.
Credit to #MartinUllrich for posting the solution in a comment above. This saved me a lot of trouble.
https://github.com/AArnott/Nerdbank.MSBuildExtension
Ensure your custom task inherits from ContextIsolatedTask and copy the dependent assemblies to same directory as your task assembly.
I have a .NET Standard library (1.4) VS 2017 project that contains custom MS Build task (MyTask) that need to be distributed via Nuget package (Let's say MyCustomTask.dll and it contains MyTask and Portable.targets that will be imported by target project)
This Nuget package with custom build task is then used by target .NET Standard (1.4) project cspro file to import the Portable.targets that invoke the Custom Build task.
However, at this point I keep on getting the build error
Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
I tried .NET Standard (1.4, 1.5 and 1.6) but same error.
The problem is that the consuming application, MSBuild.exe in this case, would need to include all the forwarding assemblies necessary to run netstandard tasks (e.g. depend on the NETStandard.Library).
The best solution in this case is multi-targeting the task library to a .net framework and a .net standard target framework:
<TargetFrameworks>netstandard1.6;net46</TargetFrameworks>
The idea is to have 2 dlls that will contain the task. In the project files contained in the NuGet package instead of using a dll path directly in <UsingTask>, the idea is to using a different dll file based on the $(MSBuildRuntimeType) property, which will be Core on the .NET Core version of MSBuild:
<PropertyGroup>
<_CustomTaskAssemblyTFM Condition="'$(MSBuildRuntimeType)' == 'Core'">netstandard1.6</_CustomTaskAssemblyTFM>
<_CustomTaskAssemblyTFM Condition="'$(MSBuildRuntimeType)' != 'Core'">net46</_CustomTaskAssemblyTFM>
<_CustomTaskAssembly>$(MSBuildThisFileDirectory)..\tools\$(_CustomTaskAssemblyTFM)\CustomTaskAssemblyName.dll</_CustomTaskAssembly>
</PropertyGroup>
<UsingTask TaskName="SomeCustomTask" AssemblyFile="$(_CustomTaskAssembly)" />
You can see examples of this in the asp.net core build tools and the .NET Core SDK.
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've got a .NET solution that I've just upgraded from VS2008 to VS2010. It contains three web projects and two straight VB projects. The web projects all depend on (and have a reference to) one of the VB projects called BusinessLogic.
All projects are targeted at .NET 2.0, but VS2010 is raising the following build 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: BusinessLogic,
Version=1.0.4419.22315, Culture=neutral, PublicKeyToken=null. The
dependencies are: Microsoft.VisualBasic, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. 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.
As far as I understand 8.0.0.0 is the correct version of VB for .NET 2.0, so why is this a warning? Is this something to worry about?
You have to go to menu Project|Properties and check the "References" Tab.
Check if the References you use are .NET 2.0 or higher.