Да, можно использовать инструмент ILMerge.

Сегодня, в 2015 году, вы можете использовать Costura.Fody для этого. Его использование означает добавление пакета NuGet в ваш проект и перекомпиляцию. Я не уверен, работает ли он с Visual & nbsp; Studio & nbsp; 2005, как в вопросе, но тогда это тоже не 2008 год. Я использовал его в нескольких своих проектах, и он отлично работал.

Fody является универсальным Code Weaver , который является бесплатным и открытым исходным кодом. Основная идея заключается в том, что он позволяет пост-обработку скомпилированного кода .NET, чтобы расширить его с помощью функций. Например, регистрация может быть добавлена ​​к каждому вызову метода и т. Д. В нашем случае это упаковка зависимых файлов DLL в ресурсы сборки, чтобы они могли загружаться во время выполнения программы, как если бы они были автономными зависимостями. ]

Существует сторонний инструмент под названием .NET Reactor , который может сделать это за вас. Я не использовал этот инструмент и поэтому не уверен, насколько хорошо он работает.

Да. В .NET вы можете инкапсулировать все ваше приложение в один EXE-файл. Просто убедитесь, что в вашем решении есть только один проект Windows Application (и никаких других проектов, кроме установок).

EXE-файл, созданный вашим проектом .NET, не будет автономным исполняемым файлом, но он будет зависеть только от среды выполнения .NET (если вы не добавите ссылки на другие сборки DLL). ). Если вы используете .NET 2.0 (который я рекомендую), среда выполнения предустанавливается на новых компьютерах и очень легко и быстро устанавливается на старых компьютерах (установщик занимает около 23 МБ).

Если вашему приложению нужно ссылаться на другие сборки (например, DLL доступа к данным или проект DLL библиотеки классов .NET), вы можете использовать один из инструментов, на которые ссылаются другие авторы, чтобы объединить ваш EXE и все библиотеки DLL, на которые есть ссылки, в один EXE-файл. Однако традиционная практика будет предписывать просто развертывать файл EXE вместе с любыми зависимыми DLL-файлами в виде отдельных файлов . В .NET развертывание зависимых DLL довольно просто: просто поместите их в ту же папку, что и файл EXE на клиентском компьютере, и все готово.

Хорошей практикой является развертывание приложения (будь то один файл или несколько) в качестве установщика с одним файлом (либо setup.EXE, либо setup.MSI). .NET поставляется с шаблонами проектов развертывания, которые могут довольно легко создавать инсталляторы для вас.

Немного не по теме: вы можете использовать NGEN для компиляции вашего .NET-приложения как собственного EXE-файла, но это все равно будет зависеть от времени выполнения .NET. Преимущество нативной компиляции состоит в том, что некоторые вещи могут быть предварительно скомпилированы, но я никогда не видел ситуации, когда это незначительное увеличение производительности стоило бы беспокоиться.

Как уже было сказано, вы можете использовать ILMerge .

Однако это может быть проще, если вы используете бесплатный протектор Phoenix , который также защищает ваш код.

Я использовал исполняемый упаковщик с открытым исходным кодом .NETZ .NET для упаковки файлов EXE и DLL в один файл EXE. Вот пример командной строки для упаковки файлов DLL в один файл:

netz -s application.exe foo.dll bar.dll

Вы можете попробовать утилиту NBox .

Джеффри Рихтер писал в своем отрывке из книги , что метод обратного вызова с событием ResolveAssembly в домене приложения может быть зарегистрирован для включения CLR . ] чтобы найти сторонние сборки и DLL-файлы во время инициализации программы:

AppDomain.CurrentDomain.AssemblyResolve += (sender, 
  args) => {
    String resourceName = "AssemblyLoadingAndReflection." +
    new AssemblyName(args.Name).Name + ".dll";
    using (var stream =       
      Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName)){
        Byte[] assemblyData = new Byte[stream.Length];
        stream.Read(assemblyData, 0, assemblyData.Length);
        return Assembly.Load(assemblyData);
      }
   };

Отказ от ответственности : я сам этим не пользовался. Насколько я понял, клиент все еще должен иметь установленную платформу .NET.

Вы не должны разбивать его на несколько сборок (которые обычно являются проектами внутри решения Visual Studio). В любом случае требуется .NET Framework, и нет способа - и это правильный путь - его встраивать.

Да, вы можете создать один EXE-файл. Вот две хорошие статьи:

1. Как включить все связанные библиотеки DLL в один файл EXE
2. .NET runtime - один файл EXE

ILMerge может объединять сборки в одну сборку, если сборка содержит только управляемый код. Вы можете использовать приложение командной строки или добавить ссылку на файл EXE и программно объединить. Для версии с графическим интерфейсом есть Eazfuscator , а также .Netz , оба из которых бесплатны. Платные приложения включают BoxedApp и SmartAssembly .

Если вам нужно объединить сборки с неуправляемым кодом, я бы предложил SmartAssembly . У меня никогда не было икоты с SmartAssembly , но со всеми остальными. Здесь он может встраивать необходимые зависимости как ресурсы в ваш основной EXE-файл.

Вы можете сделать все это вручную, не беспокоясь о том, управляется ли сборка или в смешанном режиме, встраивая файл DLL в свои ресурсы и затем полагаясь на сборку AppDomain ResolveHandler. Это универсальное решение, использующее наихудший вариант, то есть сборки с неуправляемым кодом.

class Program
{
    [STAThread]
    static void Main()
    {
        AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
        {
            string assemblyName = new AssemblyName(args.Name).Name;
            if (assemblyName.EndsWith(".resources"))
                return null;

            string dllName = assemblyName + ".dll";
            string dllFullPath = Path.Combine(GetMyApplicationSpecificPath(), dllName);

            using (Stream s = Assembly.GetEntryAssembly().GetManifestResourceStream(typeof(Program).Namespace + ".Resources." + dllName))
            {
                byte[] data = new byte[stream.Length];
                s.Read(data, 0, data.Length);

                // Or just byte[] data = new BinaryReader(s).ReadBytes((int)s.Length);

                File.WriteAllBytes(dllFullPath, data);
            }

            return Assembly.LoadFrom(dllFullPath);
        };
    }
}

Где Program - имя класса. Ключевым моментом здесь является запись байтов в файл и загрузка из него. Чтобы избежать проблемы "курицы с яйцом", необходимо убедиться, что вы объявили обработчик перед доступом к сборке и не имеете доступа к элементам сборки (или не создаете экземпляры чего-либо, имеющего отношение к сборке) внутри загрузки (разрешение сборки) часть. Также убедитесь, что GetMyApplicationSpecificPath() не является каким-либо временным каталогом, так как временные файлы можно пытаться удалить другими программами или самостоятельно (не то, что он будет удален, когда ваша программа обращается к файлу DLL, но, по крайней мере, это неприятно AppData - это хорошее место). Также обратите внимание, что вы должны записывать байты каждый раз; Вы не можете загрузить из местоположения только потому, что файл DLL уже находится там.

Для управляемых DLL-файлов вам не нужно записывать байты, а непосредственно загружать их из расположения DLL-файла или просто читать байты и загружать сборку из памяти. Примерно так:

using (Stream s = Assembly.GetEntryAssembly().GetManifestResourceStream(typeof(Program).Namespace + ".Resources." + dllName))
{
    byte[] data = new byte[stream.Length];
    s.Read(data, 0, data.Length);
    return Assembly.Load(data);
}

// Or just

return Assembly.LoadFrom(dllFullPath); // If location is known.

Если сборка полностью неуправляемая, вы можете увидеть эту ссылку или эту о том, как загрузить такие DLL-файлы.

Я использую .netshrink сам, и он делает именно то, что вам нужно. Он упаковывает основные и дополнительные сборки (файлы DLL) в один исполняемый образ.

Я использую его уже год, и я не собираюсь возвращаться в ILMerge (он всегда падает в какой-то момент ...).