Im having a hard time figuring out what the best approach is when designing my build process. It seems Microsoft have turned things around (again).
I am using TFS 2015 and Visual Studio 2015. For earlier versions of TFS I have normally created custom code activities that I plug in to my build definition process file (xaml). I like this approach because it gives me great flexibility and enables me to code .NET classes. I used these guides:
https://msdn.microsoft.com/en-us/library/dd647551(v=vs.120).aspx
http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx
In TFS 2015 it seems that there is no documentation on how to create custom code activities. In fact, it seems that Microsoft have changed things and now focuses on scripting languages in stead of custom .NET code: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/steps/index.
I have created a custom code activity and it seems to be working in TFS 2015 (with a few hacks) so it is still possible, but I am nervous that this approach is no longer the way to go.
Can anyone provide information about what is happening here?
TFS 2015 introduces new builds, which are web- and script-based, and highly customizable. Meanwhile, TFS 2015 will continue to support the XAML Build templates and controllers.
The new builds are based on a different architecture and run on a completely different system. Currently, you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
Which builds should I use?
If you are new to Team Foundation Server (TFS) and Visual Studio Team Services, you should use this new system. Most customers with experience using TFS and XAML builds will also get better outcomes by using the new system.
The new builds are web- and script-based, and highly customizable. They leave behind many of the problems and limitations of the XAML builds. For example, this new system embraces the diverse set of domain-specific languages (DSLs) that developers used to build the code on their dev machines. We expect this will reduce the chances of running into the "builds fine on my machine but not on the CI server" problem.
If you have heavily customized XAML builds and custom activities, you can continue using those builds until you are ready to port your business logic into scripts that can run in the new builds.
Useful articles for your reference:
https://blogs.msdn.microsoft.com/visualstudioalm/2015/02/12/build-futures/
https://msdn.microsoft.com/en-us/library/vs/alm/build/feature-overview
Related
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
there is no code. Do we need to Re-configure all build server again?
After migration on VSTS can we configure All build servers on premises as well using old all XAML build definitions or not?
Please suggest on this.
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft:
XAML build is still here until now. Current state :
If you have any XAML build data in your team project collection, you
will get a warning about the deprecation of XAML build features. You
will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds. If you need to create new
XAML build agents, you will need to install them using the TFS 2015
build agent installer. Please refer to official document -XAML builds:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2#xaml-builds
And we will keep it longer, how long does it can be used depend on
user feedbacks.
Installing TFS2015 Update 4.1 locally allows you to configure Build Server, Service and Agents that are connected to Azure DevOps Service, and run all your XAML builds from either Azure DevOps or Visual Studio.
XAML builds are no longer available in VSTS, so they will not work at all after a migration.
The good news is that TFS 2017 supports build vNext so you can convert your builds before you migrate to make sure you can still build after the migration.
Build vNext (Azure DevOps Pipelines) are much more flexible and easier to set up and customise than the old XAML builds. However if you have a lot of customised builds then it might take a while to convert them all.
One big advantage of the new build system is that the same build can be used across multiple branches, which might mean that you don't need to put as much effort in to converting builds as in the XAML system you needed a build per branch.
My suggestion is that you begin by familiarise yourself with the new build system and start to convert the builds before you migrate, then you can import you TFS database in to VSTS.
I currently have a custom XAML build workflow which performs a lot of validations based on code structure, folders, file content and even database configuration.
Currently we need to consider to migrate it to TFS 2017, and I'm trying to understand the possibilities, effort and pitfalls and this is where I could use your help.
I have logic built in C# and then I look at MSDN documentation the language seems to be Javascript, GitHub samples seem to be Typescript. Am I forced to use one of this languages? any preferred one or limitations that I should be aware of? Can for instance, I connect to a database directly? or it's better to have an API and just use REST calls?
Can I for instance, use .Net object which have already some wrapped logic?
I also noticed that on the manifest file I can declare inputs, but can I somehow use outputs? For example, I have a task that does validation and in the end I would have a task to send an e-mail with the result of that validation. Is this possible?
Thank you in advance.
You are right in concluding that XAML builds are deprecated. The new Task based system is much more flexible and now that we even have YAML support, you can move to Builds as Code.
The reason you're seeing Build Tasks in TypeScript (which is a superset of JavaScript) because of the cross platform nature of NodeJS. This allows your tasks to run on Windows, Linux and Mac. In the mean time we also got .NET Core support. You can also use PowerShell if that's more of your liking.
Regarding your 'can I connect to a database' question. Yes you can, if you want it is another question. This will massively slow your build down and will make your build fail if there are issues with database connectivity. I would suggest asking a second question here on Stackoverflow to describe your situation and discuss if there is a better alternative.
You can use output variables from your task and reuse these in the next tasks. That's all supported and no problem (see https://roadtoalm.com/2016/08/11/set-output-variable-in-a-powershell-vsts-build-task/ for an example).
There are too many questions here and they are broad.
Whatever, XAML Build are deprecated in TFS 2017 and will not be available in the next version of TFS. VSTS already no longer supports them. So you need to Migrate from XAML builds to new builds (vNext builds). Also this similar thread for your reference : Converting TFS XAML Build Custom Activities into TFS 2015 Build Tasks
Marketplace
While you can make use of custom build tasks with XAML build there is
no centralized or integrated solution for browsing available tasks,
installing them or managing them. With the new builds you can make use
of the quickly-growing Visual Studio Team Services Marketplace. Here,
you can search and browse the many extensions currently available in
the Marketplace.
See WHY SHOULD I LEAVE XAML BUILDS for details.
So, you can find the existing extensions in Marketplace and install them to extend the build process (add correspinding tasks). You can also custom your own extension based on your specific requirements. See Extensions overview.
You can build custom applications or services that integrate with your
Visual Studio Team Services (VSTS) and Team Foundation Server (TFS)
accounts by using the REST APIs to make direct HTTP calls, or
utilize our .NET Client Libraries.
Source here : Integrating with VSTS and Team Foundation Server
To add a custom task you can reference below articles:
Add a build task
Reference for creating custom build tasks within extensions
Developing a Custom Build vNext Task
For the "outputs" validation, you can try it with build alerts.
we have our business apps and size is 64 MB. every time add new functionality or change existing one then we rebuild our setup and deliver to client. so this means every time we are delivering 64 MB or more than that to our client.
we have our main win form project and also there many other class library project in our project solution. i am looking for easy way out to deliver only changes to our client.
may be changes could be there in our win form project or could be there in any class library.
so wherever changes made i just only deliver changes through setup and i want just client would install that setup or run any exe file and could see the changes we made in code.
i create setup with VS2005 setup creation option. how suggest me the best option for creating patch like apps which any client just install and get the changes in his apps. give me the best idea to implement in detail. thanks
When using Wix to generate an installer for your project, you can use it to also generate a patch file which will update only changed files.
Visual Studio 2005 setup projects don't really support Patch building and such. It's meant as a rudimentary solution for building installers. Wix, however, is what Microsoft uses internally to build the setup experience for Visual Studio 2012 and other products. There is a very extensive walk-through available here.
Wix does come with a steep learning curve. Would you have been using Visual Studio 2010 or 2012, then you could take advantage of a couple of templates that make it much easier to build a setup for a given type of application. I don't believe these will work with Visual Studio 2005.
This book might also guide you.
Our main website is a collection of 10 separate ASP.NET projects and applications. At the moment, to do a complete deployment onto a fresh server involves running ten separate msdeploy jobs; each application is built, configured (using config transforms) and packaged, but we don't have any solution for deploying all the packages as a single operation.
I can see several possibilities that might work in this scenario, but would love to hear from anybody who has succeeded - or failed - in setting up something similar:
A folder full of packages and deploy.cmd scripts, with a "master script" that will call each individual app script in turn and deploy that app to the target server.
Using a staging server where we deploy the latest build of each package from TeamCity using the production configuration, but then use msdeploy to capture that server into a single enormous msdeploy ZIP package, which is then deployed onto each production server as a single msdeploy step.
Creating a single, enormous Visual Studio solution that references EVERY project in our codebase (perhaps via svn:externals?), compiles and cross-references them ALL, and hence supports using a single msbuild job to create a huge monolithic package containing our entire codebase, built from the latest revision in source control and configured for the target environment.
I've studied Troy Hunt's excellent "You're Deploying it Wrong" series, and Scott Hanselman's "Web Deployment Made Awesome" article, but I think I'm looking for something a step beyond either of these approaches that incorporates multiple projects and applications without necessarily building them from source in a single step - any ideas?
We had a very similar scenario in our company, and we created an installation package using WIX. Our config transform happens at installation time, so now we create a single build, then deploy that to each server via an MSI install package. WIX is very flexible, but also has a steep learning curve. We modify our configs using our own custom action, but it could be done other ways.
We use Team Foundation Server and MSBuild to do our builds. This is pretty straight forward, but did take some work to set up correctly with as many projects and solutions as we had.
Other options we looked into, and even tried were:
InstallShield - Not flexible enough.
Writing our own C# Install - WIX already thought of everything we
were trying to accomplish so why reinvent the wheel?
Just saying to heck with it all and installing things manually - 2 or
3 months of development time in WIX and MSBuild have easily paid for
the hours we would have spent of the last year doing things manually.
I think the deployment tools built into Visual Studio were designed for a single application with just a few deployments. It sounds like you need external tools, and development effort, to get your deployments quicker, and eliminate the need for doing things manually. That's why we invested in the above solution, and it has really paid off.
I'll pick Installshield.
Installshield latest versions support creating webdeploy packages.
You can define the IIS configurations for all apps in a single project and create releases if you want to create packages by separate or one single release for all web apps.
Installshield project has an object model where you can automate basically every task from build scripts, also the projects are simple xml files that you can also modify in automation scripts if required
Developers can modify update WixXML projects by separate and you can add those projects builds as merge modules to your installshield projects through your build scripts with some little tweaks to the installshield project xml (at least in 2011 version, this part is not supported by installshield but can be done)
You don't even need to modify Visual Studio Projects for groups of web apps that follow a same pattern, neither manually modify your installshield project to add new web apps for these cases, you can create packages for new web apps without intervention setting one time your build scripts for the installshield project automation task based on the root VS build output
During .NET v1 days, I have tried without much success to convince colleagues to develop test-driven and automated-build work habits using the additional tools of NUnit and NAnt. When .NET Framework 2.0 and Visual Studio 2005 Team Suite came into picture, I was able to "force" my team into writing tests and provide themselves with visual testing right inside Visual Studio. I was further able to tweak project files with extra MSBuild tasks to carry out more build automation.
Of course this does not mean Microsoft has delivered perfect systems, but I believe they have taken these in the correct steps forward. With all these features baked right into the framework and products and becoming "native" it got abit easier to motion developers into better development practices.
Having long forgotten the open-source options (which I do miss), I am wondering what value proposition do the current incarnations of NUnit and NAnt hold? What case can one argue at this stage to convince a team not to use MSBuild or MSTest?
Clarification:
My company is a pure Microsoft SI. Visual Studio Team Suite editions, Database Professional edition, TFS, and the like are available for our use. We do not use Visual Studio Professional edition or lesser.
MSBuild is a pretty good build tool. I've used it in combination with NAnt and Cruisecontrol.Net a couple of times. NAnt together with the NAnt contrib extensions seems a bit more flexible in handling OSS tools like NUnit, NCover etc while the fact that MSBuild can build VS solutions is a big plus for it. I found the easiest way to create build scripts is to use both, NAnt to call the different parts of the build (build, fxcop, test, coverage etc) and MSBuild to do the actual building.
I haven't got much good to say about MSTest. It's slow and cumbersome to install on for example a build server. It's not very flexible and has all kinds of 'extras' that seem more geared to integration testing than unit testing. I found light weight XUnit.Net, MBUnit or NUnit to be far better suited for unit testing. Speed is important here, you want to run the tests often for quick feedback on the effects of your changes in code. Portability is important too. You want to have the tests run everywhere without a lot of setup and hacking like you need for MSTest on a machine that doesn't have team system installed. Although Unit testing isn't new there's still a lot of development going on there. Best practices change a lot and so do the tools. I don't want to be tied to a tool that only gets upgraded every few years with visual studio. Every one of the three OSS .net unit testing tools is set up to be extensible. MSTest isn't (as far as i've seen).
In my view NUnit is the de facto standard for unit tests in .NET. It's free and you can easily write tests in any edition of Visual Studio. If MS had made MS Test available in VS 2005 Pro (as they have in VS 2008 Pro), it might have taken over by now - but I think it's too late.
I view ReSharper as basically essential for Visual Studio, and that includes a great test runner which works very well with NUnit. If I'm developing an open source project, why would I want to require VS 2008 Pro or VS 2005 Team Suite?
MSBuild vs NAnt is slightly different, as MSBuild is bundled with either the framework or the SDK (I can't remember which now) - but I think NAnt is a more pleasant environment to work in. MSBuild is clearly better for doing the raw "build the solution" bit - but you can invoke it from NAnt.