I am trying to introduce continuous integration in the Xamarin.iOS project. I am following the method that is mentioned on the Xamarin website which is given here
https://developer.xamarin.com/guides/cross-platform/ci/jenkins_walkthrough/#Configuring_the_MSBuild_Plugin .
This is the screenshot of what is expected from the process
The problem is that the http://localhost:8080/configure link does not shows the MS Build configuration part in which I need to put the path of the xbuild which is "/Library/Frameworks/Mono.framework/Commands/xbuild" .
I have checked the following things on the Mac:
MS Build has been installed in the jenkins
Xamarin.iOS has been installed.
I have restarted jenkins
I have checked whether the plugin is present in the the location that is mentioned in the application "/Users/username/.jenkins/"
Is there some other way to go about this continuous integration ?
I have used Jenkins_49.zip in order to install it on the Mac
It seems the Xamarin documentation contains an error there. The correct URL is /configureTools, not /configure, i. e. the menu item "Global Tool Configuration".
Maybe the link was correct in an earlier version of Jenkins?
Related
I'm attempting to setup an old project on a new computer using Rider with TFS. I'm already using TFS with the same repository on an old computer with Rider, however, I've noticed that on my new computer, TFS is no longer an option for version control. I have the plugin, I can go to version control under settings and view settings for TFS, but when I attempt to enable version control for the project, TFS is not an option. Similarly, I can't checkout from TFS.
Also, the settings screen for TFS is very different on my new computer's install, giving me only the options to delete and update configurations, but no way to add one (so I can't actually do anything). Any ideas about what's gone wrong here?
Have tested installing riderRS-171.4456.199.exe (Windows), the TFS Integration plugin has been bundled with Rider and enabled VCS-TFVC successfully. Seems you are using TFVC version control(check out), please follow below requirements:
You must have the TF command line tool installed to be able to
use TFVC features. The minimum version supported by the plugin is
14.0.3. To install the tool, download the latest "TEE-CLC-14...zip" file and extract it to a known location. After extracting the files,
you must accept the license agreement. To do so, open a Command
Prompt/Terminal window, navigate to the extracted directory, and run
tf eula. After reading the EULA, enter y enter code hereto accept
it. NOTE: If you forget to do this, the plugin may fail to load
with a RuntimeException.
For the tool to be detected by the plugin, you must set the location of the executable in the Settings/Preferences menu by following these instructions:
Go to RD Settings Version Control -TFVC
In the Path to tf executable text field, navigate to the location of
the tf executable.
Click Test to test that the executable has been found and is working
as expected.
Click Apply then OK to save and exit.
More details please refer this tutorial.
Also try to setup a new created project or select another project when you are using Rider with TFS. To narrow down if the issue is related to that special project.
I am trying to set up a TFS Build agent to build my Xamarin.Android project automatically on every check in.
I have followed the steps outlined here: https://msdn.microsoft.com/library/vs/alm/build/apps/xamarin for setting up a Hosted build agent.
TFS Build templates also have a Xamarin.Android template, which you would expect means they are ready to go. This is also backed up from the above link which states you can build a Xamarin.Android solution on a Hosted pool
But I keep getting the following error on building the project:
Missing Android NDK toolchains directory '\toolchains'. Please install
the Android NDK
I found a link at Xamarin https://developer.xamarin.com/guides/cross-platform/ci/configuring_tfs/tfs-and-xa/ which says I need to log onto the build machine and copy and paste the Android NDK onto my remote machine.
But obviously with a hosted pool I cannot log onto machine.
Am I missing something in my setup?
The original problem was about building a Xamarin Android App on an Azure DevOps hosted agent and having an error because the Android NDK can't be found.
Yes, the build will work if you disable options like EmbedAssembliesIntoApk or BundleAssemblies, but this is not a true solution, especially when you need those options to be enabled.
As the Android NDK path is not found when building on a hosted agent, the solution is to manually set the Android NDK path.
In the build task, in the MSBuild Options, provide the following Additional Argument:
VS2015 Hosted agent: /p:AndroidNdkDirectory="C:\java\androidsdk\android-ndk-r13b"
VS2017 Hosted agent: /p:AndroidNdkDirectory="$(latestAndroidNDKPath)"
If you want to know more about this issue I wrote an article that will give you more details:
Building a Xamarin Android App with Bundle assemblies into native code option enabled on an Azure Visual Studio Team Services (VSTS) hosted agent
(And getting the following error: "Error : Could not find a part of the path 'd:\platforms'."?)
How to retrieve the latest Android NDK on a VS2017 hosted agent:
$ndk_root = "C:\Microsoft\AndroidNDK64\"
if(Test-Path $ndk_root) {
$androidNDKs = Get-ChildItem -Path $ndk_root | Sort-Object -Property Name -Descending | Select-Object -First 1
$latestAndroidNDK = $androidNDKs.FullName;
Write-Host "##vso[task.setvariable variable=latestAndroidNDKPath]$latestAndroidNDK"
} else {
Write-Host "NDK is not installed at path $ndk_root"
exit 1
}
Write-Host Variable '$(latestAndroidNDKPath)' is $latestAndroidNDK
Step by Step guide to solving this issue.
If you can I would advise setting up your own build Host using Visual Studio 2015 Update 2 with Xamarin and this link. After doing so you can use this Xamarin link to make sure. 1. your java SDK and NDK are in a local (non user specific area, which if you installed using visual studio they should be) and the Enviroment variables have been added (from the Xamarin link):
Adjusting Environment Variables During the automated build process
Xamarin.Android will require access to the Android SDK and NDK at the
paths that were adjusted above. This is best done by setting ot
adjusting several server wide environment variables:
If not already, log in to the TFS machine as Administrator. Open
Control Panel, type Environment in the search box, select Edit the
system environment variables, and then click the Environment
Variables... button to bring up the following dialog:
Under System variables select ANDROID_HOME and click Edit…, or if
ANDROID_HOME doesn’t exist, click New… to create it:
Set the value to c:\android-sdk (or wherever you moved the SDK) and
click OK. Under System variables select ANDROID_NDK_PATH and click
Edit… (or New… if necessary):
Set the value to c:\android-ndk\android-ndk-r8d (or wherever you moved
the NDK) and click OK. Note that you do need the second folder name in
this value. Select the Path variable, click Edit… button, and append
;c:\android-sdk (or whatever folder you used) to the end of the path
and click OK. Don’t forget to include the semi-colon (;) separator
between this and previous entries.
Verify the changes by opening a command prompt, entering Set, and
examining the variables. The Team Foundation Server should now be able
to build Android apps in a team project.
after this you must set the following properties to False in your project.Android.csproj file.
open the file in notepad,
go to the Release configuration section
and set the following to false:
<AndroidUseSharedRuntime>False</AndroidUseSharedRuntime>
<EmbedAssembliesIntoApk>False</EmbedAssembliesIntoApk>
<BundleAssemblies>False</BundleAssemblies>
Your project will now build on a hosted pool!
Although I think this hides the real issue as setting these to true will build on your local build agent.
I think the microsoft hosted pool is missing the Android NDK enviroment variable as it doesnt show up in the capabilities in TFS
There is a same issue on Xamarin Forums, and following is the solution in it:
Fixed: As an update if anyone else having this problem when building
Release (that the NDK \toolchains is missing) it appears that mkbundle
is broken.
The root cause is that "MakeBundleNativeCodeExternal" is true for
release and false for Debug. Although this appears as a licensing
issue, my build agent has an Enterprise licence installed.
Disabling "MakeBundleNativeCodeExternal" in Release build by editing
the Android project in notepad, seach for 'BundleAssemblies' - and
change the 'True' under Release configuration section to ' False'
save, build Release, works.
Refer to this link for details: Missing Android NDK toolchains directory
I'm setting up a new build server using TFS 2015 and after I configured the agent, when I tried to queue a build I got this error:
No agent could be found with the following capabilities: msbuild, visualstudio, vstest
How can this be resolved?
Install Visual Studio on your build agent, then restart the build agent. Restarting the build agent will capture the added Capabilities.
Note: First of all, you can do all this with the community edition and TFS Express 2015 on your own server (for free up to five users) - so don't worry about needing to use the Visual Studio online version or paying for Visual Studio Professional.
It is very easy to misinterpret the error message provided and go off on a wild-goose chase trying to debug it.
Unfortunately the message itself is just badly worded and that's the real problem.
Here is what that error message really means:
"No agent could be found with the following capabilities: msbuild,
visualstudio, vstest.
In fact I didn't actually find ANY build agents configured for the selected build queue."
So you're thinking that doesn't apply to you because you just created a build agent?
Well, maybe you did, but here's what probably happened:
You created a new pool (for no reason other than you just thought you ought to).
You then created a queue under that pool.
You ran the PowerShell script to create an agent and you assumed it put it in the pool you just created....
But it didn't - it put it in the 'default' pool which you aren't even using...
Aha!
So here's what happens when you build:
You select a queue from the dropdown.
TFS tries to build by looking for the pool that corresponds to that queue and it doesn't find any agents AT ALL there, so you get a stupid useless red-herring error message.
When I finally realized what happened I just deleted my cutely named pool + queue and just reverted to using the default pool.
Next time I will try to pay more attention to this message during the PowerShell configuration:
Configure this agent against which agent pool? (default pool name is
'default')
You will have to create a queue under the pool, but then your agent should start working.
If you have a genuine with a certain capability being absent from your agent you can check what your agent supports via the 'capabilities' tab shown here. Of course msbuild, visualstudio and vstest are all here :-)
In my case, after installing MSBuild (https://www.visualstudio.com/downloads/, search for "Build Tools for Visual Studio 2017"), I just had to add the path to MSBuild to the PATH environment variable. The agent wasn't detecting MSBuild until I did that.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin
I did NOT have to install the full Visual Studio IDE. The selected answer for this question is just plain wrong...
By default, when using the new build system on VSO, it doesn't pick the hosted build option, which is how I ended up on this post in Stack Overflow. If you are used to using a VSO build server here's what you need to do:
Create a hosted build by going to the General tab and changing your Default Queue to hosted. More on the restrictions of that and how it works here: https://www.visualstudio.com/get-started/build/hosted-agent-pool
Add them as User-defined capabilities, e.g.:
visualstudio C:\Program Files\Microsoft Visual Studio\2022\Community
vstest C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I had initially installed the agent on a machine that did not have Visual Studio installed. However, after installing Visual Studio (and then Visual Studio Build Tools), restarting/recreating my agent, restarting my machine, etc., I could not get the agent to detect the new capabilities automatically, so I added them myself in Azure DevOps as User-defined capabilities.
I had this issue and it turned out being my release process had selected the "wrong" agent. Just edit the release and set the correct agent queue
I was using a Xcode build slave for building an Xcode project.
And the error message I ended up with in TFS 2015 was
"No agent could be found with the following capabilities: xcode"
I registered an OS X on-premise build slave.
In the "Register Agent" step, I named by build agent:
>> Register Agent:
Enter agent pool (press enter for default) > My-Xcode-Agent-Pool
So, I had to select the "My-Xcode-Agent-Pool" as Default queue in the build settings. Source: Microsoft-hosted agents
Although none of previous answers worked for me, the post by Simon_Weaver pointed me in the right direction.
He mentioned that vstest was in his list, but it wasn't in mine. I fixed it by adding a user-defined capability named "vstest" with the full path to vstest.console.exe under Visual Studio 2017.
What ended up working for me was to go to where I downloaded the agent and running:
./config.cmd remove then ./config.cmd to reinstall the agent from the command line inside the directory of my agent.
Download agent
per microsoft https://msdn.microsoft.com/en-us/ie/bb399135(v=vs.94)
You must install on the build agent the version of Visual Studio that your team uses on its dev machines. See Installing Visual Studio. You must also install any other software and components that are installed on your dev machines and that are required to build your app.
In my case, after installing MSBuild, restart all Azure services (in windows service) and it worked. No need to install full Visual Studio
You have to install the correspondent Visual Studio version on the build machine (where you have installed your agent). This will add the required tools and capabilities to the server.
Visual Studio is required, because it installs all the build targets required to build your projects.
After being installed, you have to restart the agent Windows service so that it refreshes the list of capabilities.
Since you are using the Visual Studio installation on the build machine to build, that installation doesn't count as an additional license.
General solution for TFS:
The common way of resolving most of the issues on the build server is to install Visual Studio & all dependent packages on your build server.
Alternative solution in case of using VSTS
When you choose where to build, use "Hosted"
and then the build will work.
The guide how to make it work may be found here: Deploy an agent on Windows for TFS 2015
Check the agent section which will contain information about capabilities.
Updated:
Once you have the list of capabilities in vsts(azuredevops)
you might need to install the desired software on your build agent machine.
PS Be aware, you might have to license your sw, if required.
Issue:
I am trying to automate the build and installation of DNN modules on a build server. We are currently using DNN 5.5 and TFS for source control and build automation. The TFS build works as expected (getting, compiling, building/copying DNN packages) but when executing the Install.aspx?mode=InstallResources URL we get the "Site is under construction". The event log for DNN does not reveal any information. If I log in to the build server using my Id or the build server id and run the this script, everything works as expected. It’s when the script is started from the scheduler that the DNN InstallResouces URL has issues. The build id used is an administrator on the build server. I have search the web for others doing the same but only found one that stated they wrote an exe utility that submits a HTTP request and parses the response for the success or fail of the resources. Is this the only option? Any other ideas?
I would recommend that you nit work with Instances of your software from build. It is a bad practice and you need many workarounds to get things going. I would recommend that you install Release Management which is specifically designed to do what you are asking. It just has better tooling and configuration options for this.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
I created a post on this not to long ago and you can get more info in Professional ALM with Visual Studio 2013 on building and configuring a release pipeline. This way you are deploying tested binaries and not creating untested new ones for future deployments.
Resolution: The issue was resolved by setting the correct permissions for the TFS build user to execute the DNN install resources. The script being executed needed to load the Windows user profile when the script was being executed.
I've been reading and experimenting for days. I bought the latest "Inside the Microsoft Build Engine - Using MSBUild and Team Foundation Build". I've been trying to figure things out by looking at the build targets.
I was quickly able to get a package to be built on the build server, but I want to be able to specify the installation folder, so it doesn't go into wwwroot. I read that I would have to switch the project over from using cassini to the local IIS server. Went through all of that.
The args I'm passing to msbuild through the definition:
/p:DeployOnBuild=true /p:DeployTarget=Package /p:MSDeployPublishMethod=InProc /p:CreatePackageOnPublish=True /p:MsDeployServiceUrl=localhost
I've got SO MANY questions, but I'll start simply. If anyone can provide guidance I'd be super thankful.
If the named application doesn't exist on the build server (which it shouldn't!) the package creation fails. If I add a shell app named accordingly the package is built.
Even if I hack my way past #1 when I try to deploy using Web.deploy.cmd, it fails:
Error: Using a 64-bit source and a 32-bit destination with provider appHostConfig is not supported.
Note that the build server is 64-bit and THIS target server (development) is 32-bit. I have the build configuration building against "any cpu". Oh, and I'm invoking the deployment FROM the 32-bit machine, so there's only the 32-bit msdeploy.exe available.
In the appropriate BuildDefinition under "Process", expand the "Advanced" section and set the value of "MSBuild Arguments" to "/p:DeployOnBuild=True".
That will make your WebDeploy Package built according to your settings in the project properties.
I write 2 articles about how to create Web Package and auto deploy it to a Web Server, I think it maybe useful for you.
Auto Deploy your Website for QA with Team Build click here
How to run remote deploy with MS Deploy? click here