What way should I go when I want to build some projects and afterwards I want to do some extra stuff? Some kind of finalizing the build.
I need a target that executes just after the last project was build (Rebuild All Succeeded). In that target, some Files including a deployment guide (.docx), some SQL scripts and PowerShell are moved / copied into a predefined directory hierarchy. I already build WSPs and other files that get copied to their destination, but not those "global files".
I thought of the way that after the last project in the build order was build, I can trigger that target, but what if in the future the build order will change?
Is there a "AfterRebuildAll" Target or some best practise?
If you're building with TFS, there are customizable TFS build targets.
If you're building with msbuild.exe from the CLI, you can look into placing an "after.solutionfile.sln.targets" msbuild project file in the same folder as your solution that contains your custom targets.
Related
I am attempting to set up a DevOps build definition to build a VS2017 solution on an on-site agent.
After adding the standard Visual Studio Build step to the build pipeline, the build agent reports the error:
"Error MSB3030: Could not copy the file "d:\agent_work..."
This seems to be happening for any LINKED item.
These items were added to the project from other solutions ("add existing item->Add As Link")
The solution/project builds fine locally on developers PCs, but not on agent.
All that is really required is for the build step to copy these files to an output directory to be included in the build artifacts.
Properties for all linked items are set to "content & copy always".
Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found.
Am I missing something basic here?
This is a workspace mapping issue. You have files that aren't part of your build workspace. You will need to update your build to have a workspace that is mapped in a fashion equivalent to your developers' workspaces.
If your developers are referencing files outside their workspaces, this is a problem that you will have to rectify, then update the build accordingly.
Solved the build error : "Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found." by adjusting the mappings in preceding "get sources" step. After looking at the logs of the build it appeared that the agent was looking in "d:\agent" for some items and "d:\agent\s" for other items (and not finding them). Don't know why it was looking in the "s" sub-directoy. But anyway, the work-around was to include the "s" in the local path mappings for "Local path under $(build.sourcesDirectory)" (ie: s/MyLocalPath)
I have two projects in TFS, WebSite and Reference, and they follow the structure:
$\
WebSite: Main project to be built
Reference: Repository with many referenceable dlls.
Website.dll uses dlls existing at Reference but, for several reasons, they are not contained in the same solution, and may be mapped to different folders that do not follow the VSTS structure.
So, in order to have the Website project compiling locally, the Reference's.dlls Hintpath at Website.csproj have been manually changed to a specific, absolute path, common to all developers' machine.
Now, we're experiencing with CI/CD, and we're thrilled with the hypothesis of having VSTS doing the dirty, tedious work of building/deploying. Thing is, since Reference.dll is not in the same project as Website, building ends up lacking essential libraries (the aforementioned Reference folder) and fails.
Is there a way of telling VSTS to GET Reference's dlls (which are compiled at this point), copy them to the directory Website.csproj is being built at and let them be used to build the main project?
What I've tried:
First:
Map Website and Reference in the Get Sources step
Using a Copy Files task, set Source FOlder as $\References and Target Folder as $(Agent.BuildDirectory)
Build
Now:
Added all the references in the main project.
In both cases, none of the references are found, and the
The type or namespace name '(namespacehere)' could not be found (are you missing a using directive or an assembly reference?)
errors are thrown.
I've been searching through the vsts help section, but can't seem to find any obvious solutions.
Any help is greatly appreciated.
It’s mainly caused by the Reference's dlls are not added in source control (TFVC repo).
First, please make sure you add the Reference's dlls into the website project. So the project file will contain the reference as below (ClassLibrary1.dll as the reference in below example):
<Reference Include="ClassLibrary1">
<HintPath>..\..\ClassLibrary1\ClassLibrary1\bin\Debug\netstandard2.0\ClassLibrary1.dll</HintPath>
</Reference>
Then you can use any of below options to make the referenced dlls work.
Option 1: add the referenced dlls into source control
If you have added .tfignore file into your TFVC repo, it will ignore files and folders under **\bin, so the reference dlls not checkin to TFVC repo by default. You can follow below options to checkin the reference dlls into TFVC repo:
Exclude the reference dlls in .tfignore
Exclude the dlls you want to refer in .tfignore. The format is:
!**\referencename.dll
Such as !**\ClassLibrary1.dll.
Add the reference dlls into source control
In VS -> Source Control Explorer -> Add items to folder -> selected the dlls.
Checkin and double check the dlls are added into TFVC repo
In VS pending changes window, there will show the dlls and the .tfignore file as Inculded changes, checkin the changes.
And double check the dlls are added into TFVC repo in VSTS web page.
Option 2: build the reference project before building website project
If you do not want to add the dlls into source control, you can also build the reference solution firstly so that the reference dlls will generate before build the website project. Details as below:
Edit build definition -> add VS Build task (specify reference solution) before building website project -> Save and queue the build.
Note: for option 2, the build configuration you specified in the relative path should be consistent with the build configuration in VSTS build definition.
Such as I specified Debug in the relative path ..\..\ClassLibrary1\ClassLibrary1\bin\Debug\netstandard2.0\ClassLibrary1.dll. So in my VSTS build definition, VS build task to build the reference project, the build configuration must be Debug.
Now, no matter which option you are using, VSTS build will not show the error message The type or namespace name '(namespacehere)' could not be found.
The correct way to approach this is to not store references in source control. Turn them into packages, store them in a package management feed, and restore them during build. Developers will automatically restore them on build.
I have a build definition in VSTS and I want the unit test projects to be run as part of the build, do I then need to include those dlls in the deployment to the Azure web app? surely they are no longer needed after the build.
No matter you are going to use Release or not, you could only copy the files that you need and publish them:
If you are going to use TFS Release to deploy, then in Release definition, you can just select the build artifact. If you want to deploy in build definition, you can add deploy task after Copy files and deploy from the target folder in Copy files task.
I have a .NET Core project that is auto-built in Appveyor and deployed to Nuget. By default, every successful build causes a new Nuget release.
However, there are many cases when a new release is meaningless because the library's actual code has not changed:
Readme updated
Unit tests added
Appveyor configuration changed
Other cases
It is possible to configure the build so that Nuget publishing only runs if there are changes in the actual code (for example, in folder X)?
There are a few options.
Commit filtering. Note that with it the whole build, not just deployment will be skipped if nothing in folder x changed. You may need a build without deployment at least when unit tests added. As a workaround consider adding separate AppVeyor project which will build and deploy only if folder x changed and keep current project to build every time, but not deploy
Inspect changed files with script. Please check this sample on how to check those files if you use GitHub. So if you see that files in folder x changed, you can set some custom environment variable (lets say you call it deploy_nuget) to true, and use it with a conditional deployment.
I have used the
/p:GenerateProjectSpecificOutputFolder=True for creating build for each and every project in my solution and now i wanted to customerize the folder structure on my needs. How can we achieve this?
enter image description here
If you are using XAML build, you can customize Binaries folder in TFS Team Build by modifying the build process template. Adding CreateDirectory Activity and FindMatchingFiles activity are necessary, following this blog for more details.
If you use the new build system, that will be much easier to manage artifacts. With task Publish Build Artifacts, you can specify contents in the task, also you can add as many Publish Build Artifacts task as you want to manage artifacts. More details, check http://www.codewrecks.com/blog/index.php/2015/06/30/manage-artifacts-with-tfs-build-vnext/
Alternatively you can extend your build definition with a PowerShell script at different points within the build:
Pre-build
Post-build
Pre-test
Post-test
Note I am using the TfvcTemplate.12.xaml template. This is the build template that comes with TFS 2013.