Develop Reference

to run this program you must install .net (for a net5.0 windows forms app windows 11)

I built a small C# windows forms project on Windows 11 using net5. It runs fine in debug mode under Vstudio 2019 latest (v16.11.8). If it helps any, the "dotnet --list-sdks" commands report that both .NET v5.0.404 and v6.0.101 are installed."dotnet --list-runtimes" reports that runtimes NETCore.App 3.1.22, 5.0.13, and 6.0.1 are installed, along with WindowsDesktop.App versions 3.1.22, 5.0.13, and 6.0.1.
When I build the app I use the post-build event to copy files to a different folder where I double click the .exe file to run the forms app. But the double click always tells me that to run the app I need to install ".NET" (exactly, no other info). Would you like to download it now? I click Yes, the popup dialog disappears, and nothing happens.
I copied the .exe first to the destination folder, and when that failed I copied the json config file, the DLL, and the .pdb file too. But still, no happiness.
I must be missing something simple since the app runs fine under vstudio.
I compared the contents of the Debug/net5.0-windows folder with my destination folder. The Debug folder had 44 other DLLs and a dozen language packs. I suspect that my .exe app cannot find all those DLLs for some reason. It should find them because of all the SDKs and runtimes that are installed. But I don't know enough about how to tell the .exe file to find and use all the installed SDKs and runtimes.
Can someone please tell me what I'm doing wrong and how I can get the exported file to run using the installed runtimes? Thank you.

You can publish it with a single executable option -
https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file#publish-a-single-file-app---visual-studio
You can do this via VS gui or with the .net cli like:
dotnet publish -r win-x64 -p:PublishSingleFile=true --self-contained false

IMO it's one of those cases where the error message is simply misleading.
Got this message even after having installed the latest .NET 5.0 runtime files.
And even after the suggested dotnet publish the application still wouldn't start on the target machine.
Turns out that, in addition to the .NET runtime files, there is also a "Windows Desktop Runtime". Only after installing the latter the app would start normally.

AutoIt (AutoItX) on C# Windows 7 App System.DllNotFoundException

I have a C# application that uses AutoItX for automation. This application works fine in my Windows 8.1 x64 environment compiled with Microsoft Visual Studio 2013 release 3.
I pushed a copy of the app code to a bitbucket repository and cloned it to a computer running Windows 7 x64. AutoItX version 3.14.2 was installed and the 32bit calls were selected. The application was compiled using Visual Studio 2013 release 4.
The app compiled fine, but the first use of the AutoIt functions resulted in an error:
An unhandled exception of type 'System.DllNotFoundException' occurred in AutoItX3.Assembly.dll
I tried the following steps. The app was tested after each of these steps
Attempted to register the .dll manually using regsrv32
regsrv32 "C:\Program Files (x86)\AutoIt3\AutoItX\AutoItX3.dll"
Uninstalled VisualStudio 2013 R4 and attempted to reinstall VisualStudio 2013 R3 {The installation of R3 failed because it required internet explorer version 10 and version 11 has already been installed on this computer} so R4 was reinstalled
Uninstalled AutoIt and reinstalled selecting the 64 bit library preference. Compiled the app with x64 Platform option
Uninstalled AutoIt and reinstalled using the 32 bit library preference
Compiled the app with the X86 Platform option
Manually copied AutoItX3.dll to the C:\windows\System32 directory
Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform
Wiped computer clean and reinstalled windows 7, AutoIt (32 bit preference), Visual Studio 2013 R4
Installed AutoIt v14
Installed the beta version of AutoIt v15
Performed a Windows update - 213 updates (!) installed
Installed Internet Explorer v11
Performed a Windows update - 4 updates installed
Installed AutoIt version 3.10.2 that worked on the Windows 8 system
I would appreciate suggestions on what to try next. I'm probably missing something very basic, but I just can't find a solution

Manually copied AutoItX3.dll to the C:\windows\System32 directory
Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform
That's the only thing you did wrong, you reversed the copies. There are no other DLLs you could be missing, the AutoItX3.dll and AutoItX3_x64.dll files themselves have no other dependencies that are not already available on any Windows machine. Just operating system DLLs, they've been around forever. Something you can see with Dumpbin.exe /imports.
And the exception message comes out of .NET, it is caused by a [DllImport] attribute. You can see the content of AutoItX3.Assembly.dll with a decompiler like ILSpy or Reflector. There is very little to it, only two DLLs are ever used. AutoItX3.dll for 32-bit code and AutoIt_x64.dll for 64-bit code.
Fairly tragic btw, otherwise a side-effect of ab/using the operating system directories for non-operating system DLLs. The only real way to make sense of why this is backwards is to know the history of Windows.
Back in the early days of Windows when it was still a 16-bit operating system (versions 1 through 3.11), c:\windows\system was the home directory for the operating system executables. Starting with NT 3.11 and Windows 95, the first 32-bit versions, that directory was renamed to c:\windows\system32. When the 64-bit version became available, Microsoft could not rename it to c:\windows\system64 anymore. Too many programs hard-coded the name of that directory in their source code. Breaking those programs would have been a good idea, just not a good strategy to get customers to move to the next version.
The 64-bit version has an emulator that can run 32-bit programs, it is called WOW64. "Windows on 64-bit Windows". The c:\windows\syswow64 directory is therefore the home directory of the 32-bit executables.
Exactly backwards from what the names would suggest. Just reverse the copies and that runtime error will disappear.
Generic advice applies:
The official way to get the loader to tell you about missing DLLs is to enable loader snaps. It is the most reliable way, albeit a bit clumsy.
Dependency Walker has not been maintained for a very long time and produces far too many false warnings. It also has a problem with .NET programs like this, it cannot see the dependency on AutoItX3.dll. You should still get something out of it when you use its Profile mode.
Process Monitor was always the best tool to troubleshoot missing DLLs. You'll see your program searching for the missing DLL, you can tell its name and the directories it looks in from the trace. Start near the bottom working backwards to avoid drowning in the data. I should however note that its been unreliable lately on the machine I use since ~Win81, the trace is just missing stuff I know should have been there. YMMV.

Such an issue can be caused by a missing DLL or a dependency of a missing DLL. I never got good results with Dependency Walker but I have successfully tracked down such issues with Process Monitor.
It should not be a 32/64 bit issue directly, since that would result in a BadImageFormatException instead.
You can debug missing DLL issues like this:
Start Process Monitor
Set a filter for your executable
Reproduce the issue (i.e. run your application)
Save the log in XML file format
Open the XML in Process Monitor Log Analyzer (Disclaimer: I'm the author of that free tool)
Check from top down which DLL is really missing. There may be some where the program can gracefully degrade, so not all of them are necessarily required.

Short solution
Copy and paste the AutoItX3.dll file to /bin/Debug or /bin/Release folder.
Project solution
What you can do is to put in the project's Post-build event command line:
copy /Y "$(SolutionDir)\packages\AutoItX.3.3.12.0\AutoItX3.dll" "$(ProjectDir)\bin\Debug"
 
copy /Y "$(SolutionDir)\packages\AutoItX.3.3.12.0\AutoItX3.dll" "$(ProjectDir)\bin\Release"

DLL Hell(p) - Works on dev box, but not any othe

3 Days of hair pulling. It just doesn't make any sense. I can't figure out what I've missed.
So I have this C#/WPF VS2013pro project I'm building that works fine on my Visual Studio machine: Win 8.1 x64 but fails due to 'dll not found' on any target PC I transplant it to.
It uses FreeImage, which has two DLLs:
FreeImage.dll - C++ that does all the work
FreeImageNet.dll - .NET wrapper to make like easy in C#
The two need to be in the same directory and preferably the same as the .exe - so they are.
My project is 64bit. I downloaded the source for FreeImage and compiled both DLL's for x64: First the CPP one, then the .NET one. Then copied them to the solution.
The .net DLL is referenced in my solution. The CPP does not reference, of course. Both are part of the solution and copy to the %outputdir% (Bin/Debug or Bin/Release) when the solution is built. The program runs fine in DEBUG and in RELEASE on my Development PC and the DLL methods do their job.
I copy the entire BIN directory to another PC running the same version of Windows, same updates, the works... The program runs but when a method is needed from the FreeImage.dll it fails with "unable to find dll".
To make sure I'm right about it using the dll from the BIN directory (and not from System32 or SysWOW64) on my VS machine I pull it out and run the app: Yep it fails.
I put it back and move the entire directory: It works
I pull it out: It fails
I put it back and move it to a thumbdrive: It works
{you get the idea}
So at this point it sure seems like it is really using the one in the same directory as the .exe and the .NET wrapper dll
I move the thumbdrive with the code that just worked on my VS machine to the other PC: It fails.
Next I try remote debug to the other PC: All the files copy to a matched directory, debugging starts and works, I get output and breakpoint behavior from the remote PC: Only the calls that require the DLL again fail because FreeImageNet.dll cannot locate FreeImage.dll
I did nothing special on my Visual Studio machine to make FreeImage work: I downloaded the source and compiled then copied the DLLs to the solution and referenced the .NET dll - That's it.
I have Googled, and researched and opened questions on SourceForge about it.
Every previous question I have found on this issue are cases of someone thinking FreeImageNet.dll was self-contained and not realizing it had to be located along side of FreeImage.dll
I have checked registry for I have checked registry for HKLM/System/CurrentControlSet/Control/SessionManager/KnownDLLs/
I have tried to register it with regsrver32 (yes, the 64bit flavor)
I have tried setting an environmental variable to it.
I have tried copying the DLL to every directory that is part of the DLL search order.
I have tried it on Win8.1x64pro (same as my Visual Studio pc) and two Win7x64pro machines.
I have assumed it was some weird quirk in 3.16 of FreeImage and done this again and again with previous releases as far back as 3.6, all with the same results.
I have built an installer for the solution and installed it on the VS machine where it worked, and installed it on the test machine where it failed.
I am trying for the first time (and not so successfully) to virtualize my physical PC. VMware has always been good to me for test environments and at this point I want to see if a total clone of the Visual Studio machine will succeed or fail with this project.
So... Anyone have an idea?

Darn it, I missed one: vcomp120.dll
Seems it is part of the Visual C++ redistributable that was installed with Visual Studio.
It should have dawned on me that I would need to include this, but with the entire EMGUcv package working... and the fact that I hate C++ and haven't used it in a dozen years... It totally never occurred to me.

Can you please try to import the dll with DLLIMPORT. Copy and place the dll to the directory same as of exe and use following code in Code behind:
[DllImport("FIBITMAP.dll")]
public static extern void Load(string param1,string param2,...);
Here Param1, Param2,... will be your parameters to the function Load.
Hope this helps.

How to Deploy c# project with all dependencies in visual studio 2012

I have created a small c# program in visual studio 2012, I used two external dll libraries. When I build the project for release, it creates the release file with a bunch of other files, including the external dll's I used. It works on my computer, but if I copy that whole release file to another computer it just gives me an error message and exits.
What else does the program need to run?
The error message is:
The application was unable to start correctly(0x000007b). click OK to close the application.

I suspect that your error code is actually 0xC000007B (STATUS_INVALID_IMAGE_FORMAT), rather than 0x0000007B (INACCESSIBLE_BOOT_DEVICE). The former is common when your application encounters a runtime mixup between the 32 and 64 bit versions of a DLL.
What could be happening is that your application (say it's 32 bit) has a dependency on a certain DLL, call it FOO.DLL. When run on your local machine, you are picking up the correct version of the 32 bit version of FOO.DLL on your path. But when you deploy to the other machine, you are picking up a 64 bit version from somewhere on the system path. The INVALID_IMAGE_FORMAT error is thrown when the loader finds a 64 bit DLL trying to be loaded into your 32 bit app.
One way to fix this is by identifying the DLL and redistributing the correct version with your application.

C# and FAXCOMEXLib

I'm using the FAXCOMEXLib api for sending faxes in C#. I've recently moved to a new development machine running Vista and now I'm running into an issue with the API. Microsoft released a new version with Vista and now when I compile the application on the Vista machine, I can't install and run it on an XP box without getting a fatal exception.
My question is, whats the best way to go about being able to compile and prepare installations on the Vista machine, but still allow the use of the application on XP? Do I have to actually have an XP box available to do a final release compile or is there a way to get around these problems?
Thanks for any help with this problem.

Not exactly an answer but may help:
I got this from Experts Exchange:
After much tribulation, I found a
solution.
The root cause of the problem is
simple: the version of FAXCOMEXLib in
Vista is different than that of XP.
So, when I built the solution in
Vista, it built the Interop wrapper
around the newer version, that found
in the system32 directory, regardless
of what actual fxscomex.dll file I
referenced. So, it was always wrapping
around a version of the file
incompatible with XP.
To work around it, I built the
solution on an XP box, then stole the
Interop wrapper from that build. I
then wrote a batch file that I run
when I copy the build onto the XP box.
The batch file gets rid of the
existing Interop wrapper, replaces it
with the wrapper I stole from the XP
build, gets rid of my assembly (called
fax.dll) that references the Interop
wrapper, and recompiles it from
scratch on the XP box using the
csc.exe tool and the original fax.cs
file. In other words, I essentially
beat the files into submission until
they point to the right version of the
FAXCOMEXLib library. For clarity,
here's the batch file that converts
the Vista-compatible version of the
program to an XP-compatible version:
***** del Interop.FAXCOMEXLib.dll del fax.dll ren
Interop.FAXCOMEXLib.dll.fix
Interop.FAXCOMEXLib.dll
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc"
/t:library
/r:Microsoft.Practices.EnterpriseLibrary.Common.dll
/r:Microsoft.Practices.EnterpriseLibrary.Data.dll
/r:Interop.FAXCOMEXLib.dll
/out:Fax.dll fax.cs
Not very elegent or pretty, but it
does the trick.
I would imagine that this would be an
issue with any old COM .dll on XP that
has been updated to a new version for
Vista.
Thank you cpkilekofp for taking a
look. Admin, you may close this
thread.
Hope this helps.