We are going to use Visual Studio Team Services for a project. We are using VSTS Git as our repository. A portion of this project is written in Golang. We want to enable CI and build/test all code at check in. I have been learning more about extensions, the build agents and build process within VSTS. I see in the marketplace there are options for Android, iOS and other platforms (but not GoLang). Can anyone start me on the path to creating a custom extension or build definition for Golang? How can I create a custom extension to enable automated builds at check-in of GoLang code? Thanks!
Yes but I would look at it a bit differently. There is no need to add anything to VSTS, you just need golang/the go compiler installed on your build agent and then you can set up a job using MSBuild like any other MSFT supported language which invokes the Go compiler with your sources. Basically, write an msbuild script who's sole job is to invoke the go compiler with the target sources.
Here are MSBuild docs on the Exec task which is what you'd use to kick off your build; https://msdn.microsoft.com/en-us/library/x8zx72cd.aspx
As far as I know in order to add the Go compiler you need to setup a private agent or install it on the fly using a build task like the tool installer
Related
is it possible to utilize my NSIS installer script to make an automated build (daily) for my program in TFS 2010? The program isnt C#, it's actually small talk, so the installer being designed in NSIS was prior to our group being required to migrate source control into TFS.
Essentially the installer just copy/pastes the directory and shortcuts onto destination PC, and runs a regedit for the new parameters. I noted in the TFS build tool (which I'm extremely unfamiliar with) that it constantly wants me to point at a .proj file.. Does this mean I've got to convert our NSIS scripts into some .NET equivalent (if so how?) or is there a plugin of some sort to allow these guys to play nice together?
If your project support MSBuild to build it, you can use TFS Team Build directly. If your project doesn’t support MSBuild to build it, you need to provide a compiler which can build your project, and this compiler support run the command line to invoke it, so we can add the InvokeProcess activity(execute the command line) to invoke that compiler to build your project in build process template.
Here are useful blogs for your reference:
http://donovanbrown.com/post/I-need-to-build-a-project-that-is-not-supported-by-MSBuild
http://blogs.objectsharp.com/post/2011/03/31/TFS-Build-Invoke-Process-Activity.aspx
I am building a cmake application using Visual studio 2017 which needs to build some part/some files on linux machine while some needs to be build on windows and for that I am using WSL.
Now point is, to build windows part I have target "x64-Debug" and for linux part target is "Linux-Debug" so my point is I want to build this both configuration in single build step.
Is there any way , i can use something like post build of cmake which will trigger second project build.
How to run post build step in cmake project.
Please help.
Thanks,
You cannot do what you are suggesting. You can try Cross Compiling. However, that comes with it's own set of headaches. Since you already have WSL, I think cross-compiling is not the way to go.
If you really want to automate the process, then you'll want to use a build automation server (e.g. Jenkins). If you have an open-source project, I would suggest using Travis-CI and Appveyor.
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
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.
I have some existing install shield 2009 projects and every time i want to create a newer version of them i perform some specific tasks that i want to automate with a script.
This are the operations that i have to perform manually
Change GUID
Point to the updated packages
Build single_exec_image
Is it possible to make this operations from CLI on installShield 2009?
Thank you in advance
InstallShield has an Automation Interface (32bit COM based). You can use this API to make programmatic changes to your installer project. InstallShield also supports command line builds using ISCmdBld.exe.
Typically you do all of this in the realm of build automation using MSBuild or NAnt. Both allow you to write custom tasks in c# that can interop to the COM automation interface.
For example I use TFS which uses MSbuild (which InstallShield has native support for via .isproj files ) to build my installer. In this scenario I can use dynamic properties in MSBuild to generate a GUID and I can use path variable overrides to point to your source. The build target then builds the installer.
A bunch of ways to skin this cat depending on your environment.