What is Manual Build? - visual-studio

Seems like a pretty obvious question but I haven't been able to find this anywhere online - but what exactly counts as building something manually? As in if I do Ctrl+Shift+B on Visual Studio is that manually building? Then how could I go from that to automated build (running it from command line?). All I know is that I am supposed to use MSBuild to do automated builds on a project that is currently built 'manually'.

What is Manual Build?
Whether you are using Visual Studio or MSBuild command to build is considered to be manual build. That because you need to build your project manually every time no matter you are using Visual Studio or MSBuild command. And the hot key Ctrl+Shift+B is a quick start mode to build project in Visual Studio.
If you want to automated build, you should consider 'continuous integration' For example, TFS(Team Foundation Server), Teamcity, etc. You can easily search those continuous integration info on the internet.
The biggest difference between manual build and automated build is that you should manually build your project every time when source code changes, but automated build will execute the build automatically by continuous integration tool when source code changes, no need to build your project manually.

Related

How can I consistently automate, using TFS vNext build steps, building whatever solution files our development teams get working using Visual Studio?

Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.

Developing in Visual Studio but using custom, non-msbuild build scripts

I'd like to start exploring options outside of msbuild for scripting my builds, like CAKE or FAKE.
What's the best practice for developing .NET Core in Visual Studio but using external build scripts? Like, how does this actually work in practice?
I'd like to continue to take full advantage of the VS environment, including Intellisense, package management, IDE features like Go To Definition, etc.
Do people somehow customize/override the VS F5 and/or Ctrl-Shift-B behaviors? Or do they use .csproj files and let VS and msbuild do its own thing until it's time to generate a "real" build, and then run their own scripts at that time?
Locally on your development machine you usually run build scripts from command line. You don't write build script to help you while developing. You write them that your code is verified by an automated build and that you automate processes like creating deployment packages, publishing nuget packages...
Most common practice is contionous integration approach. This means that when you or someone in your team commits/pushes code to the version control system(like git svn...) your selected continuous integration tool (like jenkins, team city...) pulls source code from version control system and runs your build script which for example compiles your code, run tests, creates deployment package.
I would also suggest that you take a look at flubu. Flubu is a cross platform build automation tool for building projects and executing deployment scripts using C# code. It's easy to learn beacuse you write your build script entirely in c#.
More about flubu can be readed here: https://stackoverflow.com/a/46776658/3118784

Run Code Analyzers in VSTS project build

In VSTS (hosted TFS) I have a build definition which uses MSBuild. What I would really like is to have pull requests annotated with any rule violation detections. However I can't get the analysers to work at all. What I've done so far;
Installed Microsoft.CodeAnalysis.FxCopAnalyzers in one of the projects that gets build
Verified that running "Analyze Code" in Visual Studio does output rule violations
All the *.ruleset files are not available on the self-hosted build agent, as it only has MSBuild installed (no full-fledged Visual Studio). For the same project as in point 1, I've also used a custom ruleset.
I have also build the project on a hosted build agent (which has VS2017 installed), but also to no avail.
With all of the above, the build log / build overview in VSTS doesn't list any rule violations. It's my understanding that the code analysis should be run automatically and the output should appear on the build overview page (i.e. https://MYSITE.visualstudio.com/MYPROJECT/_build/index?buildId=XXX&_a=summary&tab=details).
The Code Analysis setting is based on the configuration and platform, so you need to make sure you build the project with the same configuration and platform that enabled code analysis on build.
You also could specify it in MSBuild Arguments of MSBuild task:
/p:RunCodeAnalysis=true;CodeAnalysisRuleSet=..\RuleSets\MyMixedRecommendedRules.ruleset

How to get output in team build in TFS

I started learning TFS Team build. I am having a basic doubt. I referred this
article. I followed the steps exactly and got succeeded. I created a Console Application and pushed in TFS using TeamServices. My doubt is when we build a Console application in visual studio we will get an exe in bin folder.
Same way in this team build how to get the output in my local machine ?
What is the difference between the local build using Visual studio and this team build ?
EDIT :
I added like this. Still I am not able to see the output in the RELEASE folder.
I got the result as success saying
Still I couldn't figure out the output - the exe produced as a result of build.
Am I doing anything wrong ?
Note : I have a requirement like what you explained in the answer. So why I am using TFS team build. Since I am new I am experimenting with a small example.
When to use a build system
Team Build does not replace Visual Studio build. Use Team Build when you have a complex / lengthy build, to easily integrate running unit tests as part of the build or to deploy assemblies to a server after the build is complete.
Most people will setup a TFS build definition to run as "Continous Integration" build, meaning that whenever a commit is checked in, a build occurs. The build would compile and run tests and if it fails all developers can be notified.
How to get to the build output
When using a build system like TFS build, the build is done on a remote machine. If you want to retrieve the output of the build, add a Publish Build Artifacts step to your build definition. Since the build happened on a remote machine, the remote machine does not have access to your local developer machine.
The artifacts (assemblies) will be available for download on the build summary page:

trigger build tasks in visual studio and tfs build

I have a c# solution with multiple projects. I have a .sln file I build the solution with in VS2012.
I am looking to set up TFS Build and want to include some custom msbuild actions, such as running stylecop and fxcop rules. I want these tasks to fire when building the solution locally and within tfs build.
I have looked at creating a .proj file for the solution. However, I am not sure how this can be setup locally and to run the tasks locally.
What is the correct setup for tasks to be run within tfs build and visual studio?
My best guess is to set the flag "Enable Code Analysis on Build" in the project settings "Code Analysis". More on that here.
I suppose that running StyleCop is better fitted in the IDE (check R#) or the VCS (check SVNStyleCop) on commit. I am not sure if the same exists for GIT or other repositories.

Resources