Pre-requisite license of True DBGrid DLL compilation stops VSTS auto build - azure-devops

we are using True DBGrid in our .NET project. This requires a first time registration while we perform build of the project. When we build from Visual Studio (v2015) it asks through a popup for the license key first time then performs the build. Next onwards it somehow understand this registration and perform build without asking again. This procedure works fine in on-prem Visual Studio.
But currently we are trying to move our solution to VSTS cloud. And this pre-requisite license of True DBGrid stops our build pipeline, since neither we can procedure the popup during auto-build nor we can let VSTS cloud server know about that license key. Can you advice how we can successfully let VSTS server know about the license of this 3rd party True DBGrid component?
I believe when we run it from on-prem Visual Studio the license successfully register the True DBGrid component into our local server. But this simply we can not do in VSTS cloud server. Can you please help us to solve this problem and adopt VSTS DevOps feature successfully? Thanks, Dimitry.

There isn’t ComponentOne products installed on Hosted agent and base on componentone-licensing document, it needs administrative rights to call CILicenseActivation.exe tool to register license, so you can’t do it on Hosted build agent.
You can setup a private build agent and running as your account. Deploy an agent on Windows

Related

Possible to Build With Imported COM Objects?

We have an application that utilises a third-party COM object (provided by a very well known finance/accounting software company).
In order to build this using VS on a dev machine yo must run tlbimport.
Is it possible to building this using DevOps builds on a MS hosted server, or do we need a self-hosted build server with the tlb file imported??
The tlb import tool is automatically installed with Visual Studio. You can refer to this official document.
Microsoft-hosted agent includes Hosted VS2017, HostedVS2019, etc. So I think you can build
this using DevOps builds on a MS hosted server.

What is actual TFS 2018 Build server configuration ? If i complete agent installation will that be considered as build server?

I have installed TFS 2018 and I'm trying to setup dedicated build server for this.
I have three windows servers one for TFS-WindowsBox1(TFS 2018 Installation completed), one for Build server-WindowsBox2(Build server setup steps and architecture needed), DB-WindowsBox3(DB Installation completed).
I'm looking for build server setup on WindowsBox2 and I'm looking best practices or steps to follow.
In administration section, I'm seeing agent download option in agent pools tab.
If i download and install agent on windowsbox2 server , will that be considered as Build server.
And what are the differences between agents and build server setup ?
TFS has no concept of a "build server". If an agent is configured on a box and the agent is running, then that box can run builds (and releases, since the release agent is the same piece of software). That's all there is to it. Build agents are assigned to agent pools, which dictate the set of available agents.
In previous iterations of the build system (XAML build, TFS 2010 - TFS 2013, although it's configurable up to TFS 2018), you had to register build controller and assign build agents to the build controller. XAML build is deprecated and should not be used except in the cases of pre-existing legacy builds, so if you're not already using XAML build, you can safely ignore this paragraph.
You can refer to this article (Deploy an agent on Windows) to setup TFS build/release agent, after that this is your "build server".
There are interactive and service mode and by default it is running in interactive mode, for this mode, you need to call run.cmd (in the same folder of config.cmd) to start agent, then the agent state will be online.
With service mode, you can check whether the corresponding service is running or not in Services.

Deploy + desktop application + TFS 2017

I have a winForm application. I want to install it on the server every time the CI/CD happens. Later, after I install it(i don't know how to automate installation as well.), I want to run UI tests on it. What task should I add to my release management?
I only found web deployment when I researched. Since, mine is a desktop application, I need different build/release task. I could do it from vs2017(by right click project + publish)
I want similar one from TFS 2017.
You can try to build with the publish profile. See Publish profile.
In TFS using VS Build step with the MSBuild Arguments something like below:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(Build.StagingDirectory)\\" /p:PublishProfile="YourPbulishProfile"
You can reference this article : Using Web Deploy in Visual Studio Team Services Release Management
To run coded UI tests from TFS.
Firstly, you need to run your agent as an interactive process. Regarding how to deploy an agent on windows, please refer to this link.
Secondly, add your coded UI tests project into TFS version control.
Last, create a build definition to use Visual Studio Test Agent Deployment task and Run Functional Tests task to run the tests.
Reference below articles:
Continuous integration, test, and deployment tutorial
Deploy a Desktop App from TFS to VM for Coded UI Test.
I found a way to publish my desktop application on to the server. below is the article which explains the build tasks needed.
Click here

Visual Studio Team Services Build Queue Not Appearing in List

I'm setting up a build definition in Visual Studio Team Services using a Build Agent installed on my local machine for testing.
I'm following these instructions for creating a build agent, setting up a build definition, and queuing a build. I've created the agent on my local computer and it appears in the agent pool in VSTS. The agent is enabled and ready to go. I've also created a build definition that invokes my build script. Everything up to this point appears to work fine.
At this point I'm ready to queue a build and run it. The dialog for this looks like:
The dropdown labeled "Queue" only shows the Hosted agent pool. There should be a second pool called Default but it is not appearing. I can get it to "appear" by right clicking and inspecting the HTML and then using dev tools to change the value for the Hosted option. Hosted's ID is 2, I changed it to 1 since I assumed this to be the ID for Default. Once I do this I can click "OK" and the build runs as expected -- everything is checked out on my local machine by the build agent. Presumably my assumption about the ID value is correct.
So...everything it working correctly once I muck around with the plumbing a bit. But this is definitely not the way things should be working. Why is the Default queue not showing up in the dropdown? Do I need to flip a switch somewhere to make it work? Does my account not have enough access?
Some other details:
My account is a "Pool Administrator"
The build agent is not installed as a Windows service. I start it manually from a command prompt. I've not been able to install it as a service.
The machine that has the build agent installed on it is running Windows 10 x64 Pro. It was upgraded from Windows 8 x64 Pro.
I cannot use a hosted agent as I'm building a Unity project and Unity is not supported by for hosted agents.
I know I can use Unity Cloud Build but I do not want to.
UPDATE
I've removed my previous Build Agent and installed a new one, as a service, on a Windows Azure VM running Windows 10 Enterprise x64. With this change the "Hosted" and "Default" queues are appearing as expected.
Your account needs to also have access to the agent queue. Agent pools and agent queues are different entities, and being a "pool administration" does not necessarily mean you are a "queue administrator".
In my case it helped to execute the agent configuration in a console with elevated/administrator rights. If the agent configuration is done in a console with normal rights, the agent can still be configured properly, but its queue won't appear for selection when you will be queuing a new build.

Deploy web applications and windows services using TFS 2010

Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent