I have a 32 bit application that uses a DLL built by someone else, lets call it xyz.dll. This DLL has dependencies on few other old DLLs. All dlls are saved in the same folder where my app is located. My app compiles fine but in run time, it throws an error "Could not load file or assembly "xyz.dll" or one of its dependencies. is not a valid Win32 application"
I have 2 workarounds that seems to solve this problem. In first one I moved the DLLs to a separated folder and created a batch file to run the app. The batch file first add the dlls' path to the environment, then call the app. Interestingly if I leave the dlls in the same folder with the app and just add this to the path, it wouldn't work.
The second way also moved dlls to a folder and add this path to user environment variable and run the exe directly. Either one of these solutions requires extra steps which is not ideal for app deployment. I am wondering if there is a better way?
When your dll is in the same folder as the application, it is that dll that the application attempts to load, and this fails, as you said.
When you move the dll to another folder and add the pathname of that folder to the PATH environment variable, the application works. In this case, the application is not attempting to load the dll that you have moved to another folder. If this were the case, it would fail. It must be loading another version of the dll that is in one of the folder paths that are in your PATH environment variable.
Simply use Windows search to find all copies of your dll file on your computer. You will be able to determine where that other dll is.
Related
I have created an AutoCAD plugin, but encounter problems when using the plugin on certain machines. It works fine on my machine.
One thing that I have noticed is that if I change the output path of the build to a different directory I get problems stating that certain namespaces cannot be found.
The following shows the build output folder with the dll files in, the build is successful.
http://imgur.com/5va3ePj
However, if i build to an empty folder (even with dll files referenced) i get the following errors and warnings...
http://imgur.com/eM86l0u
This plugin needs to be able to be used by other users, i think im not referencing dll files properly or something as the program only runs successfully on my computer (and all computers that i have opened the solution in visual studio and built to the export folder). Copying all the files shown in the folder above to the same path on another users computer doesn't work, other users get an error stating 'Could not load fil or assembly "c:/info3d/info3dreloaded.dll" or one of its dependencies. Operation not supported. Exception from HRESULT: 0x80131515)'
Thanks in advance for any help!
Chris
For AutoCAD DLLs set the Copy Local to false. AutoCAD provides those via its runtime.
"Once a AutoCAD .NET API DLL is referenced, you must set the Copy Local property of the referenced DLL to False." from http://knowledge.autodesk.com/search-result/caas/CloudHelp/cloudhelp/2015/ENU/AutoCAD-NET/files/GUID-8657D153-0120-4881-A3C8-E00ED139E0D3-htm.html
Right click on the reference and click on properties and set the "copy local" property to true
I have my WCF service that uses a third party DLL. this third party DLL is a com register DLL no problem there. But this DLL used an unmanaged, not registrable DLL that has to be in local execution path of the other DLL. The problem is that when my WCF start on IIS it load the third party DLL assembly but the DLL cannot find his DLL as it's not in my application bin folder. I manually putted the other DLL in the bin folder but the execution path is not there. That third party DLL does have methods to expose files in his directory but it doesn't see the file.
I know the problem is that because if i copy paste the method in a console app it run flawlessly but i HAVE to put the DLL's the third party DLL uses into my BIN folder to make it work. Calling the DLL method to see local file clearly shows that it uses my application execution path. I have no problem with having to do that. If i could force the execution path of my Service to always be the same in a place i could know i would simply shove these extra DLL in their and forget about it.
Anyone have an idea how to achieve that ?
The only solution is to create a console application. Install it on the server anywhere else than the web service. Hard code the console executable path into the web service and make the web service start the console app process passing the parameters to it then wait for process exit. Once the console app close go read the log file that it created and extract the result. Then simply return to the client the result.
I am writing an add-in dll in c#, VS2012, Win 7 x64. Debugging has been fine; VS registers the dll at the end of building and I've also set up a batch files in my project folder to register and unregister the assembly.
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe" /codebase ".\bin\Debug\MyAddin.dll"
This will work every time. FYI my development files are also on a network drive and they will register. Even changing to an absolute file path for the dll works.
Now I am working on deploying the add-in, so I'm starting with WIX to create the installer MSI to put the files in the correct install folder. This is where I start getting the RA0000 "Unable to locate input assembly 'MyAddin.dll' or one of its dependencies." error from regasm.exe when I run from a batch file in in my project folder to register the files once they are installed.
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe" /codebase "C:\Program Files\Suite Folder\Product Folder\MyAddin.dll"
This never works. I could see if regasm never worked, but anywhere outside of the output folder won't. So here is what I've tried so far.
Since my Debug output folder has other files like the .tlb and other stuff I started deleting them one by one all the way down to my add-in and the dependent .dlls. Just to verify what files are really needed to register in the output folder.
I thought maybe WIX was not creating the files correctly so I copied all the files including the .tlb and others from my output folder into the install folder (I know these should not impact anything but just to be thorough)
I've unregistered the dll after VS builds thinking that more than one register was the problem.
Tried running regasm from within the install folder directly so it could find all dependencies there.
Made sure all of my dlls are x64 platform.
Tried all lines from batch files in CMD window (w/ and w/o run as admin).
File attributes from output to install folder are the same.
Any ideas?
I am working with developing Windows Service using C#. I want to load CLIPSLIB.dll with Windows Service. First I tried write service as console app in vs2010 placing CLIPSLIB.dll in the project debug folder. It worked fine.
But when I install it and run as Windows Service it throws this exception.
Could not load file or assembly 'Mommosoft.ExpertSystem, Version=0.3.0.2, Culture=neutral, PublicKeyToken=20382083c6694bdc' or one of its dependencies. The system cannot find the file specified.
As I figured out this is happening because Windows Service is unable to load relevant dlls. So whare should I put external dlls to load with Windows Service?
Scott Hanselman has an article that describes how to debug assembly loading errors. the downside to this method is that it requires a registry key change and a reboot in order to emable the fusion loader logging.
That article can be found here:
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
since you are writing a windows service check that the reference for the assembly refers to the bin directory and not some other path. Otherwise the fusion loader logs will identify where it is trying to load the assembly from.
as to the .dll files add a folder to your project and add the .dll files there, change the build properties from do not copy to copy if newer in order that the .dll files will end up in your build output bin path.
You must rebuild the CLIPSLib solution,
Download all files in this link :
Link: https://svn.code.sf.net/p/clipsnet/code/
2.Open CLIPSLib.sln in CLIPSLib folder
3.Right-click on the solution and select rebuild solution.
4.Go to the CLIPSLib folder your CLIPSLib.dll and CLIPSNet.dll is in ..\ ..\mlplatform\bin floder.
hope this help.
I have a ClickOnce application deployed to a virtual machine, Windows 7 32-bit. This application uses some COM components so to get the application working I have created manifests for both the COM assembly and the the application, i.e.
application1.exe and
application1.exe.manifest
comAssembly1.dll and
comAssembly1.x.manifest
Following information from here.
To ensure the application is working, I have run regsvr32 on the COM assembly and all is OK. I then un-registered the assembly and was hoping that all would continue to work. Sadly, it is not the case.
My first port of call was to check my manifests. These match the article referenced above as well as others I have read. So I wanted to check if the manifest was being loaded. I have Process Monitor running and have put a filter on to show only access of files named "application1.exe.manifest", and I don't see any. Having a bit of a google I don't seem to be able to find anywhere that says when then manifest is loaded or by which process.
Have any of you had this problem before? If so, did you discover the cause?
Or is there some magic switch I need in my ClickOnce manifests to tell it to use a manifest file?
And for my own information, when would you expect to see you applications manifest being accessed?
A separate .manifest file will only be used by Windows if the executable doesn't contain an embedded manifest. Problem is that any C# executable already has one. A simple one that's auto-generated by the compiler, it declares the program compatible with UAC.
Project + Add New Item, pick the Application Manifest File item template. It will open in the editor, showing those UAC entries. Move your reg-free COM manifest entries into this one and deploy your app without the .manifest files.