Visual studio копировать после сборки
Используйте события сборки для указания команд, которые выполняются до начала сборки или после ее завершения.
При сборке проекта события перед сборкой добавляются в файл PreBuildEvent.bat, а события после сборки — в файл PostBuildEvent.bat. Если вы хотите обеспечить проверку ошибок, добавьте собственные команды проверки ошибок в шаги сборки.
Указание события сборки
В обозревателе решений выберите проект, для которого необходимо задать событие сборки.
В меню Проект выберите Свойства.
Откройте вкладку События построения.
В поле Командная строка события перед сборкой укажите синтаксис события сборки.
События перед сборкой не выполняются, если проект актуален и сборка не запускается.
В поле Командная строка события после сборки укажите синтаксис события сборки.
Добавьте оператор call перед всеми командами после сборки, запускающими BAT-файлы. Например, call C:\MyFile.bat или call C:\MyFile.bat call C:\MyFile2.bat .
В поле Выполнить событие после сборки укажите при каких условиях должно выполняться событие после сборки.
Чтобы добавить длинный синтаксис или выбрать макросы сборки из диалогового окна Командная строка события "После построения" или "Командная строка события "До построения"", нажмите кнопку с многоточием (. ) для отображения поля редактирования.
В обозревателе решений выберите проект, для которого необходимо задать событие сборки.
В меню Проект выберите пункт Свойства (или из Обозревателя решений нажмите клавиши ALT+ВВОД).
Выберите элементы Сборка > События.
В разделе Событие перед сборкой укажите синтаксис события сборки.
События перед сборкой не выполняются, если проект актуален и сборка не запускается.
В разделе Событие после сборки укажите синтаксис события сборки.
Добавьте оператор call перед всеми командами после сборки, запускающими BAT-файлы. Например, call C:\MyFile.bat или call C:\MyFile.bat call C:\MyFile2.bat .
В разделе Когда выполнять событие после сборки укажите условия, при которых должно выполняться событие после сборки.
Синтаксис события сборки может включать любую команду, допустимую в командной строке или в BAT-файле. Для имени пакетного файла необходимо указать префикс call , чтобы гарантировать выполнение всех последующих команд.
Если событие перед сборкой или после сборки завершается ошибкой, можно прервать сборку, задав завершение действия события с кодом, отличным от нуля (0), что означает успешное выполнение действия.
Макросы
В скриптах для событий сборки может потребоваться сослаться на значения некоторых переменных уровня проекта, например имя проекта или расположение выходной папки. В предыдущих версиях Visual Studio они назывались макросами. Аналогом макросов в последних версиях Visual Studio являются свойства MSBuild. MSBuild — это механизм сборки, который Visual Studio использует для обработки файла проекта при выполнении сборки. Событие сборки в интегрированной среде разработки приводит к созданию целевого объекта MSBuild в файле проекта. Вы можете использовать любое свойство MSBuild, доступное в целевом объекте в файле проекта (например, $(OutDir) или $(Configuration) ). Свойства MSBuild, доступные в этих событиях, зависят от файлов, которые неявным или явным образом импортированы в файл проекта, такие как файлы .props и .targets , и свойства, заданные в файле проекта, например в элементах PropertyGroup . Будьте внимательны, чтобы использовать точное написание каждого свойства. При неправильном написании свойства ошибка не возникает. Вместо этого неопределенное свойство оценивается как пустая строка.
Например, вы указали событие перед сборкой следующим образом:
Это событие перед сборкой приводит к следующей записи, называемой Target в файле проекта:
Событие сборки отображается как целевой объект, включающий задачу Exec со входными данными, указанными как Command . Символы новой строки кодируются в XML.
Выходные данные событий сборки записываются в выходные данные сборки, которые можно найти в окне выходных данных. В раскрывающемся списке Показать выходные данные из выберите Сборка.
Пример
В следующей процедуре показано, как задать минимальную версию операционной системы в манифесте приложения с помощью команды EXE, вызываемой из события после сборки (файл exe.manifest в каталоге проекта). Минимальная версия операционной системы — число из четырех частей, например 4.10.0.0. Чтобы задать минимальную версию операционной системы, команда изменит раздел манифеста:
Создание команды EXE для изменения манифеста приложения
Создайте проект Консольное приложение для команды. Назовите проект ChangeOSVersionCS.
В Program.cs добавьте следующую строку для других директив using в верхней части файла:
В пространстве имен ChangeOSVersionCS замените реализацию класса Program следующим кодом:
Команда принимает два аргумента: путь к манифесту приложения (то есть папка, в которой в процессе сборки создается манифест, обычно Projectname.publish) и новую версию операционной системы.
Скопируйте файл EXE в каталог, например C:\TEMP\ChangeOSVersionVB.exe.
Затем вызовите эту команду в событии после сборки для изменения манифеста приложения.
Вызов события после сборки для изменения манифеста приложения
Создайте проект Приложение Windows Forms с именем CSWinApp.
Выберите проект в обозревателе решений, а затем в меню Проект выберите пункт Свойства.
В конструкторе проектов найдите страницу Публикация и для параметра Расположение публикации задайте значение C:\TEMP.
Опубликуйте проект, щелкнув Опубликовать сейчас.
Создается файла манифеста, который сохраняется в каталоге C:\TEMP\CSWinApp_1_0_0_0\CSWinApp.exe.manifest. Чтобы просмотреть манифест, щелкните правой кнопкой мыши файл и выберите пункт Открыть с помощью, затем выберите Выбрать программу из списка и щелкните Блокнот.
Найдите в файле элемент . Например, версия может быть следующей:
Вернитесь в конструктор проектов и перейдите на вкладку События сборки.
В разделе Событие после сборки введите следующую команду:
C:\TEMP\ChangeOSVersionCS.exe "$(TargetPath).manifest" 5.1.2600.0
При сборке проекта выполнение этой команды приводит к изменению минимальной версии операционной системы в манифесте приложения на 5.1.2600.0.
Так как макрос $(TargetPath) выражает полный путь к создаваемому исполняемому файлу, файл $(TargetPath).manifest будет указывать манифест приложения, созданный в каталоге bin. При публикации этот манифест копируется в заданное ранее расположение публикаций.
Опубликуйте проект еще раз.
Версия манифеста должна иметь следующий вид:
Для некоторых сценариев могут потребоваться более интеллектуальные действия сборки, отличающиеся большими возможностями, чем события сборки. Например, для большинства распространенных сценариев создания кода необходимо выполнять операции очистки и перестроения. Вам также, возможно, потребуется включить инкрементную сборку для шагов создания кода, чтобы шаг выполнялся только в том случае, если выходные данные устарели по отношению к входным данным. Для таких сценариев рекомендуется создать пользовательский целевой объект, который указывает AfterTargets или BeforeTargets , чтобы выполнение происходило в определенной точке процесса сборки. Для дальнейшего контроля в сложных сценариях рекомендуется создать пользовательскую задачу.
Есть проект с dll, которую после билда постоянно вручную копирую в нужную папку. Для автоматизации попробовал указать Post-build event. Просто dll скопировать легко:
А как за ней утянуть еще и xml описание? Не силен в bat'анике, надо как то отрезать от $(TargetPath) расширение ".dll" или есть другие способы?
2 ответа 2
Таким образом, можно предположить, вы просто неправильно проставили настройки References в вашем проекте, поскольку копирование dll'ок , необходимых для запуска проекта должно происходить автоматически. Файлы с xml документацией по сборкам также копируются автоматически.
Если я где-то ошибся в своих предположениях, то могу предложить вам более общее решение. Вместо того, чтобы как-то отрезать от названий файлов расширения и реализовывать некоторую сложную логику в Post-Build Events , сделайте примерно следующее:
Определите множество файлов, которые всегда необходимо копировать в папку с собранным приложением (в вашем случае здесь будет дополнительная dll'ка и соответствующий ей xml файл).
Отведите для этих файлов специальную папку в вашем проекте. Я в своих проектах использую папки с названиями data и static_data .
Семантика этих названий следующая - в data хранятся файлы, без которых запуск приложения или тестов невозможен. Это могут быть какие-то входные данные, файлы для тест-кейсов, какие-то unmanaged dll'ки и т.п. В static_data находятся вспомогательные данные, которые просто используются в проекте - например, графические assets , скетчи UI , важная информация в pdf'ках .
- Далее в Post-Build Events добавьте следующую команду:
- Этим вы гарантируете, что в случае успешной сборки проекта все файлы из data будут скопированы в Output папку с собранным приложением.
Есть еще один важный момент, на который стоит обратить внимание - если файлы в папке data обновились, то они, естественно, не будут скопированы в Output до пересборки проекта, а значит, в некоторый момент времени, несмотря на то, что вы уже обновили файлы, собранное приложение будет работать со старым комплектом файлов. Это достаточно критично для тестов.
On a successful build, I wish to copy the contents of the output directory to a different location under the same "base" folder. This parent folder is a relative part and can vary based on Source Control settings.
I have listed a few of the Macro values available to me .
$(SolutionDir) = D:\GlobalDir\Version\AppName\Solution1\build
$(ProjectDir) = D:\GlobalDir\Version\AppName\Solution1\Version\ProjectA\
I want to copy the Output Dir contents to the following folder :
D:\GlobalDir\Version\AppName\Solution2\Project\Dependency
The base location "D:\GlobalDir\Version\AppName" needs to be fetched from one of the above macros. However, none of the macro values list only the parent location.
How do I extract only the base location for the post build copy command ?
6 Answers 6
Here is what you want to put in the project's Post-build event command line:
EDIT: Or if your target name is different than the Project Name.
One can use xcopy with wildcards and the appropriate switches to achieve a similar result, whilst maintaining the source folder's (tree) structure, such as: xcopy /i /e /s /y /f "
update to my prev. comment: copy /Y "$(TargetPath)" "$(SolutionDir)somewhere\" , without the extra backslash, since $(SolutionDir) includes a trailing backslash (at least in VS2012)
If none of the TargetDir or other macros point to the right place, use the ".." directory to go backwards up the folder hierarchy.
ie. Use $(SolutionDir)\..\.. to get your base directory.
I think this is related, but I had a problem when building directly using msbuild command line (from a batch file) vs building from within VS.
Using something like the following:
(note: start XCOPY rather than XCOPY used to get around a permissions issue which prevented copying)
The macro $(SolutionDir) evaluated to ..\ when executing msbuild from a batchfile, which resulted in the XCOPY command failing. It otherwise worked fine when built from within Visual Studio. Confirmed using /verbosity:diagnostic to see the evaluated output.
Using the macro $(ProjectDir)..\ instead, which amounts to the same thing, worked fine and retained the full path in both build scenarios.
Would it not make sense to use msbuild directly? If you are doing this with every build, then you can add a msbuild task at the end? If you would just like to see if you can’t find another macro value that is not showed on the Visual Studio IDE, you could switch on the msbuild options to diagnostic and that will show you all of the variables that you could use, as well as their current value.
To switch this on in visual studio, go to Tools/Options then scroll down the tree view to the section called Projects and Solutions, expand that and click on Build and Run, at the right their is a drop down that specify the build output verbosity, setting that to diagnostic, will show you what other macro values you could use.
Because I don’t quite know to what level you would like to go, and how complex you want your build to be, this might give you some idea. I have recently been doing build scripts, that even execute SQL code as part of the build. If you would like some more help or even some sample build scripts, let me know, but if it is just a small process you want to run at the end of the build, the perhaps going the full msbuild script is a bit of over kill.
I have a solution with 3 projects in it. I need to copy a view from one project to another. I'm able to copy the created DLL via post build events like so:
So i want to copy the file in project one '/Views/ModuleHome/Index.cshtml' to a folder in project 2. How do I copy file(s) to my desired project via post-build event? Thanks
8 Answers 8
and if you want to copy entire folders:
Update: here's the working version
Here are some commonly used switches with xcopy :
- /I - treat as a directory if copying multiple files.
- /Q - Do not display the files being copied.
- /S - Copy subdirectories unless empty.
- /E - Copy empty subdirectories.
- /Y - Do not prompt for overwrite of existing files.
- /R - Overwrite read-only files.
I added this line to my post build and i get this error "Error 1 The command "xcopy "C:\Users\tcompton\Downloads\MEFMVCPOC\ModuleA\Views\ModuleAHome\Index.cshtml" "C:\Users\tcompton\Downloads\MEFMVCPOC\MEFMVCPOC\Views\ModuleAHome"" exited with code 2." What does this mean?
Look at the output window: Ctrl+W+O . Does the Views\ModuleAHome folder exist at the target location? Look at the output window for the exact command being executed and then read the documentation for the xcopy command to understand the different switches available: xcopy /? .
The folder 'Views\ModuleAHome' exists but its not part of the target project meaning you have to click 'show all files' for it to appear in VS.
I don't think that the fact that the destination folder is not part of the destination project makes any difference to xcopy. This command operates directly with the file system. As far as making this folder appear as part of the destination project is concerned, automating this task might be more difficult.
Notice the quotes in source path and destination path, but not in path to exludelist txt file.
Content of ExcludedFilesList.txt is the following: .cs\
I'm using this command to copy file from one project in my solution, to another and excluding .cs files.
Thank you. The /exclude: works after adding quotes to your-source-path and your-destination-path . Without those quotes it doesn't work at all.
xcopy "$(TargetDir)*$(TargetExt)" "$(SolutionDir)\Scripts\MigrationScripts\Library\" /F /R /Y /I
/F – Displays full source & target file names
/R – This will overwrite read-only files
/Y – Suppresses prompting to overwrite an existing file(s)
/I – Assumes that destination is directory (but must ends with )
A little trick – in target you must end with character \ to tell xcopy that target is directory and not file!
I use it like this.
Note the use of this. $(TargetDir) has already '\' "D:\MyProject\bin\" = $(TargetDir)
You can find macro in Command editor
Call Batch file which will run Xcopy for required files source to destination
This command works like a charm for me:
It recursively copies every dll and exe file from MySolutionPath\libraries into the bin\debug or bin\release .
You can find more info in here
Like the previous replies, I'm also suggesting xcopy . However, I would like to add to Hallgeir Engen's answer with the /exclude parameter. There seems to be a bug with the parameter preventing it from working with path names that are long or that contain spaces, as quotes will not work. The path names need to be in the "DOS"-format with "Documents" translating to "DOCUME~1" (according to this source).
Note that the source and destination paths can (and should, if they contain spaces) be within quotes, but not the path to the exclude file.
If you want to take into consideration the platform (x64, x86 etc) and the configuration (Debug or Release) it would be something like this:
Linked
Related
Hot Network Questions
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2022 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2022.5.9.42071
Задача: После сборки проекта в отладочном режиме автоматически скопировать файлы *.pdb и *.exe в нужную директорию.
Инструментарий: Visual Studio
Решение: Для решения данной задачи можно воспользоваться несколькими вариантами:
- Указать Output path в свойствах проекта
- Настроить Post-Build event
Рассмотрим оба случая:
Откройте свойства проекта (Для этого нужно кликнуть правой кнопкой мыши в Solution Explorer на проекте и выберем пункт меню Properties или выделить проект и выбрать в главном меню пункт Project — Properties…)
Для указания Output path нужно открыть вкладку Build и в разделе Output изменить параметр Output path (Рис. 1). В моем случае указан относительный путь который указывает на папку которая расположена на 2 уровня выше от расположения проекта.
Рис. 1. Настройка Output Path
Если Вам не подходит первый вариант — можно воспользоваться вторым вариантом — post-build event’ом.
Откройте свойства проекта и перейдите на вкладку Build Events (Рис.2.). Если вы хотите узнать какие макросы можно использовать при написания post-build event’a — нажмите кнопку Edit Post-build, откроется окно в котором нужно нажать на кнопку Macros>>. В результате в этом же окно отобразится панель в которой будут описаны все макросы, которыми кожно воспользоваться в коде.
Рис. 2. post-build event
Названия макроса можно использовать следующим образом $(), где — имя макроса.
В результате у меня получился вот такое скрипт, который копирует собранный файл проекта и файл .pub в указанную папку, только когда установлена конфигурация — Debug .
if Debug == $(ConfigurationName) (
xcopy "$(TargetPath)" "" /y
xcopy "$(TargetDir)$(TargetName).pdb" "" /y
)
Читайте также: