I am using JSON.Net to get my Console application to translate sentences with Google Translate. My code fully works fine with absolutely no errors when I run it in Visual Studio. But when I take the .exe out of the "[project_name]\bin\debug" folder and copy it to the desktop to run it returns the following exeception.
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified....
I noticed that in my "[project_name]\bin\debug" folder there is the .dll file that I am using, but not only this, I am also using a .dll that I referenced somewhere else.
When I drag this .dll file with the exe onto the desktop and run it, it works. How do I make it so that I don't need the .dll with the .exe on the desktop? Or is this something that is necessary? I am sure that I have referenced everything properly.
If your application makes use of a library then that library has to be there to make use of. There are basically two ways to make libraries available to .NET applications. The library needs to either be in the same folder as the application or it needs to be installed in the GAC (Global Assembly Cache). The GAC is a common location for libraries so that multiple applications can access them. Unless you intend to ensure that JSON.NET is installed in the GAC on every machine you plan to run your app on, you need to make sure that the library is deployed along with your app. This is how applications work. There is no magic solution.
Related
I have a program which uses several DLL files. Most are from nuget source. I used to check (within main_Load()), if the dll files are present locally and in case of missing dll files, I download them from an own webserver. This works fine. Now I have added a reference to a custom DLL file (because these functions should be shared among serveral programs from several developers). However, I an not able to check this DLLs presence. Even before Program start I get a .NET Framework error: System.IO.FileNotFoundException
Any suggestions?
I am writing a commercial application in VB.Net using VS2010. My application needs to access a MySQL database. So I have a reference to MySQL.Data.dll in the "References" section of my Project. For licensing reasons, I want to make sure that this dll file is not embedded in my application. From what I read, if I set the "copy local" property to False, then the file is not copied and I need to specifically copy it to my bin directory. So I set it to False and built my project. When I run it, I can still connect to the MySQL database even though the dll is not in the bin directory. To me this indicates that it is being compiled with the build. However, the reference points to a location on my hard drive where the original MySQL.data.dll resides. Could it still find it there when the program is run?
How can I make sure it is not getting compiled? Thanks.
By the way, it is not in the GAC (I checked using gacutil.exe)
If you're referring to having the actual assembly embedded into yours, then no it does not. It can be done, but it does not happen out of the box.
The application looks at many places for your references when it needs to load it.
GAC
Next to the application (maybe also the consuming assembly)
x64 and x86 folders next to the application (maybe also the consuming assembly)
Any paths specified in the app.config/web.config for the referenced assembly.
Keep in mind that just because your application fired up, it doesn't mean it found all of the references. It more than likely hasn't loaded all of them yet as it will only do it once it is needed.
Is there any way in VB.NET to DllImport a dll file from the resources?
I really don't want to add the dll with the executable path.
You can embed a DLL into an executable:
Jeffrey Richter: Excerpt #2 from CLR via C#, Third Edition
Many applications consist of an EXE file that depends on many DLL
files. When deploying this application, all the files must be
deployed. However, there is a technique that you can use to deploy
just a single EXE file. First, identify all the DLL files that your
EXE file depends on that do not ship as part of the Microsoft .NET
Framework itself. Then add these DLLs to your Visual Studio project.
For each DLL file you add, display its properties and change its
“Build Action” to “Embedded Resource.” This causes the C# compiler to
embed the DLL file(s) into your EXE file, and you can deploy this one
EXE file.
At runtime, the CLR won’t be able to find the dependent DLL
assemblies, which is a problem. To fix this, when your application
initializes, register a callback method with the AppDomain’s
ResolveAssembly event.
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
We have a Powerbuilder 10 application that is using .Net COM assemblies. We are trying to embed the manifest in the PB application (to invoke COM assemblies without registration). The merged manifest file has added sections for dependecies on the .Net COM assemblies. We have tries various tools to inject the new manifest with different results
- using GenMan32 to inject truncates the application from 6MB to 45KB.
- using ResourceTuner, the file size looks okay, but trying to launch application gives "Fatal Disk Error".
Any suggestions on invoked .Net ComEnabled assembly from PB without registration?
Have you tried it with an external manifest and ensured that works? If an external manifest doesn't work, then the manifest information isn't correct.
Once you have a valid external manifest, you might try the Manifest Tool (MT.EXE) from the .Net SDK. It works well with true EXE files. As Terry noted though, the PB generated executable contains additional information that tools that manipulate the EXE need to respect or they will break it.
http://blogs.msdn.com/patricka/archive/2009/12/09/answers-to-several-application-manifest-mysteries-and-questions.aspx
This is more a redirection than an answer. One thing you need to be aware of is that PowerBuilder produces executables that do not follow standards for Windows executable files. Essentially they are a bootstrap routine to load the PowerBuilder virtual machine, plus a collection of class definitions (objects). The cases you've brought up are not the first I've heard of where utilities meant to modify executables don't work on PowerBuilder executables.
As for a positive contribution on what other directions to follow, I don't really know enough to give qualified advice. If it were me, I'd try to register the COM object if ConnectToNewObject() fails, but I've got no idea if that possible or if that route is a dead end.
Good luck,
Terry.