Exception from HRESULT: 0x80131047

Question

I am having this problem whenever I try to debug my project:

It's in French, here is my translation:

"Error while trying to run project: Failed Loading assembly "DBZ buu's Fury Text Editor" or one of it's dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)"

Can anyone help me please?

Susannsusanna

Answer 1

Project > Project Properties > Name > remove the apostrophe ("'") from the name, and it will work.

Susannsusanna

Answer 2

If you are using Assembly.Load() to load file try to change it with Assembly.LoadFile() instead.

Kielty

Viable but really old error tbh, +1 for the alternative solution, thanks – Susannsusanna

@PaulMcCarthy Assembly.Load is supposed to work, but with the long assembly name (i.e. "SampleAssembly, Version=1.0.2004.0, Culture=neutral, PublicKeyToken=8744b20f8da049e3" see learn.microsoft.com/en-us/dotnet/api/…) and not the file name, and this is exactly what the error message states in that the assembly name is invalid – Injector

So the message should be "long assembly name required" with a link to the document. The current message is totally misleading. – Georginegeorglana

Answer 3

It may not necessarily be related to that as in my case...

First, I would like to say that this was a very hard issue troubleshoot as there may be many variables leading to the actual problem related to assemblies.

So I was working on an Outlook Add-In 2010 targeting the 32-bit version of Office. Everything was working fine until one day out of the blues, the add-in wouldn't load anymore and I was presented with error "HRESULT: 0x80131047". After searching almost half a day I found a nice article:

http://blogs.msdn.com/b/astebner/archive/2007/05/06/2457576.aspx

I tried adding the assembly to the global cache but was unable to. Luckily, I had an almost identical project which ran just fine and I had already done comparison checks and everything seemed the same, but on this pass I found something different ... as it turned out the platform target CPU was set to 64-bit so I changed it to "Any" and voila'! - this fixed it!

Pulsimeter

Changing to "Any" worked like a charm. Just make sure ALL of your target CPU dropdowns are set to all. Found one (of two) nestled in the "Build" Window that I kept overlooking. – Lid

Changing the Target CPU from 64-bit to ANY CPU solved this problem for my PowerPoint VSTO AddIn. Thanks a bunch!!! – Maloy

@MikeMeinz I'm glad that helped out! : ) it's a tricky one given a very vague/generic error code. – Pulsimeter

Answer 4

I had an invalid .\Properties\licences.licx file that was causing this problem. This file is automatically generated by DevExpress components.

I just deleted this file and voila: Build Succeeded.

Nissa

Answer 5

For anyone else that stumbles across this article and determines that their naming convention is correct and they are using the LoadFile method...

Here is the solution I came up with:

byte[] data = System.IO.File.ReadAllBytes(filename);
Assembly assembly = Assembly.Load(data);

Quadrivium

the best answer in my opinion, I would however test if the file is "valid" by looking at the codesign certificate else the program might be easy to exploit. perhaps update the answer and use X509Certificate.CreateFromSignedFile – Pinion

Answer 6

This MSDN forum post says that you need to take "special" characters such as slashes, commas, or apostrophes out of your assembly name to avoid that error.

If that doesn't fix it, another suggestion there is to uncheck "Enable the Visual Studio Hosting Process" in the Debug tab.

Myriad

An apostrophe was the problem with my .NET Core Web API. I started a new project without the apostrophe in the name, and the starter application runs. :-) – Caesura

Answer 7

I had an invalid App.Config file that was causing this.

Somehow, I was missing the final closing tag to the main element.

</Configuration>

Brisbane