Если вы используете Maven, вы можете оценить onejar-maven-plugin . Одно из основных преимуществ заключается в том, что все ваши банки-иждивенцы остаются в баночках, а ваш код находится в собственной банке. Все эти банки помещаются в большую банку, которая становится исполняемой, что позволяет избежать некоторых возможных проблем с классом. Прочтите руководство по использованию и это сообщение в блоге для получения дополнительной информации.
если вы хотите преобразовать файл конфигурации без использования конвейера веб-публикации, вы просто используете задачу TransformXml вручную. Я написал об этом подробный пост в блоге по адресу http://sedodream.com/2010/04/26/ConfigTransformationsOutsideOfWebAppBuilds.aspx, но вот основные моменты:
<Project ToolsVersion="4.0" DefaultTargets="Demo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="TransformXml"
AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>
<Target Name="Demo">
<TransformXml Source="app.config"
Transform="Transform.xml"
Destination="app.prod.config"/>
</Target>
</Project>
Здесь я вручную преобразовываю app.config с помощью файла transform.xml, а конечный файл — app.prod.config.
Одна вещь, о которой вы упомянули, это возможность локального преобразования при запуске приложения. Причина, по которой мы выполняем преобразование только для пакета/публикации, заключается в том, что если мы преобразовали сам web.config, то в следующий раз, когда вы отлаживаете свое приложение, web.config снова преобразуется. Так, например, если в вашем web.debug.config у вас есть преобразование для добавления значения в config, все в порядке при первом добавлении, но затем при следующем запуске/отладке приложения оно будет добавлено снова. Так что лучше этого избегать.