We Keep Coding

assembly load error on C# exe which has been modified to export a variable

Working on a C# .NET application for Windows Desktop which does 3D rendering. On laptops with dual video card configs (integrated Intel video and NVidia for example), the problem can arise that the user has not changed the NVidia control panel setting to prefer the NVidia card. As a result the app may pick the integrated video and perform poorly.
Were this unmanaged code, one could do the below to export an integer from the main exe and apparently the NVidia software will detect this and then force the app to run with the NVidia card without the user having to change the control panel setting (requiring them to do this isn't realistic and it results in a bad first impression of application performance).
extern "C" {
_declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
}
In order to do the above with a .NET C# executable (it has to be the main exe not a DLL apparently), I'm attempting to use the approach outlined at the below link.
http://lucasmagder.com/blog/2014/05/exporting-data-symbols-in-c-for-nvidia-optimus/
The approach there is to, in post-build, dissassemble the .exe, then modify the IL, inserting the below at the start of a dummy method and then re-assemble the modified IL creating a new exe.
.export [0] as NvOptimusEnablement
Then at runtime there's some more stuff it does to get the value set. But, the issue is that when we try and run we get the following error from assembly loading.
Could not load file or assembly '...' or one of its dependencies. Attempt to load an unverified executable with fixups (IAT with more than 2 sections or a TLS section.) (Exception from HRESULT: 0x80131019
Searching on this error suggests that this is caused by a managed assembly which also contains unmanaged code, which is of course exactly what we're trying to do (Exception with Resolving assemblies: Attempt to load an unverifiable executable with fixups).
Anyone else have experience with this? I'm guessing back when that workaround was created this all worked, but maybe the assembly loading is more strict now? Anyonw know of a workaround?

Where exactly is .NET Runtime (CLR), JIT Compiler located?

This question might look a bit foolish or odd but I have heard a lot of about .NET CLR, JIT compiler and how it works blah blah blah... But now I am wondering where exactly it is located or hosted.
Is it -
Hosted as a part of Windows Operating system when we actually install .NET Framework?
OR
It is a part of some .exe which we can see in task manager
I am looking for the detailed answer on this. Someone might frame this question as "How Windows Operating System triggers/executes .NET Executable inside .NET Runtime?

where exactly it is located or hosted
It is just a plain DLL, you'll find back the x86 version of it in C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll. The x64 version is in the Framework64 directory. The .NET v2 version had a different name, mscorjit.dll, find it back in the v2.0.50727 directories.
It is not "hosted" at all, the operating system is completely unaware that it exists. The CLR knows how to locate and load it. Necessarily so, it is the CLR that decides when to start a program. It simply has the DLL name hard-coded and use LoadLibrary("clrjit.dll") to load it, GetProcAddress("getJit") to get the factory function. Something you can see back in the CoreCLR source code, albeit that the jitter is not a separate DLL anymore in that CLR version.
You can see the CLR with Explorer as well, again just a plain DLL. It is clr.dll in the v4 versions, mscorwks.dll and mscorsvc.dll in the v2 versions. Two different ones back then with different garbage collectors, "wks" is the workstation version, "svc" is the server version. Compare to the <gcServer> config file entry.
Which moves the question to "how does the CLR get loaded?" That's the job of c:\windows\syswow64\mscoree.dll, you'll use c:\windows\system32\mscoree.dll when you target x64 in your EXE project. Every .NET assembly has 5 or 9 bytes of unmanaged code, a jump into that DLL. Either _CorExeMain or _CorDllMain, depending on whether the assembly was built as an exe or a library. mscoree.dll takes a look at the metadata in the assembly and decides what version of the CLR needs to loaded so it can be properly executed.
Lots more shenanigans going on, I just posted the 10,000 feet view you asked for. If this interests you then you probably want to find out more about custom CLR hosting to see the man behind the curtain.

How Windows Operating System triggers/executes .NET Executable Runs
inside .NET Runtime?
Every .NET managed assembly or executable has special CLR headers, which you can see by viewing the assembly in ILDASM. This headers points to the version of the runtime that needs to be loaded. Also, there is the Image Section with the Import Address Table, pointing to what needs to be loaded:
----- Image sections:
Import Address Table
DLL : mscoree.dll
0x00002000 Import Address Table
0x0000a37e Import Name Table
0 Time Date Stamp
0 Index of First Forwarder Reference
0x0000 _CorDllMain
----- CLR Header:
Header size: 0x00000048
Major runtime version: 0x0002
Minor runtime version: 0x0005
0x00003184 [0x00007078] address [size] of Metadata Directory:
Flags: 0x00000001
Entry point token: 0x00000000
0x00000000 [0x00000000] address [size] of Resources Directory:
0x00000000 [0x00000000] address [size] of Strong Name Signature:
0x00000000 [0x00000000] address [size] of CodeManager Table:
0x00000000 [0x00000000] address [size] of VTableFixups Directory:
0x00000000 [0x00000000] address [size] of Export Address Table:
0x00000000 [0x00000000] address [size] of Precompile Header:
When ran by the operating system, mscoree.dll (or The Shim) is loaded, and it is the bootstrapper to clr.dll and clrjit.dll for .NET 4.0 and above, or mscordacwks.dll and mscorjit.dll for .NET 2.0 or below, which are the runtime and the JIT, respectively. You can see that the native dll entry point is instructed to be the _CorDllMain method for a class library, and _CorExeMain for an executable, which is responsible for the loading and jitting of the entry point. They, in turn, will call your applications entry point, in the managed environment.

This is based upon my understanding and will guide you towards you answer, but may not be fully flushed out.
The EXE/DLL files that make up the DotNet Runtime (CLR, etc.) are located in the following locations:
C:\Windows\Microsoft.NET\Framework // for the 32 bit runtime
C:\Windows\Microsoft.NET\Framework64 // for the 64 bit runtime
Within there, you have the different editions such as 2.0.50727, 3.0, 3.5, and 4.0.30319 (versions on my system today).
This is where MSBuild, as well as the files that are registered with IIS are located and run from.
I don't know if this ends up being hosted by Windows at runtime, or if there is an actual EXE you could attach to with a debugger and see in the task manager.
Hopefully this provides some more insight for you.

Unable to load dll file - exception 0x8007007E

I'm working with National Instruments Measurement Studio in C#, and I've come across a bit of a problem in deploying my application to a particular computer (running Windows 7). I've tried asking on the National Instruments forums, but haven't got any solutions yet - could anyone here give me some tips?
Essentially, I have deployed this application several times on a number of computers, but in this particular case I receive an error when running the program -
"System.DllNotFoundException: Unable to load DLL 'nianlys.dll': The specified module could not be found. (Exception from HRESULT: 0x80070007E)
I have ensured that nianlys.dll is present in C:\Program Files
(x86)\National Instruments\Shared\Analysis.
I have ensured that libiomp5md.dll and LV110000_BLASLAPACK.dll, the files from mkl.msm (nianlys.dll has a dependency on mkl.msm), are present. nianlys.dll also has a dependency on nimetautils.msm, but I'm not sure which dlls are included in this.
I have ensured the program is installed by running the setup.exe as an administrator (as opposed to running the .msi that is generated, see here).
I have ensured the computer in question is up to date with updates to the .net framework via windows update.
I have tried reinstalling the program several times, sometimes with a freshly-recompiled installer.
I have tried adding in the 64 bit nianlys.msm into the setup project manually - this throws an error because the TargetPlatform property of the setup project is set to x86. The 32 bit version is, of course, already present in the detected dependencies.
Interestingly, taking a copy of nianlys.dll from C:\Program Files (x86)\National Instruments\Shared\Analysis and inserting it into the directory the program is installed in throws up a different error - in this case, the error is:
"An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Taking a copy of the 64 bit version of nianlys.dll from another computer (default location C:\Program Files\National Instruments\Shared\Analysis) and inserting it into the directory the program is installed in throws up a third type of error - "System.DllNotFoundException: Unable to load DLL 'nianlys.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)". It should be noted that this .dll was present before installing the program on the machines that the program works on, but is not present on the target computer that is throwing up problems.
Taking the same 64 bit nianlys.dll and inserting it into the location it was found on on another computer, C:\Program Files\National Instruments\Shared\Analysis, does not solve the original error.
Even more interestingly, I have tried to reproduce the error on a computer on which the program works - removing the x64 version of nianlys.dll throws up the original HRESULT: 0x80070007E error, whereas removing the x86 version causes a windows installer to appear when running the program.
On a computer upon which the program works with no problems, the windows task manager does not seem to indicate that the program is 32 bit (with the *32 suffix on the program name), despite the target platform being set to x86. It seems from all this that there is some issue with the nianlys.dll being used in both its x64 and x86 versions, despite the target platform only being x86.
I'm running out of ideas about what kind of thing I could try to solve this problem.

I suspect that even though the setup is for X86, the project itself is AnyCPU and thus runs as a 64bit process on 64bit systems and as a 32bit process on 32bit systems. As you said your DLL is in the Program Files (x86) folder I assume it is 32bit only, so you should compile your application explicitly as x86, too. It is your bullet #7 that leads me to this conclusion.
Just copying the nianlys.dll 64bit DLL doesn't seem to work as it seems to rely on other DLLs it then can't find. (bullet #8).

It may caused by the dependents of nianlys.dll are not found. You can diagnose this problem with the process monitor , one of the system internal tools. It can capture the loading/unloading DLL activities, so if something wrong, you can find it in the log.
Be sure to use the filter when use this tool, otherwise the log file will be huge.

Unable to load DLL in C#

how to load a dll in a c# project
error:
Unable to load DLL 'Reader.dll': The specified module could not be
found. (Exception from HRESULT: 0x8007007E)
code sample:
[DllImport("Reader.dll")]
public static extern byte OpenReader(ref IntPtr hCom, byte LinkType, string com_port);
image:

If the problem is really "cannot be found", then using ProcMon from Sysinternals will show you where the system is looking for the DLL.
However, often these sort of exceptions mean 'I found the DLL but I can't load it', and that can be because a dependency of the DLL is missing rather than the DLL itself, or because the DLL is incompatible with the app trying to load it. If your C# app is set for 'Any CPU' and you're on a 64bit machine, you'll get this sort of error loading unmanaged 32-bit DLLs.
One way to isolate the problem would be to create a simple C/C++ project which loads the DLL. (Load it dynamically with LoadLibrary if you don't have access to the import lib.) Then use Dependency Walker to profile the test harness, and it will report the names of missing DLLs.

Although the reader.dll is unable to load GPSVC.dll and IESHIMS.DLL.
i managed to make it work by running the corflags command on application.exe
the application is now marked as 32bit:
corflags application.exe /32bit+
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 3
ILONLY : 1
32BIT : 1
Signed : 0

I found this in another post. Maybe it will help your situation
NUnit "missing" GPSVC.DLL on Windows 7/64

If it's a simple C DLL it just needs to be in the same folder as the .exe.

For me the solution was to installing the C++ Redistrable X64 on client machine.
(Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019.)
The dll was already on the right place, in the same folder than the .exe file.
Here you found the download link:
https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0

Could not load file or assembly, PublicKeyToken=null

Could not load file or assembly 'NCrawler.GeckoProcessor,
Version=3.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies.
When I call CrawlUsingGeckoProcessor.Run();
What does this mean? I can click "go to definition" and I can see the Run() method.

This error usually means that the assembly was not found.
Try verifying that the file exists in the directory where your application is running.
If you still can't figure out which file fails loading, try using a tool such as Fusion Log Viewer (run fuslogvw.exe from the Visual Studio command prompt), to determine which files the CLR was trying to load and from where, so that you can see exactly what failed.

I experienced the same problem, and the reason was that I compiled my EXE and DLL on 32 bit machine for "x86", because it depends on C++\CLI library compiled for Win32. Then I tried to use this library on 64 bit machine from 64 bit process. Obviously 64 bit process can't load 32 bit libraries, so I got this error, which does not really help to understand the problem.
So the reason could be that you try to use 32 bit library from 64 bit process.

Building over nogard answer, try setting the Solution Platform to x86

try going to app advance settings .. Enable 32 bit processing ..
if the app was built in .net 2.0 and current server is IIS 7