I am creating a console application. It uses third party .DLL. My PC has latest version (say 2.3.0.0). When I run this application on other PCs (by copying the .exe file), I get FileNotFound exception that it can not find the .dll with version 2.3.0.0. The other PC had version of 2.1.0.0 which will suffice based on
How do I tell , to not look for the specific version at run time ?
I know for compile time you can avoid this by setting "Specific Version" to false. But how about run time?
Related
I had two applications that was able to run on my local machine in asp.net through visual studio. A webservice and a web forms app. I decided to try and deploy the webservice to my web host online, but it didnt work, so i tried to remove the reference i had to the MySql data connector and then move it to the "bin" folder and re-reference it. This resulted in that my local application broke, and when i tried to undo what i had done, it just remained with the same error. I have tried to uninstall and install various versions of the MySql connector, but without luck. The reference to the MySql connector also got broken in the web forms app, which i didnt delete the reference in, so now neither of them runs.
"Adgang nægtet" means "Access denied".
Here is the error for the webservice
http://pastebin.com/81wuP68j
And here is the error for the web forms app
http://pastebin.com/LVuUy9Yg
Is there any way to start from fresh? I read on a related question, that a guy suggested to reinstall windows, but that isn't a viable option at all.
EDIT: Apparently when i was re-referencing to a new MySql dll file, it was a wrong version of it, so after installing a new one (a second time), and moving it into the bin, and referencing to it, it worked.
Does the shortcut in the Start Menu set the working directory
correctly? (I suspect that this is the most likely answer)
Is there a different/incorrect version of MySql.Data.dll installed
in the GAC (Global Assembly Cache)? I've seen this give similar
error messages before.
Set 'Copy To Local' the Mysql.Data.dll reference from properties.
If MySql.Data is a mixed mode (native and managed code) 32 bit DLL.
And you executable specifies "Any CPU". On a 64 bit machine with 64
bit .NET this will fail with error message you got. A solution is to
specify "x86" as target for the executable.
I am writing an application in C# with Visual Studio 2010 and am close to the end with engineering of my application. For testing i use 3 different machines:
Machine A: Workstation-PC (Intel CPU, Win 7 64Bit, .NET 4.0)
Machine B: Private PC (Intel CPU, Win7 64Bit, .NET 4.0)
Machine C: Labor-PC (AMD64, Win7 64Bit, .NET 4.0)
I want a standalone .exe file for the final version. The application works like a charm on Machines A and B no matter if i run the application in the solution folder or copy it to any directory and run it there. It works always (as it should). But Machine C throws an error, directly on application startup and outputs a "...WERInternalMetadata.xml"-file which says "System.IO.FileNotFoundException":
CLR20r3
myapp.exe
1.0.0.0
53318d78
Testreporter
1.0.0.0
53318d78
5d
f
System.IO.FileNotFoundException
But when I start the application in the solution folder(e.g. ...myapp\bin\x64\Debug), where the *.dll files are contained, the application works perfectly without any problems.
Does this mean, that the program searches for its dependecies in the root directory?
I've already checked the references in code. Furthermore if there were any problems with references, the app would not run on Machine B...
I find it curious that Machines A and B run the program without issues no matter where i place the .exe but Machine C only runs my app properly when placed in specific path....
Maybe the processor plays a role there? Any ideas on how to solve this?
BTW:
How can i build a .exe-file that already contains all dependencies and libraries my application needs. A standalone-exe so to say...
Thank you very much
It looks like the EXE is able to find the necessary DLLs in GAC on machines A and B, but is failing to do so in Machine C. Hence, only the particular path is working.
Please check the GAC.
Also, to embed DLLs into EXEs, refer to this SO thread: Embedding DLLs in a compiled executable
I've found a thread with similar topic, leading me to the solution:
System.IO.FileNotFoundException. Where do I find what path is wrong?
I am using Power Packs, too. When i removed the "Microsoft.VisualBasic.PowerPacks.Vs.dll" from the solution directory and started the application, my program failed with the descripted error. Copying back, then starting the application again was successful. So I guess my the target machine (machine C) needs a Power Pack Installation.
So I guess I can solve this problem in 4 ways?:
1.) Leaving the "Microsoft.VisualBasic.PowerPacks.Vs.dll" with the .exe in same folder and then start my application.
2.) Installing the PowerPack http://go.microsoft.com/fwlink/?LinkID=145727&clcid=0x804
3.) Installing the PowerPack.dll manually to the GAC. Or getting them to the GAC with the corresponding tools as described here http://msdn.microsoft.com/en-us/library/yf1d93sz%28v=vs.110%29.aspx
4.) Embed the .dll right into the .exe
Am I right?
Thank you very much for your help!
I had this problem also, with similar entries in Windows->Application logs, including FileNotFoundException. Very disappointed that every app log clue was just a rabbit hole (lack of specific info on WHAT file).
I eventually discovered the error of my wicked ways via Procmon.exe, and scanning through every line marked "NOT FOUND" in the Result column. There was a companion DLL generated as part of the project that I'd forgotten to copy over to the target machine.
If Procmon.exe ever disappears I'll be dead. It has helped to resolve probably 90% of subtle issues encountered since I began using VisualStudio in 1998.
Gave myself a "BoneHead of The Day" award...
We have a c# executable that loads a 32bit dll written in C++ which dynamically loads another 32bit dll (the first dll is a wrapper).
When this is built on a 32bit machine (with VS toolset v100) it all works correctly.
When it is built on a 64bit machine (with VS toolset v110) it runs on some machines, but on others it gets a FileNotFoundException on the wrapper dll. It works on some 64bit machines, fails on some and fails on at least one 32bit machine.
The failure happens in Assembly.LoadFrom, where the location comes from Assembly.GetExecutingAssembly().Location. The dll is in the same dir as the exe, which was build as x86.
If build on a 64bit machine to get a failing version, then I drop in a version of the wrapper dll built on a 32bit machine, it works properly (so it's not really a file not found problem, but rather a 'correct' file not found one).
Any ideas why this is failing? Is it the build machine, or the toolset? Or something else? Is there something I can set in the build to get it working properly (I'd like to continue building on a 64bit box)?
Do you have all dependency dlls installed on the client machines? Like VC Runtime, other libraries you depend on?
I have created a simple inventory application in WPF. How should I give it to client now ?
One way what I did: I have set my AppPresentation solution as start up project and I can see all the DLLs from other solutions are added in the Debug and Release directory of this solution.
When I copy the Release folder to other drive (from D: to C:) and run the AppPresentation.exe some Error occurs about some DLL missing but I can still see those DLLs in this folder.
However when I copy the debug folder to the other drive and run the application i.e. AppPresentation.exe now I can run the application successfully with complete working.
Can I give this entire Debug folder to the client and expect that it runs perfectly on his machine ? I will ensure .NET 4.0 Framework is installed on that machine (but not Visual Studio ofcourse). Will this work ?
It will work as long as you have the required version of the .NET Framework installed on the client and all the necessary dll's have been included,
Ideally you should look at creating a Visual Studio setup project:
Using a setup project has the following advantages:
All your dll's and other files required for the application to run will be consolidated in one setup file
You can specify prerequsites such as .NET Framework which will prevent installation until all the required components have been installed first.
Users can specify exactly where on disk the application should be installed without manually copying the dlls (as would be the case in your scenario).
This is but a few advantages of using a setup project but hopefully you'll be convinced to give it a try as it is the preferred way of installing Windows applications
P.S If your setup project gets more complex consider looking at Wix
I am developing a 32bit WinForm app (target: .NET 3.5). My client insists the app be installed into "Windows\System32\clientname" folder and autostarts on startup. Also, the app must be 32bit, so I can't use "Any CPU".
I am developing under Win7 x64 with VS2010 and all versions of .NET are installed. When I start the app I get the message "Unable to find a version of runtime to run this application".
On Win7 x86 it works without problem. It's not the app itself and I am 100% sure all the required frameworks are installed.
I know that on a x64 system this folder is not to be used for 32bit apps but as I said: client insists and won't budge.
Before I tell client definitively that it can't be done I want to explore all options. I googled of course and also searched this fine site but nothing helpful for my particular situation came up.
My app spawns another 32bit process located in the same folder. On x64 that didn't work either, of course, but I solved that by using "Wow64DisableWow64FsRedirection" and then copying it to another location to start it from there (which works fine).
I have done my homework but I just can't find a solution for starting the main app under x64 and in that particular folder.
Is there one?
In an attempt to solve this problem I created two folders on my Win7 x64 machine:
C:\Windows\System32\ClientName; and
C:\Windows\SysWOW64\ClientName
Next I created a simple x86 WinForms application targeting .NET 3.5. I found that if I copied the executable to C:\Windows\System32\ClientName I got exactly the same error message as you reported.
However, if I copied the executable to both directories, then I could start it from C:\Windows\System32\ClientName, and it worked just fine.
I did not try this, but I suspect that if you have a multi-assembly application, you only need to copy the *.exe file to C:\Windows\System32\ClientName. All of the other files (and the EXE) would then reside in the C:\Windows\SysWOW64\ClientName directory.
This is a bit of an untidy solution, I know, but then again your client's requirement is a bit unusual to start with.