Unable to Get CodeDom dll to build, mismatch Assembly - asp.net

I am running a 4.6.1 .NET Azure API. I'm trying to debug it locally, and I get this error.
The exact error says
Could not load file or assembly 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Now, I have searched for the standard responses. I checked my package config first:
Sure enough, it's the right version of 1.0.2. I then checked my reference to make sure my version is what it says it is.
So I check my local assembly just in case as well. Looks on point.
So what am I missing? Where else could it not match? The only solution I have found is to point the project's build settings to 'bin\' versus 'bin\debug', but that feels way too hacky.

What worked for me was simply uninstalling that package: Microsoft.CodeDom.Providers.DotNetCompilerPlatform
The code worked just fine with out it in my case. I was able to re-install the package and the code continued to work just fine as well. Git seems to think all the package files that came back are different to those that were there before uninstall.
I'm not sure why this worked, but it got me developing again.

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.

Migrated NuGet package source into solution but cannot load it's built DLL

I have pulled an in-house NuGet package's source into a new class library project of my solution, removed all references to the original package and referenced the class library. The solution builds just fine but when I run it I get the classic...
Could not load file or assembly 'Standards.Environment, Version=12.8.0.0, Culture=neutral, PublicKeyToken=e1f2345a678912bc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I've searched SO and tried the solution here: How to resolve “Could not load file or assembly... to no avail.
What I don't understand is that I get the above error even though the AssemblyInfo.cs of the Standards.Environment class project contains these lines:
[assembly: AssemblyFileVersion("12.8.0.0")]
[assembly: AssemblyVersion("12.8.0.0")]
Have I forgotten to do something when migrating the source code into my solution?
EDIT I have discovered that one of the other in-house NuGet packages is referencing the same package which I have removed (because I migrated its source into the solution.)
How can I force the other NuGet's DLL to accept the DLL of the class library as the dependency it is looking for?
The cause of the problem was that I had removed a NuGet package which contained the DLL which another NuGet package was looking for. When I migrated the original NuGet source into my solution it broke the references.
The solution was to switch back to using both NuGet packages and let them sit happily alongside each other OR import both.
Not particularly happy with this, but reverting back to a previous version of the solution and solving the real problem (an unrelated bug) was easier once I understood this.

ASP.NET Project stopped working after updating to VS2017: Could not load file or assembly 'System.Runtime.InteropServices

I have an ASP.NET project that worked perfectly in my previous Windows installation with VS2015.
I've clean installed Windows, VS2017, and cloned the git repo. Restored NuGet packages and started to get the following error on one of my 3 web projects:
Server Error in '/' Application.
Could not load file or assembly 'System.Runtime.InteropServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Interestingly, I'm only getting this error on one of the 3 web projects while the others run just fine.
What might be the problem?
After further investigation, I've realized that there were many dependent assembly redirections. I've removed all of them, explicitly added System.Runtime.InteropServices as a package, and the problem was solved.
I have no idea why it was the case in the first place though.

`ExceptionHandling` not found?

I'm referencing System.Web.Http.dll, full path:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Http\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Http.dll
However, I'm getting a compile exception saying that it can't find ExceptionHandling in the System.Web.Http namespace.
The type or namespace name 'ExceptionHandling' does not exist in the namespace 'System.Web.Http' (are you missing an assembly reference?)
Looking in the file, it is indeed not there.
I have been updating NuGet packages, so I'm assuming it's been moved\replaced with something.
Where do I need to go now to get this namespace? The internet seems quite quiet on this.
OK, the solution was odd. Not sure how the project ended up in this state.
The fact that the reference was pointing to C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Http\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Http.dll showed that it wasn't using the assemblies provided by the package, which were in the packages folder.
I had to explicitly delete the references, then roll back the version of Microsoft.AspNet.WebApi.Core as VS wouldn't let me uninstall it as the project wouldn't compile (at least I assume that was why, never had that before though).
That re-added the assemblies with the correct paths, that being, paths to the packages folder.
I also stuck and your suggest solve my problem
my step is here
remove Reference System.Web.Http
remove Nuget Microsoft.AspNet.WebApi.Core
restart Visual Studio
try to install Nuget Microsoft.AspNet.WebApi.Core again

Could not load file or assembly 'Syncfusion .. On deployed version

http://pastebin.com/5Ph3BfD3
I am getting the message
Parser Error Message: Could not load file or assembly 'Syncfusion.Core, Version=11.4451.0.26, Culture=neutral, PublicKeyToken=632609b4d040f6b4' or one of its dependencies. The system cannot find the file specified.
I have set copylocal to true in my project on each of the references
They are in my BIN folder on the local machine, the
The parser and the line on the web.config refer to different versions; can anyone tell me what I can to sort this out.
Frustrating!
Your config file is looking for a specific version of SyncFusion. Does the version number match the version of the syncfusion assembly?
If not, either get the correct assembly, or update the web config. Also see this if it is relevant: Target non specific version of an assembly
I have raised this with SYncfusion Tech support, they are going to see if they can reproduce it on Azure

Resources