Why am I getting Could not load file or assembly error on a System.Configuration DLL when using framework 4.0? - assemblies

Immediately after we upgraded to visual studio 2010 and the 4.0 framework our trunk build started breaking with the Could not load file or assembly error.
We determined that a 3.5 project couldn't reference a 4.0 project else we'd get this error because, as the error states, This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
We've since resolved this and the trunk has been building fine.
I recently did a branch and tag, however, and suddenly this error has resurfaced when I try to build the branch; except the error is regarding one of our own .net 4.0 project's reference to System.Configuration DLL.
Towps.Namespace.MyService.csproj in Core.Dev\Towps\Projetcs\Application\MyService:
RG0000: Could not load referenced assembly
"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll". Caught a BadImageFormatException saying "Could not load file or assembly 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.". in ResGen(0, 0)
I tried setting the specific version property on that system.Configuration DLL ref to true. I can see in it's properties that the runtime version is v4.0.30319 and the Version is 4.0.0.0. The path to the DLL ref is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Configuration.dll which to me looks fine.
The target framework for the csproj file that CrusieControl is using MSBuild to try to build is targeting framework 4.0. Again seems fine.
It builds in the IDE for both trunk & branch. Cruise Control build it in the trunk. The branch build fails when CrusieControl tries to build.
Any ideas what could be happening?
It could be an MSBuild mismatch but I've scanned the config files and msbuild proj files that CruiseControl is using and there are no references to older MSBuilds; which makes sense since all those were updated to get the trunk working.
The branch was simply a copy of the trunk so I'm having difficulty determining what could be the difference!

It turns out that after I branched, all the .proj files in my branch build directory that cc.net uses were back to using ToolVerison="3.5".
I thought I committed all the ToolsVersion="4.0" proj and config changes to the trunk from which I made the branch; evidentially not.

The difference could easily be hint paths no longer lining up on the new branch. However there's not a log to go on in your description. What are the command line options you are passing? In ccnet.config and also any others that may get in if ccnet.config is pointing at a build script that calls msbuild instead of directly to a .sln or .csproj file.
Turn on /v:d for the msbuild on BOTH and then compare the reference resolutions (or build order, etc..) for that assembly or other ones involved/near it.
Also are you providing the path to msbuild on both?
msbuild4="C:\WINNT\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
<msbuild>
<executable>$(msbuild4)</executable>
in your ccnet.config?
I've seen it report the 2.0 build executable during a msbuild4 /tv:3.5:
<Message Text="MSBuildToolsPath:$(MSBuildToolsPath)" />
<Message Text="MSBuildToolsVersion:$(MSBuildToolsVersion)" />
MSBuildToolsPath:C:\WINNT\Microsoft.NET\Framework\v2.0.50727
MSBuildToolsVersion:2.0
so that didn't seem very useful.
I'd like to see the config blocks for both branch and trunk.
I know I had some paths in the buildscript that failed in my branch because there was a hardcoded path that would not be valid for the branch. I had to adjust the ccnet.config to pass in arguments for those items to override for the branch.

Please check .net framework version supported by your client. For example sharepoint2010 will not support dll built by 4.0 or higher .net framework. It will support only 3.5 or below.

A bit late I know, but if anybody else has this issue, try adding the RuntimeVersion into your .dna file if it does not already exist.
<DnaLibrary Name="PROJECTNAME" RuntimeVersion="v4.0">

Related

System.Threading.Tasks.Extensions unloaded by IIS

I have a project with assembly which refers to System.Threading.Tasks.Extensions, Version=4.6.28619, It's an old ASP.NET App hosted on IIS. After compilation, the app is running and everything is OK. After some time, the app throws an exception.
"System.Exception: Could not load file or assembly
'System.Threading.Tasks.Extensions, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51.
After the recompilation and restarting the APP, everything works fine, but after a few hours, the exception is thrown again. What could be the problem?
I have tried to change web.config to use System.Threading.Tasks.Extensions in the correct version, but it didn't help.
Version=4.6.28619 is file version, not the Assembly Version. I did goodle on System.Threading.Tasks.Extensions history.
I found the 4.3.0 should be the correct version in your project.
Other version couldn't find 4.1.0.0 version dll like picture above. Package version >=4.4.0, using 4.1.1.0. <4.3.0, using 4.0.0.0.
Now you can follow the suggestions below to check the issue
Find the package System.Threading.Tasks.Extensions like my first picture.
If you have multi project, make sure all the projects using the same version package.
Delete the .vs folder
Check the web.confg/app.config file, and check the version of System.Threading.Tasks.Extensions, if there are duplicates, please delete them.
If the steps above not works for you, maybe the issue related to deployment. You can try the binding redirects.

devops pipeline publishing wrong assembly version (of newtonsoft.json)

I have a Blazor webassembly solution (hosted by aspnet.core webapi) which builds and runs fine locally. Server and Client reference directly newtonsoft.json.dll version 13.0.1. The server also has a reference to Microsoft.AspNetCore.Mvc.NewtonsoftJson which shows a dependency to newtonsoft.json of >=12.0.
If after compiling I search locally in the bin folders, ALL projects have version 13.0.1 but one 12.0.3 in the BlazorDebugProxy folder.
Now building,publishing and running the app via azure results in error:
Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.
File name: 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
at Microsoft.AspNetCore.Mvc.MvcNewtonsoftJsonOptions..ctor()
Looking at the files in the artifacts which the build created, it is version 9.0.1 ! The only hint why this file might be the wrong version is that this is the Net Standard 1 version. However the projects all have version 5 in their csproj files, so it should not pull any framework 1 stuff and it does not locally.
I added a step to install Net 5 SDK and when starting the restore process it correctly reports that SDK version 5.0.402 is used.
In the pre Net Core world such issues where easily resolved with an assembly rebind, what do I do now ?
I finally figured it out and it's a bad behavior of the devops pipelines. The issue is that publish will internally do a build and if that is set to the whole solution, it just copies all dll's to the publish folder.
I had the build task set to just build my web project, but forgot to do the same for the publish.
Once I did set this, the correct dll was copied (what is references in the csproj file takes precedence to any other versions).
The ONLY reason one needs a separate build task is if there are other projects to build beside the one to publish, in most cases (mine) test projects.

Why does building with Microsoft.Xml.SgmlReader 1.8.18 nuget output this warning MSB2346

I'm using the Microsoft.Xml.SgmlReader nuget in several places of my .Net Core 3.1 projects.
The build output says:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2123,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'SgmlReader.exe' or one of its dependencies. The module was expected to contain an assembly manifest.
I'm unable to google what this really means or how I fix it. Maybe I should be using a different incarnation of the SgmlReader nuget, only this one (1.8.18) seems to be the one most up-to-date.
Edit:
No information reg. sgmlreader in fusion logs when building (or starting VS2019).
But I did notice these two in the references:
Compile Time Assemblies, SgmlReader.exe and SgmlReaderDll.dll
I can open SgmlReaderDll.dll in JustDecompile, but not SgmlReader.exe.
I also notice that the exe is part of netcoreapp3.1, but not netstandard2.0 and netstandard2.1. That does not look right to me.

VIsual Studio 2017 NuGet package installs well but is not recognized

I have Solution A which has a .NET Core 1.1 class library project. In the Package properties I filled all NuGet fields and selected to create the NuGet upon successful build. This project builds just fine and the NUPKG is created. BTW How can I automatically copy the generated NUPKG to a local directory (my own repository)?
Then I have Solution B which is an ASP.NET Core 1.1 web application. In it I browse to my local repository (where I have manually copied the NUPKG built by Solution A) and install my SolutionA.MyPackage into the web application. VS.2017 says it was successful at installing it. I see it listed in the project's NuGet dependencies.
However, when I try to use ANY of the objects defined in that NuGet package I get a red highlight saying it is not found as if there was no NuGet or assembly reference to that DLL but there is!
What is causing this Visual Studio generated Nuget package to be installed and yet act as if it has not even been referenced?
UPDATE - CSPROJ TARGET
As for copying to my local repository, I added this to CSPROJ but it was not working (somebody had suggested it as I put it). I finally figured out why it did not work, the ItemGroup must be inside the Task.
<Target Name="CopyPackage" AfterTargets="GenerateNuspec">
<ItemGroup>
<MyPackageFiles Include="bin\Release\PackageId.*.nupkg" />
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="D:\My Repository\MyNugget\Publish" />
</Target>
UPDATE NuGet Inspection
I opened the NUPKG with NuGet Package Explorer and it shows this more or less:
content\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
contentFiles\
any\
netcoreapp1.1\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
lib\
netcoreapp1.1 (.NEtCoreApp, Version=v1.1)
MyPackage.dll
UPDATE 3
Since NuGet seems to have stopped working (used to work well earlier) I opted for using an Assembly Reference rather than a NuGet (for now). In this situation something odd happens, when coding I can reference ALL the objects in the referenced assembly (former NuGet) and therefore no compilation errors on the main project BUT when I then run the web application I get an internal error because it says
FileNotFoundException: Could not load file or assembly
'MyPackage, Version=0.0.3.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
Unknown location
Which is strange because in the Solution Explorer I see the assembly reference and when I click on it (main application) I can navigate to all the objects that I have defined in that assembly. Why it cannot find it anymore?
It is working again (as it was before!). Today I could open the solutions but when I tried to download an extension (Tools | Extensions) I got an error message about an Access Denied or something like that. It has happened before since I installed to VS.2017.
Of all the Visual Studios I have used since 2002 this has been the most unstable! (and I have update 15.2).
When I saw this error happening again I knew how to get rid of it and thought, "hey, maybe that is what is keeping the NuGet package to be installed but not found or the problem with a direct assembly reference".
So I went to my C:\Users\AppData\USER\Local\Microsoft\VisualStudio\15.2* folder and removed it completely.
After that I the ACCESS DENIED issue went away with the side effect that I had to reinstall all extensions again. I attempted again to install my own NuGet, it did so successfully and as expected (was not happening during the long glitch) the objects were found and the web application worked again.

Mono's XSP webserver can't find MySql.Web.dll on Linux

I'm working on getting my ASP.Net project working on Linux. I've been testing my code using XSP on windows, but now I am trying to make sure that I can develop and test on Linux as well. To that end I've gotten Ubuntu running and have MonoDevelop and MySQL running. I've downloaded the latest MySQL Connector/Net and I think I have it installed correctly.
There is no package that will automatically install the MySQL Connector/Net for distribution so I downloaded the 6.2.3 zip file from the MySQL website. Now I've already discovered the issue with case sensitivity because the zip file contains filenames in lowercase, and Mono expects them in uppercase. So I've changed the names of the files to MySql.Data.dll, and MySql.Web.dll respectively. I've also used gacutil to install both files to the GAC. Likewise I have added the files to the Mono Lib directory. The following files do exist on my machine:
/usr/lib/mono/gac/MySql.Data/6.2.3.0__c5687fc88969c44d/MySql.Data.dll
/usr/lib/mono/gac/MySql.Web/6.2.3.0__c5687fc88969c44d/MySql.Web.dll
/usr/lib/mono/2.0/MySql.Data.dll
/usr/lib/mono/2.0/MySql.Web.dll
I've also created package files so that I can add references to the the assemblies in MonoDevelop. The folder /usr/lib/mono/2.0 contains two .pc files that I added.
MySql.Web.pc:
Name: MySql.Web
Description: ASP Membership, Role and Profile providers powered by MySQL
Version: 6.2.3
Libs: -r:/usr/lib/mono/gac/MySql.Web/6.2.3.0__c5687fc88969c44d/MySql.Web.dll
MySql.Data.pc:
Name: MySql.Data
Description: Provides connectivity to MySQL databases
Version: 6.2.3
Libs: -r:/usr/lib/mono/gac/MySql.Data/6.2.3.0__c5687fc88969c44d/MySql.Data.dll
At this point I can use the assemblies in projects inside MonoDevelop. The Assemblies appear in the list of available assemblies when I edit the project references. The project now compiles without error inside MonoDevelop. However when I run the compiled web project in XSP the following error is displayed in the browser:
System.IO.FileNotFoundException: Could not load file or assembly 'MySql.Web.dll, Version=6.2.3.0, Culture=neutral, PublicKeyToken=C5687FC88969C44D' or one of its dependencies. The system cannot find the file specified.
What is fustrating is that originally the error was that it could not load MySql.Data.dll and now the error message is that it can not load MySql.Web.dll. Which means that I somehow fixed the problem I was having with the Data dll, and now I have the problem with the Web dll. I have gone and re-done I learned to fix the problem for the Data dll, but I am unable to get the Web dll working.
Unfortunately I'm still pretty new to Linux and Mono (but not to ASP.Net) and I've run out of things to try. Likewise I haven't found anything on Google to try other than what has been described above which leaves me asking for help.
Can anyone help me find out why XSP can't find the assembly and what I can do about it?
Thanks,
-Will
You can try setting some environment variables which should tell you where all Mono is looking for assemblies:
MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" xsp2
Not a perfect fix (I don't know why its going wrong), but if you're in a hurry, copy MySql.Web.dll to the bin directory of your app.

Resources