I have a simple c# library (myLib.dll) that can be registered to applications. It can be used as a plug-in. Now i would like to use the json.net library from Newton King, but i do not want to have 2 .dll that i have to send around.
Is there a way to use json.net and somehow embed the .dll into myLib.dll that in the end i have only my .dll?
Edit: to clerify: Is it allowed to merge the jsonNET.dll with my own myLib.dll so that only myLib.dll will be visible as a file?
ok it has the MIT License: http://json.codeplex.com/license
You can merge the libraries together using ilmerge.
http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
Make sure to carefully read the licence of any libraries you are merging in, as it may affect the distribution rules for your library. Also any application that uses your library will also have access to any merged libraries.
You can achieve this remarkably easily using Netz, a .net NET Executables Compressor & Packer.
Finally, as a few have already mentioned, ILMerge may be another option to consider, albeit somewhat more involved.
Related
I have an Obj-C native library libCMX.a that I wish to create C# bindings for, but the library has multiple dependencies, e.g. JASidePanels with a couple of .m and .h files.
How can I include these in the Xamarin binding project so they are linked correctly into the resulting DLL?
I know I can specify Frameworks in the LinkWith attribute, but how do I include pure code dependencies in form of main and header files?
EDIT: The library is proprietary (Cisco CMX SDK), I do not have access to the source code.
EDIT 2: The library is part of a framework (CMX.framework), from which I have extracted the extensionless archive and renamed it to libCMX.a to match default library naming for Xamarin.
You can reference multiple native libraries in your binding project, the combined set of libraries will be linked into your application.
You only need to surface the APIs for libraries that you want to invoke/call. For the rest, just include the binary dependencies.
You will need to compile those into the static library (libMyLibrary.a) you are binding to C#.
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.
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.
There is a similar question for 3.5 here:
Is there a built-in zip library in .NET 3.5?
that speculated that 4.0 would have it, but I can't find any info about it. If not, does anyone know why not? Seems like it would be fairly high on the list of things to include support for.
Take a look at the System.IO.Packaging namespace, which contains support for ZIP files, but not all of the features of ZIP files.
Still, it might be enough for your needs.
You may have already moved along, but ZiP API is added in .NET 4.5
http://msdn.microsoft.com/en-us/library/system.io.compression.ziparchive.aspx
go nuts.
Not for 4.0, but a ZipArchive class is being considered for the next version. You can find details about this on the BCL Team blog.
Edit: Otherwise, assuming that it's still available, and depending on your definition of built in (at least it comes/came with Visual Studio), you might be able to use the J# classes to zip files as described in this article: Using the Zip Classes in the J# Class Libraries to Compress Files and Data with C#
Edit2: Though note the comments below, that the J# option is probably not the right option except in certain unusual circumstances.
Most easiest to deal with, is with sample code here.
You need to add a new assembly just to find he Zip archive.
Working with Zip files in .NET 4.5
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.