I am building my solution in Visual Studio Online Build, the default 'steps' are build/test/index+publish/publish build artifacts. I want the build to be placed in a folder in my source control (rootfolder/builds). However, I don't see an option to enter an output-path anywhere.
EDIT: I see that next to 'timeline' on the build screen there is the option to view the 'Artifacts', but, I want to see/copy the drop to my TFS online project folder like '$myproject/mybranch/builds/'
The option to store the build drop on the TFS server is no longer supported. It was introduced as a temporary measure in 2012 and replaced with server drops in 2013.
Server drops are stored in an unversioned store in TFS/VSO and does not incur the overhead of versioning.
In TFS 2015 this transitioned to the new Artifacts repository. All build output is stored on the server and is accessible in the web, and through an API.
The way things stand right now, this is not possible. You have two options to drop your build outputs
Team Foundation Server
UNC file share if you use a on-prem agent.
See the Artifact Type argument on Publish build artifacts.
I it is possible with a custom powershell task. I have recently created a powershell build task that could "check-in" your drop artifacts into a folder like $myproject/mybranch/builds.
Have a look : https://github.com/skuvnar/visual-studio-team-services-scripts.
Although its possible, I would suggest against it - could lead to all sorts of trouble with the builds.
Related
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
We have a C# .NET project using Visual Studio 2013 and we're setting it up to release and deploy with Visual Studio Team Services (VSTS). The websites were pretty simple and easy to set up and they work fine. A few projects are libraries or Console applications and we're trying to determine the best method for creating an automated release for these.
The publish profile asks for a location to publish to - we've experimented with the build drop on our VSTS build server (where all of the other files are) and then asks for a website, a UNC path or a CDROM. We chose "UNC Path" and put the same build drop location in, but in UNC format.
It hasn't really worked yet, so I thought I would see if any best practices for creating VSTS releases and deploys for Console or Code Libraries exist.
Thank you!
Have you considered installing the agent on the target environments and using a release definition that simply copies the right files at the right place?
Regards
Note: copy path shouldn't be hardcoded and rely on variables.
To specify the agent queue by going to the tasks tab when editing the release definition. Click on the "run on agent" header, that will open the details, select your queue here.
Agent queues can contain multiple agents, so your job when you add agents is to organize them by queues that make sense in your context.
I have a solution in TFS 2015 that using continues integration build method, what i want is every check-in triggers a build that selectively only output changed dlls, exe, into the artifact folder. Is there a such configuration to do so?
Unfortunately, there is no this built-in configuration with vNext build in TFS2015.
However, a obvious solution is adding a Powershell Script on what to publish as artifacts. Using a PowerShell script to organize everything and pre-compressing in single files is the best approach for your situation.
Detail step and screenshot please take a look at this blog: Manage Artifacts with TFS Build vNext
How do I create a TFS Build which automatically runs a Release (deployment) from Microsoft's Release Management for Visual Studio 2013?
In order to start a release off from your TFS Build, you need to change the Build Definition. Luckily when you install Release Management it creates a Build Template for you to use with an example. In may instances this will be enough to get you going.
Release Management Build Process Template
Release Management Build Process Templates are not installed in TFS by default, so it won’t appear as an available build process template until you add it.
Find the Template in your server install in : C:\Program Files (x86)\ Microsoft Visual Studio 12.0\ReleaseManagement\bin\
TFS 2010 : ReleaseDefaultTemplate.xaml
TFS 2012 : ReleaseDefaultTemplate.11.1.xaml
TFS 2013 : ReleaseTfvcTemplate.12.xaml (or ReleaseGitTemplate.12.xaml if using GIT)
To add the release management build process template, you will need to check it in to your TFS source control in the BuildProcessTemplate folder in your project. Then add the build process file when editing (or adding) a Build Definition. Once the release management template has been added to the list of build templates, you can start using it.
Please ensure you use the above templates from the Release Management Server and not the client directory as I did initially. You will get rather odd errors during your build if so, such as:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (3883): Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions are:skipInvalid.)
Package Pickup \ Path to package.
When you set up your components, Release Management needs to know where to pick up your installation files to do something with them. When you created your Release Template it should be connected to a specific build by selecting the build definition that will initiate it (also tick "can trigger a release from a build?"). When you add the components to install as part of your release you specify their Source. "Builds with application" should be selected. The bit that got me was the big empty box next to the Build Drop location which is a mandatory field. My initial reaction was to fill it with the name of the msi file I was trying to deploy. That makes sense right? wrong. If I queued a build from Visual Studio I kept getting the following message.
Package location '\\blah\blah\Build Name\Build Name_20140707.3\A.Product.To.Install.msi' does not exists or Deployer user does not have access.
The file did exist in the location and the user the deployment agent was using did have access to the drop directory. I had also confirmed it was able to access it using ProcMon. After sleeping on it I decided to hover my mouse over the input box and a nice tooltip pops up saying:
The package path relative to the build drop location is required for
component bound to a Release Template. If the package is directly at
the root of the build drop location, you need to enter the '\'
character.
So, after my eureka moment, I deleted the msi file name and replaced it with a "\" and queued the next build. It worked. In retrospect I think they should remove the mandatory requirement for something to be entered to replace the need to enter a "\". It's a little hidden and not intuitive.
See MSDN Article here for more info
For Modified Build Process Templates
First post on Stack, so please be gentle!
We are just getting into Continuous Integration with TeamCity. We have setup a TeamCity project(s) that looks like so:
Solution Build (builds entire solution) - .Sln file
Debug to Dev Server (builds .csproj in Debug configuration and Deploys to test server using MSDeploy)
Release to Production (builds .csproj in Release configuration and Deploys to production server using MSDeploy)
Within our Umbraco Visual Studio project (which is a Web Application not the standard Website project type) we have the umbraco_client and umbraco folders excluded from the Project, primarily because they are already compiled and don't need to be re-compiled by our process. Both folders are however included in the SVN repo.
The problem we are experiencing is that because these two folders are excluded from the Visual Studio project, TeamCity does not deploy them.
So my question boils down to "how do you include folders in the TeamCity build package where the folders are in the SVN but excluded from the Visual Studio project?".
Any pointers would be really appreciated.
Thanks
dotdev
We've been using TeamCity for umbraco. This is what we've been doing recently on our internal dev servers:
/p:Configuration=Debug
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=OurDevServer/msdeployagentservice
/p:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=umbraco_site
/p:IgnoreDeployManagedRuntimeVersion=True
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
/p:SkipExtraFilesOnServer=True
/p:ExcludeFoldersFromDeployment="media;App_Data\Logs;App_Data\preview"
/p:IncludeSetAclProviderOnDestination=False
/p:AuthType=NTML /p:UserName=
They key to solving the problem you are having is
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
By default, it is set to something like "AllFilesInProject". Combining FilesToIncludeForPublish with the ExcludeFoldersFromDeployment can give you some control over exactly what TeamCity attempts to deploy
I would suggest using an approach similar to the one described in this blog post: http://blog.iqit.dk/2013/11/using-package-restore-in-umbraco-projects
You don't mention nuget, so assuming you use a zip or web pi to setup Umbraco in your solution, but you should still be able to use the targets listed in msbuild or add to your web applications .csproj when building your solution. It would require that you have the Umbraco and Umbraco_client folders somewhere in Svn repo or on your build server in order to copy it in.
As an alternative I can also recommend that you download the UmbracoCms nuget as that contains an extension to the msdeploy pipeline that includes the two mentioned folders in an msdeploy zip package. But again also based on the nuget install and thus a standard location for the Umbraco folders.
Hope this helps.
I've based my TeamCity builds on Troy Hunt's excellent "You're Deploying it Wrong" series - which is an excellent step by step guide to integrating Visual Studio based projects and TeamCity. http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
As to excluding the umbraco and umbraco_client folders from SVN; a complex Umbraco build will probably have changes in the Umbraco folder to the default build eg adding Umbraco Event Handlers, adding new Umbraco Sections, changes to back-office tabs. I don't think umbraco_client will change unless you get into changing rich text editors and so on - but it is possible. So I'm not sure that excluding those particular folders is correct. Excluding the media folder is often discussed as well - but it does make TeamCity config simpler if everything is there.
But to answer your question you could exclude them from the build and copy them onto your build server; then add a 'Command Line' runner build step that simply copies them back into place before the build step starts.
I usually add a source control change step that fires a rebuild and have two build steps in TeamCity for an Umbraco project. One is a 'Visual Studio (sln)' runner to check that the sln file has every reference and third party product set up correctly (this should eliminate the 'it works on my machine' issues); and the second is a 'MSBuild' runner that replicates the csproj build process. With the second build step with the right permissions (if your ports are open on the machine you're deploying to, or you're deploying to the same machine as you are on) you could test this in Visual Studio or DOS.
These two build steps should be able to deploy to the IIS website on a staging server; and if the right ports are open on your live or UAT server you could then add a third build step and deploy it onwards (if the first two build steps run properly).