Добрый день.
Допустим есть у меня .Net exe-шник. Пропускаю я его через ngen на машине сходной с машиной пользователя и отправляю пользователю, у которого Framework не установлен. 
Пользователь счастлив? Или ему еще какие-то dll нужны? Или он все равно без Framework'а не обойдется?

без Framework не обойтись.   

NGen немного не для того предназначен. с помощью него можно избежать стадии JIT-компиляции. Как известно компиляция сборки на платформе .NET осуществляется в два шага: 
1) компиляция в IL-код (получение ассемблирного кода для платформы .NET (IL или как его еще называют MS IL) из языка, на котором программируйте: C#, VB.NET или пр.)
2) JIT-компиляция, при которой происходит компилирование IL-кода в машинный код, при этом для разных машин, этот машинный код будет разным. После JIT-компиляции создается файл, который содержит тот самый машинный код, и при повторном запуске приложения, JIT-компиляция уже не происходит, так как CLR перед тем как запустить сборку (*.exe или *.dll), проверяет есть ли файл с машинным кодом для данной запускаемой сборки, а он есть. А так как CLR - чать .NET, то отсюда вывод: без .NET Framework не обойтись.



Это сообщение отредактировал(а) RWander - 3.12.2009, 18:07

RWander, что-то сумбур какой-то. Если NGen не юзать JIT каждый раз будет, так как JIT компиляция в памяти происходит и только тех функций, которые реально вызываются.
CLR проверяет, есть ли прогнанный через NGen exe для exe c IL кодом, если я пользователю посылаю exe полученный через NGen там IL кода уже нет. собственно не понимаю, с чего бы такой exe с машинным кодом запускался через CLR, 
единственная засада, если вызовы Framework функций остаются внешними, тогда exe с машинным кодом получается зависим от Framework dll, а при их подгрузке уже может и CLR потребоваться. Но честно говоря не вижу особых трудностей NGen'у скомпилить в машинный код и все вызовы Framework функций, в таком случае exe с машинным кодом вообще получается ни от кого не зависим, использует тока собственный код. Но вот информацию о том, производит ли NGen такое встраивание, или ссылки остаются внешними, я не нашел.

нужно добавить:
при использовании NGen, на выходе получаем файл с машинными инструкциями на "средней машины", а не для конкретной, на которой запускаешь сборку, который будет постоянно считываться CLR при последующих запусках сборки. При этом скорость первого запуска сборки значительно уменьшается, так как не будет происходить JIT-компиляция, но так как код при использовании NGen получается усредненным под большинство машин, то преимущество JIT-компиляции, которая происходит без участия NGen, иногда пропадает

Добавлено через 7 минут и 13 секунд


это так.





сборка всегда содержит IL-код. На выходе NGen мы получаем не новую сборку, а файл, в котором будут записаны машинные инструкции, который уже сохраняется на диске, а не в оперативной памяти. И при следующей загрузки сборки CLR, будет его считывать и следовательно JIT-компиляция уже не будет происходить. 


Это сообщение отредактировал(а) RWander - 3.12.2009, 18:25

RWander, ты вообще читал, что я написал? пользователю посылается не сборка, прошедшая через NGen, а тот дополнительный exe файл, который получается на выходе из NGen.
цитата с msdn:
"The Native Image Generator creates a native image from a managed assembly and installs it into the native image cache on the local computer."
Вот я NGen запустил, потом грязными ручками в "native image cache on the local computer" залез, нашел там "native image" и его-то и отправил пользователю.


*производительность меня не волнует. я хочу отвязаться от Framework. чтоб написанный на C# exe запускался на машине пользователя, у которого Framework не установлен.

Это сообщение отредактировал(а) 17dufa - 4.12.2009, 11:48

17dufa, думается, что использование ngen-generated файлов без .Net невозможно. Да, мы получаем конечно-откомпилированный код, но ведь ядро CLR все равно должно на клиенте существовать? Я имею в виду домены приложения, сборщик мусора и т.п.
цитата отсюда
From Richter with love )

tol05, ну в принципе никто не мешает NGen'у добраться до кода IL самой CLR и встроить его в сборку перед ее компиляцией в "native image".
Если полученному "native image" надо просто еще пару "native" dll из комплекта CLR, я в принципе не против, пошлю их вместе с этим "native image", только скажите какие именно. Главное, чтоб пользователю не надо было Framework устанавливать.

Но вообще все это похоже на гадание на кофейной гуще. Кто-нить точно знает? Или как всегда единственный критерий истинности - практика?

Это сообщение отредактировал(а) 17dufa - 4.12.2009, 12:37

А что собственно плохого в том, что будет установлен Framework? Современное программирование под Windows и платформа .NET понятия уже можно сказать неразделимые. Если проблема в том, чтобы таскать с собой Framework, то его можно запихнуть в инсталятор твоей программы.

RWander, надо. не обсуждается.

17dufa, 

хых, если не осуждается, зачем тему начинал вообще, еще и хамишь. 


All,

извиняюсь за оффтоп

RWander, тему начал, чтобы узнать, можно ли при помощи NGen избавить пользователя от Framework. Вариант установки пользователю Framework не обсуждается. Не вижу как последнее условие противоречит созданию темы.

17dufa, ок, принимаю   

но не нужно игнорировать хорошие советы

RWander, думаешь я от хорошей жизни вспомнил про NGen и пытаюсь его заюзать?  

разные ситуации бывают, согласен.

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

Нет, нельзя. Для этого есть другие утилиты, например Postbuild for .NET за 1599$. 
Спроси у заказчика, какой вариант ему больше нравится: установить фреймворк или раскошелиться на энную сумму. Третьего варианта нет, разве что переписать программу с нуля на каком-нибудь нативном языке программирования.

source777, ну переписывать не придется, прога тока начнет писаться в ближайшее время.
А куда NGen кладет обработанный файл? никак не могу найти местоположение на моей машине "native image cache"?

Из книги Рихтера:





Это сообщение отредактировал(а) RWander - 4.12.2009, 14:34

нашел. виндовый проводник как последняя сволочь не показывает подпапок, но я его обманул FreeCommander'ом. На машине без CLR exe-шник выдал - что-то в духе "файл не является win32 приложением". так что NGen в этом деле нам не друг, как и писал source777

дык тот же самый Рихтер писал, что заголовок .Net exe файла отличается от заголовка обычного exe файла Windows  )

что я и пытался видимо сказать, когда упоминал ядро CLR

Ну тогда самое время ТЗ составлять и вписать туда в "Системные требования" наличие установленного .NET Framework нужной версии. Ну право слово, очень странное требование заказчика: писать на .NET, а запускать без него. Ты хоть ОС заказчика узнай, а то как попадётся Win98... 



Ага, там это в PE-заголовке написано...  

Добавлено через 3 минуты

Не совсем, у .NET-сборки как бы 2 заголовка... первый - как раз стандартный PE, как у обычного exe файла Windows, чтобы при запуске без установленного .NET Framework пользователь смог увидеть сообщение об ошибке, про которое уже упомянул 17dufa.

source777, да нету у заказчика требования писать на шарпе. язык для заказчика вторичен. а вот Framework устанавливать не будет. просто мне хотелось на шарпе реализовать. ну значит не судьба, MFC наше фсё  

Совершенно верно. И один из заголовков - просто заглушка для псевдо-совместимости с Windows. А с помощью другого заголовка поднимается run-time машина CLR

Зачем же сразу про такие гадости... Есть же wxWidgets, Qt, GTK+ и много других хороших GUI-тулкитов...