Using C# .NET with COM interop in VS2012, I'm developing a common library for use in several other programs. To keep the integration simple, I would like to keep the entire library down to one DLL. One of the features of this library is localization. It has string tables with messages in multiple languages, each language having it's own ResX file.
Presently, a MyLibrary.resources.dll is being created for each language and placed in its own subdirectory, like this:
Release\MyLibrary.dll
Release\ja\MyLibrary.resources.dll
Release\fr\MyLibrary.resources.dll
What I want to see is just this:
Release\MyLibrary.dll
Here are my current ResX settings.
I have tried using ResXFileCodeGenerator and GlobalResourceProxyGenerator for the "Custom Tool" generators. I also tried a few options for "Build Action" including Compile, but so far only Embedded Resource works. Other than that I'm not sure what else to try or if I'm on the right track. There aren't really that many settings to work with.
I am aware that there are a variety of tools that may work to do this after building the DLL, but I'm looking for a compile-time solution. Third party tools are challenging from a maintenance standpoint -- I will not be the only one updating this library.
There are two main ways of embedding libraries into a single DLL or executable. The first uses ILMerge, combines all assemblies as if it was a single assembly; the second is dynamically loading dependencies from embedded resource(s) at runtime (offers a bit more flexibility, but has its own set of pros and cons). The sample project is intended to be portable (the only dependency is Powershell -- all required libraries are included in the project).
It's important to know the difference between the two techniques. I've written articles outlining both approaches with a sample project on github for both approaches.
Articles:
Assembly Loading: Combine Assemblies & Executables Using ilMerge
AND
Assembly Loading: Dynamic Assembly Loading & Compression
Sample Project:
Application Demonstrating Both ILMerge and Runtime Loading of Embedded Assemblies
If you have any questions regarding either approach, don't hesitate to get in touch. I'll gladly refine the posts based on your feedback.
Related
I have a c++/CLI library that is in turn calling a c# library. That is fine, it is linking implicitly and all is good with the world. But for various reasons the libraries are not getting quite the prefect treatment by our automated build process, and the libraries are not finding each other unless we move the libraries to locations that we would rather not have them in, and would rather not fold into our build process.
It is suggested to me that we/I could write a post-build event that uses XCOPY. but lets say we don't want to do that.
Another suggestion is to explicitly load the dll. Windows says that to link explicitly "Applications must make a function call to explicitly load the DLL at run time." The problem is that Microsoft's example is not enough for my small mind to understand how to proceed with this idea. Worse, the only example I could find is out of date. Perhaps I am not using the right search terms but I am having difficulty finding more about it with google.
How do we explicitly Link a c++/Cli Library to a C# .dll?
----edit
OK, How do we explicitly Link a C++/CLI code, which exports a library using __declspec(), to a C# .dll.
There is no such thing as a "C++/CLI library", only assemblies are supported. There is no explicit or implicit linking, binding always happens at runtime. Assemblies are found at runtime by the CLR, the rules it uses to locate them are described in detail in the MSDN library.
Copying all dependencies into the same directory as the EXE is the sane way to go about it while you are developing the code. Well supported by build system, the C# and C++ rules are however different. C++ projects build to the solution's Debug directory, C# projects build to the EXE project's bin\Debug directory. So yes, altering a C++ project's Output Directory setting or copying files with a post build event is usually required to get everything together.
Is there a way to keep any DLLs needed for my Visual C# program (such as SQLite) inside the actual EXE so it doesn't require the files to be present?
If not, can anyone show me how to make a wrapper for my program (independent of .NET, so maybe C++?) to copy/load required files to the working directory before starting the program itself.
What I intend to end up with is a single EXE file that can be deployed anywhere and set itself up like a transformer. All it requires is the following criteria:
SQLite is present
OpenHardwareMonitorLib is present
.NET 2.0 is installed (if not, offer install with redistributable package)
Microsoft provide a tool for merging DLLs. It's called ILMerge.
It doesn't always work, I believe certain things can cause problems. But it's definitely the easier option!
If the problem is redistribute only one file, you can create a "installer" exe, that unpack all your dependencies (from executable content).
If you don't want to leave all dlls in your production environment, you can merge all IL code in the main executable. you can use ILMerge (but it's not the only product that can do this)
You can merge the dependencies into the main executable. After your build completes you run an additional tool that combines the IL code into a single assembly.
ILMerge can do this but is a bit cumbersome to use.
Some (proprietary) tools can do this as well. I know of at least one obfuscator (DeepSea) that can do this. DeepSea also allows you to specify what you want to include and what types you want to expose from the resulting assembly.
Full disclosure: I know the guys that build DeepSea Obfuscator.
I guess you could embed the target assemblies as resources and then unpack them in some custom assembly resolution code?
Edit: there's an example of this here: Embedding assemblies inside another assembly
I have an application that makes use of/consumes services from a number of external .net libraries, which in turn calls certain executables. Would it be possible to integrate these into one huge executable and load them from my application to the disk as required? Resources come to mind but not sure how that is done.
Thanks,
You have several options to do that:
use ILMerge (free)
For howto see here and here
OR
use some tool like SmartAssembly (commercial)
it can embed and merge among other things (no need to change your source code)
OR
code that yourself in less than 10 lines (free but minimal source code change)
mark all needed dependencies as "embedded resource" - this way they are included in the EXE file... you need to setup an AssemblyResolve handler which at runtime reads from Resources and returns the needed DLLs to the .NET runtime...
You can use ILMerge to merge all your assemblies into a single executable file.
You can find a complete example at CodeProject.
I've got a bunch of .dll assemblies, such as HtmlAgilityPack and MoreLinq. Where am I supposed to put these files? I usually toss them somewhere in my Projects folder, but then I'm always digging around for them. Is there a standard place to put them?
There's no standard place to put them, but make sure you:
Put them in one place
Include them in source control.
I put all my required dll's in a top level directory in my solution called "Dependencies", parallel to the project folders. I have them in source control such that when new developers check out the solution, it all compiles and works right off. It's the only way to go.
I include only the .dll files absolutely needed. This keeps it light, which is good, but then when I find some other part of MVC Contrib or whatever that I need, I have to go find the unzipped directory, which might not even be on my computer! Others put entire library directories (readme.txt and all) as part of their source control linked to the solution. This ensures you and future developers will have everything they need, but adds a little dead weight. Either is a good strategy.
Having a "Lib" folder at the same level as source projects is a common way.
To be honest, it's not the dependencies my projects have that I find hard to manage, it's the dependencies the dependencies have. I'd just like to mention NHibernate, Castle Windsor and the various Castle Windsor Facilities in particular. Getting all of those to play together on my last project cost me a lot of time.
For open source projects, I also like to have the source code handy because sometimes its useful to debug into the source code. (And sometimes because the documentation is so poor, you have to read the source code to find out how it works). I've seen VS projects arranged so that the project references the DLL yet at the same time, VS knows where to find the source code, as I write I can't quite remember how to do that.
So, a Lib folder for DLLs works for me; I often call it "Shared Dependencies".
As for open-source source code, I don't have a standard way to version that because each project is structured differently and has a different build process. I don't like to tinker with the open-source project structure or build method because then, I take responsibility for it. If for some reason, it won't build, or builds incorrectly, or produces a faulty DLL, the cause would be exceedingly difficult to track down, and I'd have to get deep into troubleshooting all of that which I dont care about at all.
In a folder UNDER your solution directory, e.g. "external" or "library". That way your continuous integration system (or other team members) can do a pull of one root from your source control system and have everything they need.
In SVN, use svn:externals to pull that directory from a different root so you can easily share library DLLS (and library projects) between solutions.
In the office we have a share on the network for referenced asseblies. These could be 3rd party or assemblies of our own that could be shared between projects.
I also, don't like the idea of putting the dll files in source control. If all the developers have access to the share all will work fine.
The visual studio directory in My Documents seems like a logical place to put them. I don't know if it's the best or anything wrong with it but at least all the libraries are found in one place.
%USERPROFILE%\My Documents\Visual Studio XXXX\Libraries
At my company we place all our shared DLL assemblies onto a network drive in a folder called Assemblies. From there, we use SyncToy to mirror changes between that folder and a folder on our local development machines (in my case C:\Assemblies with subfolders for different versions or useful third party assemblies). Using the "Reference Paths" feature of Visual Studio projects makes it very easy to select different assembly versions based only on locations.
For projects at home, I would definitely go with the idea mentioned by Jeff M of placing them in the Visual Studio folder under My Documents.
I don't have a hard and fast rule on the location. However, I would encourage consistency!
For example, I needed to to this for a small tool I'm writing for a client at the moment, so I checked their other code bases in Bitbucket which seemed to use a dependencies folder in the solution folder (alongside the other projects), so I copied that.
I'm working on a module for a CMS. This module is distributed as a class library DLL.
I have several utility libraries I'd like to use in this module. Is there anyway I can link these libraries statically so I won't have to distribute several DLL's (thereby distributing my utility libraries separately)?
I would like to have only one DLL.
You can merge your many DLLs with ILMERGE:
http://research.microsoft.com/~mbarnett/ILMerge.aspx
Haven't tried it myself. Hope it helps.
Download here:
http://www.microsoft.com/downloads/details.aspx?familyid=22914587-B4AD-4EAE-87CF-B14AE6A939B0&displaylang=en
Brief Description (from download-page)
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.
If you don't want to use ILMerge, see this page:
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
editor's note: Jeffrey Richter advices to put your dlls into exe file as resources (For each DLL file you add, display its properties and change its “Build Action” to “Embedded Resource.”). Then a custom class loader is needed to make the executable work (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).
Be sure to change the resourceName string to point to your actual resources. (e.g. change AssemblyLoadingAndReflection to your project name.)
The short answer for this is no!
You can not link in a dll during compilation.
I don't know if there is some subtle way to do this, but you would probably have to distribute the dlls along with your cms.
The best way to do this is to make some kind of re-distributable.