I had a problem running my C# application throwing the following error when trying to use a certain reference as follows:
Could not load file or assembly 'My3rdPartyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)"
Then I followed this answer for signing the assembly in question.
I can confirm via Visual Studio and Sn as well that my DLL is now definitely signed and has a strong name.
However I am seeing 2 things:
On my signed version of the application I still get the same error as above as if the assembly does not have a strong name.
On my unsigned version which was working fine until now with the unsigned DLL, it now throws the same error with the signed version of the DLL.
I am out of clue on what could be the reason.
Thx for the help.
It turns out that I was able to solve it. I was updating the third-party library (the assembly that I want to sign) so that it can work well with my .exe BUT it gets replaced by an unsigned version that came from the NuGet package.
You'll have to update the .dll in the following location:
I will have instruction for an example package named WPFCustomMessageBox.dll. Follow the ff. steps to update the package and have it reflect on the debug folder:
Open cmd in the path provided above.
Type the ff. You should organize the path in your system as your folder structure and where your files are located may not be the same as mine:
a. This one gets the necessary files from the .dll
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\Ildasm.exe" /all /out=WPFCustomMessageBox.il WPFCustomMessageBox.dll
b. I'm not sure what this one does but it preps the file for the next command.
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Ilasm.exe" "WPFCustomMessageBox.il" /dll /resource="WPFCustomMessageBox.res" /key="publickey.snk"
c. This one creates the signed .dll
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\sn.exe" -R "WPFCustomMessageBox.dll" "pair.pfx"
Type the password for your .pfx file and it should make the signed .dll.
I've tested this method with the aid from Adding a Strong Name to a Third-Party Assembly. The next time you compile, the former unsigned .dll that gets compiled/copied over to the Debug folder should be signed. Hope this helps :)
Related
I am working on an Azure Functions project which targets .NET Standard 2.0.
It builds successfully, but when I run it locally, the following error occurs:
Could not load file or assembly 'Microsoft.Extensions.Options, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
I understand that it cannot find the above DLL.
What is confusing to me is that Nuget Package manager indicates that it IS installed.
I am using Process Monitor to verify where the build engine is probing for this dll.
Here is where it probes for Microsoft.Extensions.Options.dll
C:\dir1\Solution\ProjectName\bin\Debug\netstandard2.0\Microsoft.Extensions.Options.dll
C:\dir1\Solution\ProjectName\bin\Debug\netstandard2.0\bin\Microsoft.Extensions.Options.dll
The above is confusing me because, it IS installed here:
C:\dir1\Solution\ProjectName\bin\Debug\netstandard2.0
I can see it using the File Explorer. The precise version is 5.0.20.51904 (right-click the dll, Details tab, File version field).
However, it does NOT appear in
C:\dir1\Solution\ProjectName\bin\Debug\netstandard2.0\bin\
No matter how many times I clean and rebuild, or manually delete the above bin folders, Microsoft.Extensions.Options is never generated in
C:\dir1\Solution\ProjectName\bin\Debug\netstandard2.0\bin
At this point, I'm confused and not sure what to do next, because the binding engine is telling me that it cannot find something, which is indeed where it is looking. How can I solve this problem? How can I get the binding engine to use the dll which I have explicitly installed?
It also probes these folders as well:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\Microsoft.Extensions.Options.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\Microsoft.Extensions.Options.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\Microsoft.Extensions.Options.dll
C:\Program Files\IIS\Microsoft Web Deploy V3\Microsoft.Extensions.Options.dll
Extra info:
Azure Functions Core Tools
Core Tools Version: 3.0.3284 Commit hash:
98bc25e668274edd175a1647fe5a9bc4ffb6887d
Function Runtime Version: 3.0.15371.0
One of our build agent servers does not have System.Data.SqlXml Version=2.0.0.0 under C:\Windows\assembly but every other machine we have does. Unfortunately this causes nunit-summary.exe on that box to fail with:
EXEC Could not load file or assembly 'System.Data.SqlXml,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or
one of its dependencies. The system cannot find the file specified.
error MSB3073: The command ""../tools/nunit-summary.exe" artifacts/Test_*.xml" exited with code -1.
I tried installing MSXML 4 to no avail. I have not been able to figure out how to install version 2, any ideas?
Two possible solutions.
a) In the project, expand references to find the reference to the library. Go to properies and set Copy Local to be True. The .dll will then be included in the bin folder when the project is built.
b) Install SQLXML from Microsoft (this is different to MSXML which you tried). Details about the library (including the download link) are available at https://learn.microsoft.com/en-us/sql/relational-databases/sqlxml/what-s-new-in-sqlxml-4-0-sp1
I'm trying to create a single-file executable. The code is .Net-based and also relies on some additional libraries including SQLite.
When I compile the source code, all of the relevant files go into the Release directory, although the SQLite DLL (sqlite3.dll) goes into a sub-directory (x86). I think this happens because I'm using SQLite-raw and that "spits out" both x86 and x64 copies of the DLL.
My initial command line to try is:
ILMerge /out:GEDtoRH.all.exe GEDtoRH.exe *.dll /target:exe /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2" /wildcards /log
This produces the following output that worries me:
AssemblyResolver: Assembly 'System.Runtime.WindowsRuntime' is referencing assembly 'System.Runtime'.
...
AssemblyResolver: Did not find assembly in framework directory.
AssemblyResolver: Unable to resolve reference. (It still might be found, e.g., in the GAC.)
AssemblyResolver: Assembly 'System.Runtime.WindowsRuntime' is referencing assembly 'System.Threading.Tasks'.
...
AssemblyResolver: Did not find assembly in framework directory.
AssemblyResolver: Unable to resolve reference. (It still might be found, e.g., in the GAC.)
AssemblyResolver: Assembly 'System.Runtime.WindowsRuntime' is referencing assembly 'System.IO'.
...
AssemblyResolver: Did not find assembly in framework directory.
AssemblyResolver: Unable to resolve reference. (It still might be found, e.g., in the GAC.)
Location for referenced module 'sqlite3' is ''
Should I be concerned about the unresolved references? The reason I ask is because the finished executable doesn't work. It breaks with a null reference exception (Object reference not set to an instance of an object) on this line:
file = await StorageFile.GetFileFromPathAsync(filename);
The un-merged version of the executable works fine :( It isn't "filename" that is broken as I've tried adding some extra tests and it is fine.
Try as I might to add the sqlite3.dll to the list of things to ingest, if I try, ILMerge just complains with a "Could not load assembly" error.
As SQLite is not a .NET library it doesn't contain any IL to be merged
I'm having little problem running my C# application after switching to Windows 8.1 from 8.
The problem is that I get this exception from title and there's not much help online. I tried to pinpoint the problem and it seems like my x64 application is trying to call x86 CSharp library. The reference in project leads to a DLL file, that upon calling x64 dumpbin program with /headers parameter outputs:
Dump of file Microsoft.CSharp.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
14C machine (x86)
3 number of sections
4FFA5C64 time date stamp Mon Jul 09 06:21:56 2012
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2022 characteristics
Executable
Application can handle large (>2GB) addresses
DLL
Notice the machine is x86, while the application is running in x64 (checked with Environment.Is64BitProcess). This might be the problem I'm facing, however I can't find way to solve it - there seems to be no x64 .Net libraries installed. The only ones I have found are at: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework. Or maybe I'm completely off and there's some other problem. Anyway the exception occurs at startup in one of constructors and full detail is:
Microsoft.CSharp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
"Could not load file or assembly 'Microsoft.CSharp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The module was expected to contain an assembly manifest."
Edit:
While still panicking, I solved this by downloading CSharp.dll and replacing the dummy 0-byte file in path shown in answer by it.
The module was expected to contain an assembly manifest
You've been looking at a reference assembly, it is not the one that's actually loaded when you run your program. Microsoft.CSharp.dll is stored in the GAC, put there by the .NET installer. You can see the file by navigating to c:\windows\microsoft.net\assembly\gac_msil\microsoft.csharp. Keep clicking until you get to the file.
The exception message is a very unhealthy one, it doesn't recognize the DLL as a .NET assembly. There are few decent explanations for that, other than the file being corrupted. File corruption is always bad news, a strong hint that your hard-disk is failing. You'll need to get it fixed, follow-up if necessary at superuser.com
I have got this error when using Enterprise Library 3.1 May 2007 version. We are developing a product and have a common lib directory beneath the Subversion Trunk directory
<>\Trunk\Lib\ into which we put all the third party DLLs. Inside this we have Microsoft\EnterpriseLibrary\v3.1 in which we have copied all the dlls from \Program Files\Microsoft Enterprise Library May2007\bin. Everything was working properly until one of the developers installed the source code on this machine. There were some dlls copied at the end of the source code installation and once that was done, he is not able to run the project anymore. He always gets this error
'Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
What is the problem here? I thought that when the source code was installed it was just supposed to build everything and copy in the bin directory within the source code parent directory. Also we have copied the Dlls from Microsoft Enterprise Library May 2007\bin directory into our product development directory and references into our project with a copylocal flag set to true.
Can anyone help me out here
RK
I used to get that when I developed against the signed version of the dll and deployed where only the unsigned version was available.
Also, fuslogvw.exe. EVERY. TIME.
I assume the error lies in the developer having compiled the code against the unsigned source code compilation he has.
Make sure he adds the reference to the signed DLLs before compiling his code.
Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null
should be something like:
Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=fa03fef243232
maybe you should check the Assembly- and FileVersion of the dll. if they do not match this exception can occur.
Read here to get started with assembly loading debugging.
In short you need to check the Fusion log for more information.
For a "The located assembly's manifest
definition with name [yourAssembly]
does not match the assembly reference"
message (for hresult
FUSION_E_REF_DEF_MISMATCH,
0x80131040): The Fusion log will say
which part of the assembly reference
failed to match what was found. It
will be the assembly name, culture,
public key (or token) or version (if
the found assembly was
strongly-named).