Develop Reference

A dependent dll was not found

My app does not run on "Release x86" when running the app it crashes immediately after the splash screen. Output shows the following exception:
The program '[8204] dfz.exe' has exited with code -1073741515 (0xc0000135) 'A dependent DLL was not found'.
It also tells me the module is build without symbols, however in build settings I have set debug info to Full.
The first time I build the app for the Windows Store it built correctly and I also published that version to the store. When I did a manual rebuild to check if ads where inserted correctly it would not run.
However, I can run the app on ARM and X64 with no problems on release. Only x86 with .Net native toolchain will throw the missing dependant DLL.
What I have tried so far:
Created a new project, Added all my files and Nuget packages, No dice
Removed and updated all my existing references.
Tried to debug the release version so i can find out what DLL is missing from the package. However it keeps telling me there are no symbol files.
I am looking for any suggestions I can try because I am really at a loss here of why it will not run on x86.
Edit:
A blank UWP project also returns the DLL error when i run it. It looks like i have a broken development environment.
Edit2:
Just did a remote debugging session to another laptop and the app worked with no problems. So the problem is an environment related issue.

Could one of the projects in your dependencies be configured specifically for x64?
Another thing to check is that one of your projects is not set to build for that configuration (I vaguely remember some problem I had years ago that sounds kind like your situation ... although not for windows store apps ... and it turned out one of my projects wasn't set to compile for the configuration I was selecting ).

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"

Deploying a .Net App Source Control (SVN) over 32-bit AND 64-bit dev stations

Here is the situation : Our Dev Team has heterogeneous OS systems, scattered between 32-bit and 64-bit. This is not ideal, we are actually planning to homogenize our infrastructure, but in the meantime we have to deal with it.
The issue is that when a 32-bit developer checks out a 64-bit solution on SVN, he has to manually change the target platforms all over again to get it compiled (not to mention other side problems)
My question is : What clean (though temporary) solution could be addressed in such situation, permitting each developer to keep his default project/platform settings while checking out and in from SVN.
I guess that -at least for the first time a project/solution is checked out, a dev still has to tweak the setting manually to compile it properly. After that, according to relevant SVN filters, it is possible to ignore some settings files (which ones, by the way?)
I am open to all clever and detailed suggestions.
Thanks.

Are you checking in .suo and .user files into source control? As these should be developer specific and should not be included. Pretty sure the suo maintains the build state of the project for each user.
Another option, is execute builds from scripts. For example I have 4 different build script files wired up with autohotkey to build in the background release and debug mode version of a project. This can be configured via msbuild or nant on how you want the project's configuration to look.
This has a benefit of not tying up visual studio.
It has a downside of further work customizing your solution, but long term I think you're in a better situation.

Is there a reason you're specifically targeting solutions at 32bit and 64bit?
eg: Native, unmanaged DLLs?
If you use the "Any CPU" platform option, then .NET will natively run it in either 64bit or 32bit mode depending on what's available on the machine.
Edit:
The other option if you must set the CPU Mode statically is to set up an x86-32 and x86-64 build configuration, and then have your developers select the appropriate build configuration on their end.
I would strongly suggest figuring out what's wrong with your AnyCPU mode though, as if you don't - you need two install packages for your users based on their OS mode.

As long as you are using only managed dotnet-code (no native 32/64bit code) every body can work with 32Bit solution only on 64bit and on 32bit dev-stations. On win7-64 visual studio also is a 32 bit app.

Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format

I just checked out a revision from Subversion to a new folder. Opened the solution and I get this when run:
Could not load file or assembly 'xxxx' or one of its dependencies. An attempt was made to load a program with an incorrect format.
This is the same code I had checked in a while ago. Why now is it doing this? I now also see a Debug x86 instead of just Debug in that xxx project's bin folder. What is Debug x86 and why don't I just have Debug only like I used to in the bin folder?

Sounds like one part of the project is being built for x86-only while the rest is being built for any CPU/x64. This bit me, too. Are you running an x64 (or uh... IA64)?
Check the project properties and make sure everything is being built for "Any CPU". f you're in Visual Studio, you can check for everything by going to the "x86" or "Any CPU" menu (next to the "Debug"/"Release" menu) on the toolbar at the top of the screen and clicking "Configuration Manager..."

If you get this error while running the site in IIS 7+ on 64bit servers, you may have assemblies that are 32bit and your application pool will have the option "Enable 32-Bit Applications" set to False; Set this to true and restart the site to get it working.

I had this error when trying to use the dreadful Business Objects 4 for .Net SDK.
They ship five BusinessObjects*.dll files, but all of them are 64-bit.
To get my webpage to load, I needed to click on Tools\Options, then change this setting in VS2013:

inetmgr then come to Application pool->Advanced setting of your pool-> will have the option "Enable 32-Bit Applications" set to true;
and restart IIS.
check again.!

Make sure you verify your setting for "Prefer 32-bit". In my case Visual Studio 2012 had this setting checked by default. Trying to use anything from an external DLL failed until I unchecked "Prefer 32-bit".

The BadImageFormatException on an application running on IIS (not running from VS, since visual studio fixes the problem by using the build for "Any CPU") can be caused by the following:
The site is one a server that is x64 and the Application Pool's default setting for Enable 32-Bit Applications was False. and you have 32-bit assemblies
On the level of Visual Studio, the fix is:
Change the project setting "Target CPU" to "ANYCPU"

It's definitely an issue with some of the projects being built for x86 compatibility instead of any CPU. If I had to guess I would say that some of the references between your projects are probably referencing the dll's in some of the bin\debug folders instead of being project references.
When a project is compiled for x86 instead of 'Any CPU' the dll's go into the bin\x86\debug folder instead of bin\debug (which is probably where your references are looking).
But in any case, you should be using project references between your projects.

if while In visual studio with IIS express working and when published failed try this:

In my case It worked by going to project Properties and under Target Framework i selected .NET Framework 4. This is because i have moved to a new machine that had other higher .NET frameworks already installed and the project selected them by default.
See what target framework works for you.

Debugging x86 .NET application on Windows x64 in VS2008

I use the x64 version of Windows 7. My application use some COM servers (usual native x86 COM Servers) that can't be loaded in x64 context. So I decided run it as a x86 application using WOW so I set platform target as x86.
But Visual Studio 2008 debugger started to show messages like "The source file is different...." for all source files when I try debug it. What is reason for this behaviour? This question was born there "The source file is different...." message in Visual Studio 2008 is result of debugging x32 apps on x64 Windows
Update: I cleaned solution, rebuilt solution, removed obj, bin and etc. folders, restarted computer, reinstalled Visual Studio... So, what else could be the problem?
Update2: If you create new Windows Application project and change target platform to x86 you will see this trouble. But if you delete Settings1.settings from project the trouble will be eliminated!!. Any Idea?
Update3: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/bc297668-65b4-46e8-969e-c7a6340d33b6

The error message you are getting is unrelated to debugging a WOW64 bit application. It's even less of an issue here because Visual Studio runs a 32 bit process inside of WOW64. So instead of x64 -> x86 you are actually doing an x86 -> x86 debugging session.
What's going on here is that Visual Studio is reading the checksum for the source files out of the PDB and it does not match the checksum of the files you are using to debug the application. The most likely causes for this are
Out of date PDB's
Using the incorrect source files. This is more common than you think in branching scenarios where you could easily grab the wrong version of the file.
The way I typically debug through this is
Close VS and manually delete all of the binaries and binary directories
Restart VS and rebuild
Close VS
Restart VS and attach to the running project without opening the solution
Then manually open the files

Windows 7 sets Windows Xp sp 3 compatibility mode for VS 2008 by default. Changing compatibility to Windows Vista SP2 mode have solved trouble.

You might also check the x86 build type. When you created it you may not of copied the settings from the default build and as such none of your code is building when you run your application.
Bring up the Solution Properties and check the Configuration Properties\Configuration page. Then make sure all of the projects are checked under Build for the Config/Platform combo you are using.