Если у вас при импорте модуля (iml-файл) идея тупит (не подцепляются исходники, зависимости), не спешите нажимать Synchronize. Откройте iml-файл в текстовом редакторе и внимательно пройдитесь по его содержимому. Возможно, IDEA просто не нашла один из путей. В моем случае это был путь к части исходников, которые генерировались из WSDL в директорию build/src. На момент импорта модуля этих директорий не было (поскольку они создаются при билде модуля), и IDEA некорректно обработала эту ситуацию, проигнорировав прописанные в iml зависимости. После создания директорий build и build/src повторный импорт сработал на ура.
В такой ситуации нажатие Synchronize приведет к тому, что IDEA перезапишет iml-файл, по сути, с нуля. Соответственно, потом файл будет закоммичен вами в VCS. В результате это может обернуться головной болью для всех других разработчиков, имеющих дело с модулем.
Как известно, CLR при запуске .NET-приложения пытается прочитать config-файл с именем запускаемой сборки + расширение “.config”. Но ведь если запускаемый exe-файл переименовать, то config-файл не подгрузится – и приложение, возможно, перестанет работать. С этим частенько сталкиваются разработчики при работе над деплоингом приложения. И, к сожалению, .NET не содержит способов, позволяющих самому приложению задать имя config-файла во время некой процедуры “прединициализации”. Это возможно лишь для опций, которые читаются классом Settings путем написания собственного SettingsProvider’a, реализующего интерфейс IApplicationSettingsProvider (см Application Settings Architecture для более подробной информации).
Но мы можем сделать самостоятельно из нашего приложения некий “микрозагрузчик”, который создает AppDomain, конфигурирует его и запускает сам себя, используя сконфигурированный AppDomain. Это действительно работает, причем в самом примитивном случае код очень компактен :
AppDomainSetup setupInfo = new AppDomainSetup(); string entryAssemblyPath = Assembly.GetEntryAssembly().Location; string entryAssemblyDir = Path.GetDirectoryName(entryAssemblyPath); setupInfo.ApplicationBase = Path.GetDirectoryName(entryAssemblyPath); setupInfo.ConfigurationFile = Path.Combine(entryAssemblyDir, "MyApp.exe.config"); AppDomain forkedDomain = AppDomain.CreateDomain(Guid.NewGuid().ToString(), null, setupInfo); forkedDomain.ExecuteAssembly(Assembly.GetEntryAssembly().Location); AppDomain.Unload(forkedDomain); |
Однако, необходимо следить за тем, чтобы такие ухищрения не приводили к сильной деградации производительности на этапе загрузки. Возможно, стоит написать отдельную сборку, которая будет загружать уже то, что нужно нам. Эта сборка будет очень малого размера, и работать будет практически без потери производительности.
А теперь подумаем, что произойдет, если у приложения, обработанного с помощью NBox (а это, как правило, один-единственный исполняемый файл), изменить имя файла. Если приложение не использовало config-файлы, то все будет ок. Но в противном случае – при запуске – CLR просто не подцепит старый конфиг, и приложение, скорее всего, работать не будет. Но, используя вышеприведенные приемы, мы можем заставить NBox распознать config-файл, и перезапустить самого себя, предварительно сконфигурировав AppDomain нужным config-файлом. А чтобы работа по разворачиванию файлов и сборок не производилась дважды, NBox может извлечь файлы во время начального запуска, и, перезапустившись, уже не извлекать файлы, работая со сборками. Таким образом можно минимизировать потери производительности, одновременно получая еще одну степень свободы в том, как сконфигурировать запускаемое приложение.
В принципе, теперь даже не обязательно извлекать config-файл рядом с exe-файлом упакованного приложения. NBox может закешировать извлекаемые config-файлы во временной директории, извлекая их заново в случае необходимости. Для пользователя это означает минус один файл, создаваемый в каталоге приложения, а для разработчика – уверенность в том, что его конфигурация будет применена независимо от названия exe-файла.
PS. Интересно, что метод AppDomainSetup.SetConfigurationBytes, который бы мог избавить нас от использования файлов в таких случаях, похоже, просто не работает 🙂 Здесь тред об этом : AppDomainSetup.SetConfigurationBytes has no visible effect on configuration…
Как известно, за последние несколько лет в интернетах появилось и разрослось движение Интернет бомжей. Основная идея сферического бомжа в вакууме заключается в том, чтобы заработать побольше денег “в интернете”, не работая “на дядю” в реале. Заработок, к которому стремится среднестатистический бомж – так называемый “пассивный”, т.е. один раз сделал какую-то сеть сайтов, продал ссылки, разместил рекламку – и сиди, кури сигару, в раздумьях, как бы еще срубить бабла, ну или делай следующую партию сайтов в то время как денежки капают. У каждого не обремененного огромными доходами человека, который заходит почитать бомжеблоги успешных бомжей, возникает естественная мысль – почему бы тоже не попробовать ?
У меня двойственное отношение к этим бомжам. С одной стороны, это конечно круто – иметь собственный доход, не зависеть от начальства в реале, не платить налоги, постоянно развиваться итд итп. Но с другой стороны – какова цель всего этого ? Деньги. И люди тратят годы на то, чтобы сделать (уточню – не заработать, а сделать) деньги с помощью сомнительных средств (как то – наебалово доверчивых пользователей (к примеру, через смс), наебалово поисковых машин). Ну добыл денег – что дальше ? Прожигать жизнь или детям рассказывать, как юзеров-лохов на смсках разводил ? Ладно, опустим моральный аспект. Допустим, бомж работал несколько лет таким способом, и опыт у него – исключительно в поднятии денежных средств. А если этим заниматься не интересно ? Ну вот нравится если рыбу ловить – что, всю жизнь тратить на SEO ? Или мне, например, нравится программирование, музыка, и все, что с этим связано – мне совершенно неинтересно клепать сайты и искать способы подороже их втулить. Вопрос – как найти интересующую область деятельности, не “работая на дядю” и с приличным доходом ? Недавно видел на хабре пару постов от так называемых независимых разработчиков. Но – так ли они независимы на самом деле ? У обоих весь доход – от флеш игрушек. Интересно, им не надоело еще эти игрушки клепать ?
То же самое относится и к фрилансу – фрилансер волен лишь выбирать заказчика, но продукт и то, каким он будет – не в его власти.
В общем, крутость бомжевания, фрилансирования и независиморазрабатывания лишь поверхностна. А то, кем быть и как трудиться – дело выбора каждого, в зависимости от личных предпочтений и поставленных целей. И вопрос – как заработать приличные деньги, приобрести ценный опыт и пассивный доход, работая в интересующей области – по-прежнему остается открытым.
0