Компилировать в автономный исполняемый файл (.exe) в Visual Studio - PullRequest
37 голосов
/ 10 января 2010

как мне сделать отдельный exe-файл в Visual Studio. Это просто простое консольное приложение, которое, я думаю, пользователи не хотели бы устанавливать крошечное консольное приложение. Я скомпилировал простой файл cpp, используя командную строку visual studio. Будет ли работать exe, даже если .NET Framework не установлен? Я использовал собственный код C ++.

Ответы [ 7 ]

55 голосов
/ 10 января 2010

Внутри вашей папки проекта находится папка bin. Внутри вашей папки bin есть 2 папки, Release и Debug. Для вашего полированного .exe, вы хотите перейти в папку Release.

Я не совсем уверен, если это то, что вы спрашиваете

21 голосов
/ 10 января 2010

Все, что использует управляемую среду (включая все, что написано на C # и VB.NET), требует .NET Framework. Вы можете просто распространить ваш .EXE в этом сценарии, но им нужно будет установить соответствующий фреймворк, если у него его еще нет.

19 голосов
/ 20 марта 2011

Если я вас правильно понимаю, да, вы можете, но не в Visual Studio (из того, что я знаю). Чтобы заставить компилятор генерировать настоящий, автономный исполняемый файл (что означает, что вы используете C #, как и любой другой язык), вы используете программу mkbundle (поставляется с Mono). Это скомпилирует ваше приложение на C # в настоящий исполняемый файл без зависимостей.

Существует множество заблуждений об этом в Интернете. Это не противоречит цели .net Framework, как утверждают некоторые люди, потому что, как вы можете потерять будущие возможности .net Framework, если вы не использовали эти функции с самого начала? И когда вы отправляете обновления для своего приложения, не сложно выполнить его через процессор mkbundle перед сборкой вашего установщика. Есть также преимущество в скорости, которое заставляет ваше приложение работать на собственной скорости (потому что теперь оно является нативным).

В C ++ или Delphi у вас та же система, но без среднего уровня MSIL. Так что, если вы используете пространство имен или исходный файл (называемый модулем в Delphi), то он компилируется и включается в ваш окончательный двоичный файл. Таким образом, ваш конечный двоичный файл будет больше (читай: «нормальный» размер для реального приложения). То же самое относится и к частям фреймворка, который вы используете в .net, они также включены в ваше приложение. Тем не менее, умные ссылки бреют значительную сумму.

Надеюсь, это поможет!

3 голосов
/ 10 января 2010

Я согласен с @Marlon. Когда вы компилируете свой проект C # с конфигурацией Release, вы найдете в папке «bin / Release» вашего проекта исполняемый файл вашего приложения. Это ДОЛЖНО работать для простого приложения.

Но, если ваше приложение имеет какие-либо зависимости от какой-либо внешней библиотеки DLL, я предлагаю вам создать SetupProject с VisualStudio. При этом мастер проекта найдет все зависимости вашего приложения и добавит их (библиотеки) в папку установки. Наконец, все, что вам нужно сделать, это запустить установку на компьютере пользователя и установить программное обеспечение.

1 голос
/ 10 января 2010

У меня никогда не было проблем с развертыванием небольшого консольного приложения, созданного на C # как есть. Единственная проблема, с которой вы можете столкнуться, - это зависимость от платформы .NET, но даже это не должно быть серьезной проблемой. Вы можете попробовать использовать версию 2.0 платформы, которая уже должна быть на большинстве ПК.

Используя нативный, неуправляемый C ++, вы не должны иметь никаких зависимостей от .NET Framework, поэтому вы действительно должны быть в безопасности. Просто возьмите исполняемый файл и любые сопровождающие файлы (если они есть) и разверните их как есть; нет необходимости устанавливать их, если вы не хотите.

0 голосов
/ 19 августа 2016

Вы можете встроить все dll в основную dll. См .: Встраивание DLL в скомпилированный исполняемый файл

0 голосов
/ 07 августа 2012

Я не думаю, что можно сделать то, что спрашивает спрашивающий, чтобы избежать ада DLL, объединяя все файлы проекта в один .exe.

В основе проблемы лежит красная сельдь. Проблема, которая возникает, заключается в том, что когда у вас есть несколько проектов, зависящих от одной библиотеки, это PITA для синхронизации библиотек. Каждый раз, когда библиотека меняется, все .exes, которые зависят от нее и не обновляются, ужасно умирают.

Говорить людям, чтобы они изучали С, как один ответ, высокомерно и невежественно.

...