I am have built an MSBuild project that has
the main .proj file with several Targets inside,
several .targets files
and several .rsp response files to run this project in several ways. Such as
Build, Clean/Build/Deploy, Clean/Build/Test/Deploy.. You get the idea.
What I now want to do is take this MSBuild and run it in TFS scheduler after I pull the source code. So the workflow should be
1. Pull the source code in TFS
2. Run MSBuild project in the scheduler so I might set up tasks to run hourly and nightly.
The MSBuild will take care of Deploying to IIS, unless someone has a more efficient way of deploying after an hourly build.
How can I accomplish this in TFS?
Thank you
You can use the Team Explorer UI in Visual Studio to define a "scheduled" build definition.
http://visualstudiomagazine.com/articles/2012/04/11/creating-a-build-definition-in-tfs.aspx
If you want to take this to the next level, research "continuous integration" which is also a built in capability.
Related
I've added a Blank Node.js Web Application project to my solution. It is a *.njsproj the among of other C# *.csproj projects.
The project works fine. Visual Studio build runs npm run build according the package.json. There is only one thing bothering me. The *.njsproj is built everytime I build the solution.
Visual Studio can recognize when there is no change in the C# *.csproj projects and skips them saying they are up-to-date:
========== Build: 1 succeeded, 0 failed, 29 up-to-date, 0 skipped ==========
However, this does not work for the *.njsproj. The npm run build (raised from AfterCompile target in Microsoft.NodejsToolsV2.targets) is executed every single time even though there is absolutely no change in any of the solution projects or files at all.
Is Visual Studio even able to track changes of Node.js project to skip the build or there is no chance to make it work similar to the C# projects?
All the Node.js project files have Build Action set to None.
I think it is impossible. This is related to the VS IDE's internal build mechanism for Node JS projects of this type. And it is designed by that.
And I should tell you that the up-to-date check is a feature for VS IDE. You can try the VS IDE Build and MSBuild command line build msbuild xxx\xxx.csproj -t:build with the c# project, and you will find that:
IDE build will not execute any msbuild system target, and it detects that it should not build again since there is no changes to minimize the workload of MSBuild.
However, when you use msbuild command line, no matter there is no changes, it still invokes the many system default targets which will make a burden with a large solution.
So the up-to-date is a feature for VS IDE which will helps reduce the burden of msbuild.
We could only modify target one by one to skip by inputs, outputs. But this is meaningless since up-to-date is a new detection mechanism which is not dependent on MSBuild and Targets. There is no msbuild function to get the up-to-date under node js projects.
That is an internal mechanism We cannot handle that area, you need to contact the Microsoft product team by VS IDE menu-->Help-->Send Feedback-->Report a problem or that.
My ASP .NET Solution (net framework 4.7.2) consists of several projects. I am interested in having a build definition (Azure) that will run my tests from a specific folder ( that folder contains some tests projects -nunit tests )
I have searched for information about this, but most solutions seemed constructed towards building & releasing, with all the tests in the whole solution being run.
How should I approach this? I will need to build my solution (Visual studio build ) as a task (?), but what should be the steps(tasks) to select and run my test folder ?
You could actually do something like this How to run a list of tests with VsTest.Console on windows agents if you prepare such file with list of tests from that folder.
You can find vstest.console.exe on this location on host agents
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
In that case you just need to prepare such file, put it in source control and run in your pipeline.
I will need to build my solution (Visual studio build ) as a task (?)
The answer is yes. That because the folder **\bin\** is ignored by source control by default. We need to build the solution in our build pipeline to generate dll files.
but what should be the steps(tasks) to select and run my test folder ?
We could specify the specific folder in the Visual Studio Test task in the Search folder:
Or specify that folder in the option Test files:
My VSTS Repository contains 50+ Visual Studio projects of Azure Web Apps and I was requested to get an automated build and release process in place for one of them. I went thru and selected a Visual Studio template and on the build solution I selected only the one project I wanted to do a build and release on but when I queue the build to run it starts doing a get latest on every project in the repository. This is unacceptable because it would take hours to get latest on all the projects just to compile and publish one website. This makes no sense to me. Is there a way to limit what the build does a get latest on?
Depends on the repository type you're using. In case you're using TFVC, you can go to the Repositories tab and configure your workspace mappings to match exactly what you need for your project.
If you're using Git, then you're out of luck, the way git repositories are synced, the whole repository is always fetched when a build is initiated.
If you're using your own build agent, you can configure it to retain the sources directory, in which case only the differences are synced when a build runs.
We currently use TFS to deploy builds to our servers in different environments such as QA, PreProd and Prod. In the current method, the build agent gets all latest from TFS, builds and publishes to whichever environment specified.
I know that you can actually just publish just to a drop folder where it creates PublishedWebsites folder, but how can you publish to servers from drop folder mentioning specific build? For example, there may be build #7, which our QA team has certified. We want to make sure that that is the build that is going to production and not latest content which might have some check ins from other team members.
Any help would be appreciated. I referred this link, but it is mentioning about overriding OutputRoot directory in publish.proj file, which is not created in the solution that we created using Visual Studio 2012.
http://www.asp.net/web-forms/tutorials/deployment/configuring-team-foundation-server-for-web-deployment/deploying-a-specific-build
You have multiple way of solving the needs.
The best option is to use LabManagement; it will take care of computing the correct Drop folder. See Using a Lab Environment for Your Application Lifecycle for details. The idea is to use the build-deploy-test workflow to deploy and run tests on a group of machines running Test Agent.
You can setup a more sophisticated process using Release Management, a new feature of TFS 2013 that you can add to 2012 as well. It offers to design your promotion process and control who authorizes deployments.
You should neither use Build or Lab Management to do deployments. Both are poor solutions for this as this is not what they were designed for.
Microsoft added a dedicated release management tool with visual studio 2013. I have configured and used it with both 2012 & 2013.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
This will be much easier than either of the other tools.
Just wondering if there is a preference between sln or csproj files when building projects in TFS 2012. We typically build sln files in TFS to support our dev teams and that's usually the standard, but one team is asking why we can't build csproj files instead in TFS.
I noticed that to build a csproj file you have to provide arguments in the MSBuild Arguments field for a TFS build definition, and you do not have to provide these arguments when building a solution file. So other than this small detail I'm not sure what the pros and cons are between building an sln vs csproj.
Can someone please shed some light on the benefits, pros/cons of building a sln vs csproj in TFS, is there a common practice, a standard, or does it really matter?
Just wondering if there is a preference between sln or csproj files
when building projects in TFS 2012. We typically build sln files in
TFS to support our dev teams and that's usually the standard, but one
team is asking why we can't build csproj files instead in TFS.
Why do they want to do this? Is there some sort of advantage articulated in this inquiry?
I noticed that to build a csproj file you have to provide arguments in
the MSBuild Arguments field for a TFS build definition, and you do not
have to provide these arguments when building a solution file. So
other than this small detail I'm not sure what the pros and cons are
between building an sln vs csproj.
A .sln is a master project that is converted to an msbuild script at runtime and will use a metadata file using the same schema as the .csproj projects in your solution.
To see what I'm talking about, open a command prompt, type "SET MSBUILDEMITSOLUTION=1" then "msbuild.exe solution.sln", then parse the new "solution.metaproj" and "solution.metaproj.tmp" files.
Can someone please shed some light on the benefits, pros/cons of
building a sln vs csproj in TFS, is there a common practice, a
standard, or does it really matter?
A .csproj would be a single project while a .sln would be a collection of projects. Building a single .csproj would yield the output binaries of that project (along with dependencies) and building the entire solution would yield the outputs of the entire solution.
I had the same question. Build times may be a bit slower but I haven't tested this myself (probably a negliable difference). I believe that when you build using the solution file it will automatically set 'BuildInParallel' to true.
Faster Buidls with MSBuild
I am currently working on the TFS 2012 deployment build. Based on what I experience, you don't have to provide MSBuild Arguments unless it is really required.
Lets take the following example: You have a solution with 2 projects,
Soln
> Web Proj 1
> Console Proj 2
> Dependency Library Folder
case 1: building a sln
a. In source settings, you have to mention only your solution folder. The MSBuild will automatically take care of any dependencies as they are within the solution.
b. In Process -> Items to build, you have to mention your solution file.
c. For example, if your solution has a web project, then the MSBuild output will be as shown below,
\\<build server> \d$\Builds\<Build Name>\<Build File Name>_20141210.6\_PublishedWebsites\<web proj>
Case 2: building a csproj
a. In source settings, you have to mention only your csproject folder and also the dependency folder path separately.
b. In Process -> Items to build, you have to mention your csproject file.
If you are looking for something more specific, please let us know.