Exception from HRESULT: 0x80131047

Question

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

Visual Studio error dialog

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?

score 61 · Answer 1 · edited Dec 18 '21 at 15:06

61

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

edited Dec 18 '21 at 15:06

Tomerikoo

18,379
16
47
61

answered Nov 25 '16 at 03:26

Ivandro Jao

2,731
5
24
23

2

Viable but really old error tbh, +1 for the alternative solution, thanks – Omarrrio Nov 29 '16 at 19:30
@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 https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load?view=netframework-4.8#System_Reflection_Assembly_Load_System_String_) and not the file name, and this is exactly what the error message states in that the assembly name is invalid – yoel halb May 22 '19 at 04:51
1

So the message should be "long assembly name required" with a link to the document. The current message is totally misleading. – Paul McCarthy May 23 '19 at 02:10

score 23 · Accepted Answer · edited Dec 18 '21 at 05:01

23

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

edited Dec 18 '21 at 05:01

Wai Ha Lee

8,598
83
57
92

answered Sep 21 '12 at 10:08

Omarrrio

1,075
1
16
34

Leo Gurdian · Answer 3 · 2013-04-30T17:15:58.050

11

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!

edited Apr 30 '13 at 17:15

answered Apr 30 '13 at 16:41

Leo Gurdian

2,109
17
20

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. – user8597 Feb 26 '20 at 21:08
Changing the Target CPU from 64-bit to ANY CPU solved this problem for my PowerPoint VSTO AddIn. Thanks a bunch!!! – Mike Meinz Feb 24 '23 at 19:21
@MikeMeinz I'm glad that helped out! : ) it's a tricky one given a very vague/generic error code. – Leo Gurdian Feb 28 '23 at 08:46

score 5 · Answer 4 · answered Apr 11 '18 at 13:25

5

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.

answered Apr 11 '18 at 13:25

Lvpdev

51
1
2

score 2 · Answer 5 · answered May 06 '14 at 09:15

2

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.

answered May 06 '14 at 09:15

user3541373

31
1

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. :-) – Super Jade Jan 02 '20 at 21:59

score 2 · Answer 6 · answered Mar 16 '18 at 15:03

2

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

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

</Configuration>

answered Mar 16 '18 at 15:03

Rhyous

6,510
2
44
50

score 2 · Answer 7 · answered May 04 '21 at 17:05

2

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);

answered May 04 '21 at 17:05

The Modulator

51
1
7

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 – Walter Verhoeven Nov 15 '21 at 18:38

Exception from HRESULT: 0x80131047

7 Answers7

Linked