Develop Reference

How to reduce the size of .exe when publish it to folder as single file

I have a very small project (WinForms, it contains 2 folders and 10 classes, simple windows for input) and I want to publish it to folder as single .exe file.
When it is done the size of the file is 140MB. When I add "Trim unused assemblies" mark - 90 MB.
How can I add reduce the size this .exe file? I faced something like this before, and the size of the file was about 1 MB.
My publish config:
Configuration: Debug | Any CPU
Target framework: net5.0 windows
Deployment mode: self-contained (produce single file)
Target runtime: win x-86

Set the configuration to Release instead of Debug.
That will already add some optimazation.
The self-contained part should be disabled when optimizing for size. Disabling it will leave out the .net runtime, otherwise being embedded partially which saves space, but you must be sure the user has the appropriate .net runtime installed.
If your folders contain big files which are embedded, resources like videos, then there's nothing that can be done.
If it's a small project you can consider "just to compile it". If you're not using any non standard DLLs it result in a single (smaller) exe.
I am actually pretty fond of the self-contained option: it saves me the hassle of making sure the user/system has the correct .net vesion installed.

How to make a c#.net application portable

Im searching for a way to make my c#.net Application portable (or at least no installation needed). Some Background: I'm developing a small File-Manager for our Customers. As not every Employee of our Customer got Admin rights I need to hold it as easy as possible to use it.
My idea was to just deliver an .exe or Zip(containing .exe + dll of .net), that all Employees can use it by double clicking.
Is there any way to "bind" the dll to the exe?

Why not just use ClickOnce deployment?
http://msdn.microsoft.com/en-GB/library/142dbbz4%28v=vs.90%29.aspx
No admin rights required... auto updating... what's not to like?
(Just deploying executables is a great way to eliminate your ability to update your clients... why do that?)

You can combine multiple .NET assemblies together using ILMerge: http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
It's somewhat equivalent in concept to a static linker from C/C++ (except pretend that .lib files are directly executable).

Try ILMerge,
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly
http://www.microsoft.com/en-in/download/details.aspx?id=17630
I also use this command line tool to merge several dlls and exe into single exe, use is very simple:
ilmerge /target:winexe /out:destination.exe source.exe dll_1.dll dll_2.dll dll_3.dll

In basic the program written in .net is 'portable' - you do not need to install it. (but the compatible .NET framework must be installed on client machine)
If you like to provide single assembly, you need to download and install the IlMerge utitlity (see Dai's answer) and then have either post-build command defined or I usually do a bat file with content like this:
"c:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe" /target:winexe /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0" /out:ALLINONE.exe PROGRAM.exe LIBRARY1.dll LIBRARY2.dll
Note, the paths depends on how it is on your system...
Also I recommend to 'obfuscate' your assembly - you can use for example good opensource utility 'ConfuserEx'

Why my WPF program cannot run without Visual Studio?

I made a WPF program which uses SQLite. And by using Visual Studio 2012, it generates both Debug and Release version exe file. When I go to Debug or Release directory and run my exe file, e.g. MultiStart.exe, it can run normally.
But if I copy the MultiStart.exe to my Desktop and try to run it, it failed.
By several tests, I found that I also need to copy files MultiStart.exe.config and System.Data.SQLite.dll to my Desktop. And then it can run now.
But why? Do we have better solution so that I can make it run without addition files?
Thanks!

Why my WPF program cannot run without Visual Studio?
The question title is not really accurate since it's not really related Visual Studio. MultiStart.exe is dependent on configuration (MultiStart.exe.config) as well as other assemblies (System.Data.SQLite.dll). Without these dependencies the application cannot run (because that is how .NET works).
WPF doesn't necessarily need a config file to run so the question is what is in your config file that the application needs. It might be possible to move this configuration information into the code (e.g. connection string) and remove the app.config but then the values will be hard coded in the application.
In terms of dependent assemblies, instead of deploying them it is possible to embed them as resources and then use the AppDomain.AssemblyResolve Event to read the assembly from a resource (see Embedding assemblies inside another assembly for an example).
Another approach instead of embedding assemblies as resources is to merge them into one assembly. ILMerge is a popular choice for merging assemblies but I read that it can have issues with WPF assemblies (not sure if that applies to you). See Merging dlls into a single .exe with wpf for some other ideas for merging assemblies with WPF.
Note that setting PATH variables does not work because .NET does not use the PATH for resolving assemblies -- see How the Runtime Locates Assemblies for the details.
Another, option instead of copying the MultiStart.exe to the desktop is to use a shortcut on the desktop that links to the appropriate directory. Perhaps that is a simpler solution

You can also use ILMerge to merge all dependencies into single .exe file to simplify distributiuon of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
Example of usage: ilmerge /target:winexe /out:YourDestinationApp.exe
YourCurrentProgram.exe System.Data.SQLite.dll

Better solution that i used to do with my windows form apps is, Copy the entire folder, which contains supporting files. place it where you want. then create a shortcut of your .exe on your desktop. That always worked for me.

Because you are missing some dependency. You can open your config file and set the dependency...but I wouldn't recommend you to change config file manually.
You can also copy the dependent dll in system32 folder. ..but its only a trick because exe first search dlls in current folder than system 32 folder.

Because you're missing things from your PATH. Visual Studio is probably set to copy DLLs to the target directory on build.
You're almost certainly pulling in external libraries. Some of these are part of .NET, while others are packaged in libraries in specific folders. When you start your exe, it looks in your PATH and the current folder for everything (which includes all DLLs Visual Studio copied).
When you moved the exe to the desktop, suddenly it had no idea where those DLLs are. You haven't specifically added them to your PATH, and they are no longer in the current folder. This is why copying those DLLs to your desktop magically made them work.
Unless you stop use SQLite, there is not a way for you to not need that DLL (there are lots of ways to package/reference it though).

How can I convince mkbundle to include MonoPosixHelper?

I'm using mkbundle and trying to create an embedded version of a little program IdaTester that uses Isis2. That system in turn uses features from Mono that depend on MonoPosixHelper
My problem is that mkbundle doesn't recognize the dependency and I end up with an executable that still needs to dynamically link against ~/bin/lib/libMonoPosixHelper.so, causing problems when I move this executable to a system where I don't have Mono installed. In effect, the bundle is missing one of the things it should be statically linked against.
My executable does work, but only if I make sure to run it only on machines that have the dynamic library in the "right place". This defeats the purpose of an embedded executable... I was hoping to be able to hand people this program as a kind of server they could put anywhere and launch as a binary, and obviously if they need to install the library for this to work, the server isn't exactly standalone!
I see how to force mkbundle to include any dll files the program depends upon, but MonoPosixHelper doesn't exist as a dll; this is a Linux-only library and exists only as a shared library. Does anyone know of a way to "force" the bundle to embed it statically?
In case this helps, my little compile script is as follows:
mcs -debug+ IdaTester.cs Isis.cs -r:System.dll -r:Microsoft.CSharp.dll -r:Mono.Posix.dll
mkbundle --static -o IdaTester IdaTester.exe --deps
I then run IdaTester; this works on platforms where the libMonoPosixHelper library can be found, but will fail at runtime when trying to dynamically load that library if running on a platform where libMonoPosixHelper hasn't been installed...

One needs to distribute libMonoPosixHelper.so with the application and change the dll map to make this work.
Background on the problem - Library is Loaded at Runtime
libMonoPosixHelper is not statically linked but searched for and loaded as a P/Invoke call, such as the example below:
[DllImport ("MonoPosixHelper")]
static extern int zipClose (ZipHandle handle, string globalComment);
That is, it is only requested at runtime, not compile time, and so cannot be linked in ahead of time.
Fixing it - Distributing libMonoPosixHelper.so
Four steps are required.
Copy libMonoPosixHelper to the directory you will be distributing the program with.
Update the DllMap config file to avoid a hard coded location.
Embed the config file with mkbundle
Add the path with libMonoPosixHelper.so to the LD_LIBRARY_PATH on the install machine.
To perform each:
1. Copy libMonoPosixHelper to the directory you will be distributing the program with.
libMonoPosixHelper is usually located in the lib folder, simply copy it to the folder you will be making a tarball out of.
cp $MONO_ROOT/lib/libMonoPosixHelper.so ~/MY_PROGRAM/
2. Update the DllMap config file to avoid a hard coded location.
This is the critical bit to avoid the hard coded paths issue. We need to embed a config file with mkbundle that does not specify the path. To do this, first find the mono config file, and also copy that to the local directory
cp $MONO_ROOT/etc/mono/config ~/MY_PROGRAM/config
Now we need to alter this file to remove the specific path for the dll, open it with your favorite editor and change the paths to avoid the specific prefix:
<dllmap dll="MonoPosixHelper" target="MACHINE_SPECIFIC/lib/libMonoPosixHelper.dylib" os="!windows" />
to
<dllmap dll="MonoPosixHelper" target="libMonoPosixHelper.dylib" os="!windows" />
3. Embed the config file with mkbundle
Add the following option to your mkbundle command to embed the newly edited config file:
--config MY_PROGRAM/config
4. Add the path with libMonoPosixHelper.so to the LD_LIBRARY_PATH on the install machine.
Now you can zip up your mkbundled executable, libMonoPosixHelper.so and any other files for distribution. When unzipped and run on a machine, dlopen will now look for libMonoPosixHelper.so just like any other dll. So simply add whatever directory contains your distributed version of libMonoPosixHelper to their LD_LIBRARY_PATH environmental variable

As far as I can tell, the best option available to me is either to build a non-shared Mono library containing the same methods as are currently found in MonoPosixHelper.so, or to provide a copy of MonoPosixHelper.so as a component to be installed in the same folder as my server. Neither seems ideal: the former forces me to "reach into" the Mono distribution, which creates a longer term maintenance issue, while the latter forces me into a more complex distribution and installation mode. But it seems that once one generates a shared library, you simply can't statically link against that version of the library; the Linux loader just doesn't treat such a thing as a library in the way it handles more standard libraries.
In contrast, if I do generate a standard library from the same .o files, the loader will be happy to statically link against it, and because mxbundle ultimately runs cc and hence uses the standard ld, that option would work for me. So I guess that's the answer to my question.

How is it that I could compile an exe in C# with no error but execution fails with dll not found?

I have created a console app referencing http://www.antlr.org/download/CSharp
using System;
using Antlr.StringTemplate;
using Antlr.StringTemplate.Language;
That I want to compile by command line with
csc /r:c\antlr\antlr.runtime.dll;c\antlr\StringTemplate.dll myprog.cs
It created the exe but when executing it says it cannot find StringTemplate or dependencies why ? I have all dll package in same directory.
Update: the same program build under visual studio works but I need to do this by command line.
Update 2: even copied to exe path it still can't find them weird !
Update 3: ok finally works I confused visual studio bin output and my csc output dir.

That's because you are not using the friendly IDE that takes care of these details for you. Since you're doing this by hand, it is up to you to copy the DLLs yourself.
csc /r:c\antlr\antlr.runtime.dll;c\antlr\StringTemplate.dll myprog.cs
copy c:\antlr\antlr.runtime.dll .
copy c:\antlr\stringtemplate.dll .
The DLLs are now in the EXE's 'probing path', it won't have any trouble finding them.

The dlls have to be in the same directory of the exe unless they are in the GAC.

DLLs are search for on the PATH env variable.
Unless you specially put ;.; in your path, CWD is not searched.

Could be a number of things. For me, the most common cause of an error like this -- assuming that all the DLLs are indeed where they should be (next to the running executable) -- is that your application is compiling as Any CPU, but you are running it on a x64 machine (so the CLR loads it as x64) but one of the assemblies you reference has to interop to native code or otherwise makes a reference to a x86 (32-but) unmanaged DLL. Since you can't load a 32-bit DLL into a 64-bit process, the assembly load fails.