i did a build in vb.net and got one exe file
however, when a user runs the file, it says it is missing one of the libraries (itextsharp).
so the question is, if there is actually a build option in vb.net, why does it not include the library in the same exe file?
You can distribute the iTextSharp DLL with your application. The easiest way to do this is to simply include it in the same folder as your EXE. The DLL should be output to your Project's Debug/Release folder each time you build assuming you've added it as a Reference in your project and the Reference's 'Copy Local' property is set to True.
If you want to distribute one EXE and include the iTextSharp in that, you can use the ILMerge tool (or alternately Gilma from SourceForge) after you build your EXE.
in the properties for the reference set the Copy To Output to Always
ITextSharp is not a library linked in your project output; it's an assembly referenced by your project output. And while VB.Net builds one executable from your source code, the CLR still needs all the referenced assemblies in the same folder as your executable.
To make everything work, you can distribute ITextSharp assemblies along with your app. Alternatively, if you indeed need only one file, you can use ILMerge on your project output and the assemblies you want included. However, you might need to determine all the correct assemblies you need merged. I wouldn't revommend using this tool, unless you understand how it works.
Note: If you want to use ILMerge with .Net v4.0, read this page.
Related
Is it possible in MSBuild 4.0 and/or 4.5 to specify additional files to be treated as a manifest output of a project by its dependencies, and copied with the binary project output, whenever that is copied? Ideally, I want to create some files beside a .dll during build, and would like these files to stay in the same folder as the .dll whenever it is copied to a directory of a project depending on it.
If this is not clear, I am thinking of .pdb and documentation .xml files created by the C# compiler. These files treated specially: Whenever another project requests the .dll be copied locally into its binary directory, these files go with the .dll. Can I augment this set with my own special files?
This is not possible, and here is why. Actually, there is no concept of project output accessible externally between MSBuild projects. Rather, when a reference to a project is added, the SDK-provided build framework (based on MSBuild scripts) looks for a few specific files matching the name of the referenced DLL, and copies these files with the DLL itself into the current project output directory (assuming CopyLocal is set, which is probably true for a referenced project).
In framework v4.0, this is done by the task ResolveAssemblyReference which is called from an identically named target from the file %windir%\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets. The task looks for specially named files placed beside the target DLL, including its matchin PDB files and an XML documentation file. Other files are also discovered, as I infer from the decompiled source.
So nothing in a given project specifically marks these files as somehow "exported" from the project. The magic happens on the pulling side.
We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
I have a .dll file which I've decompiled with the software called "Reflector7.4.1" to get the source code. After decompiling, to my surprise, I got a folder instead of a single source code file.The folder contained a bunch of other files and subfolders with files.
I have identified the file in which I have to modify the code.But the problem is,after I have modified the only 1 file, how do I compile the whole bunch of folders and subfolders and many other files that I have not edited-into a single .dll file as they were before?
You should not recompile decompiled code, since the compilation process is not completely reversible, even for .NET binaries. There are many missing libraries you might need, mismatches in libraries, etc. I would suggest decompiling and then patching the DLL using a .NET assembly editor of some sort.
Reflexil is one you should check out.
You should also understand .NET disassembly and understand how to move back and forth from the decompiled source and the binaries, so you'll know exactly what you want to change.
I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!
I have two use cases: 1) loading a temporary DLL during a custom action and 2) executing a temporary EXE from a custom action. The custom action DLL is unmanaged C++. I cannot figure out how to get this working correctly. Including the DLL is easy enough but LoadLibrary is failing as it cannot find the DLL. I also cannot seem to get the physical path of the extracted DLL in order to specify full path in LoadLibrary. Any help is appreciated. I'm using WIX btw for this work.
If you have included the dll and the exe in the Binary Table of the msi, the files will be physically present in the %Temp% folder of the currently logged in user which gets mapped to SUPPORTDIR property of Windows Installer.
You need to use MsiGetProperty to get the SUPPORTDIR and use that in the LoadLibrary.
One thing to remember - Windows Installer usually extracts files from Binary table to %TEMP%, however - the current work directory is often set to c:\windows\installer.
My suggestion - extract the temporary .dll from Binary table yourself when you need it. This gives you the control of when it's saved to. Just remember that you need write permission to the location, so usually some subdir of %temp% is the best choice.