Recently moved project to tfs preview and having trouble with software licenses installed on local dev boxes building correctly but on on tfs preview.
TFS fails the build saying it can't access registry due to those dll's that require installation. When removing the license contents from the .licx file tfs builds ok but the resulting drop and install issues a warning due to the license not being imbedded in the .exe.
Is there a way to install 3rd party licenses on tfs preview or is there another work around I am missing?
I'm going to assume you're using the hosted build controller. If so, you can't install software on those machines as they use standard base images and are reset after each build.
Any builds where you want/need custom software installed are best done using your own build server, either with an on premise machine or an IAAS VM in Azure.
For reference the software included on the hosted build servers is listed here.
Related
I have build a UWP application using Sqlite. On my local machine I had to install the following SQLite for Universal Windows Platform Visual Studio Extension to get it to build. I followed this blog when using sqlite on UWP
I am now trying to implement Continuous integration with Visual Studio Team Services (was Team Foundation Server Online).
I am using a Hosted pool to build my application but I get the following message:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5):
error MSB3774: Could not find SDK "SQLite.UWP.2015, Version=3.12.2".
and it breaks the build.
How can I fix this on a hosted pool? I do not have physical access to the machine as this is managed by TFS online
EDIT:
After finding this is a library that is installed on my local machine (through the Visual Studio Extension) and so doesnt exist on my hosted machine meaning the reference is broken I am trying to add the respective files to source control and reference it directly from source control. But I have no idea what dll it is actually referencing as it doesnt say. The properties of the reference are as follows:
Actually there is a simple solution that has worked perfectly for us:
Copy the Microsoft SDKs folder to your repo (or submodule).
Add this to the end of your csproj file:
<PropertyGroup>
<SDKReferenceDirectoryRoot>$(MSBuildProjectDirectory)\..\..\..\..\Microsoft SDKs;$(SDKReferenceDirectoryRoot)</SDKReferenceDirectoryRoot>
</PropertyGroup>
From now on the build process will first check this directory for the required extensions and then fallback to the locally installed extensions. This works perfectly on VSTS hosted agents and doesn't require you to install all the extensions on every dev machine.
There isn't any way to install the extension on Hosted Build Agent.
Q: Does your build depend on software other than this software that is
installed on hosted build resources?
A: No. Then you can use the hosted pool.
Here is the software installed on Hosted Build Agent: Software on the hosted build server.
The work around is deploy your own build agent. With this build agent, you can install the software you want to build your project.
You can not install extra extension in a Hosted VSTS. I tried with TS support and there is no way to do it right now.
You can use difference CI service like Appveyor with give you some control over installing extension via powershell.
Or you can wait for Windows 10 Anniversary with include Sqlite.
Download SQLite for Universal Windows Platform SDK from here
Install it by double clicking.
This solved same issue with my UWP project.
I am developing a Sitecore solution locally using TDS. Our source control and build server is Visual Studio Team Services (in the cloud). I would like to figure out a way to implement Continuous Integration and get builds to be automatically installed on an Integration server that is an Amazon VM (or it could be some other externally located server). I have the TDS build configuration set up to create a Sitecore Update Package. The build process works great. At the end of the build process I have the Sitecore Update Package sitting in a Drops folder in source control (TFS in the cloud). Now I can't figure out how to automate the process of getting that update package out of source control and downloading it to the Integration server and running the Sitecore command to install it.
In a perfect world you would use something along the lines of a fancy Microsoft Release Management to deploy it to the environment of choice. However, if you are like the majority of us mere mortals without the fancy tools - this should help: https://github.com/adoprog/Sitecore-Deployment-Helpers
With these pages you could just send a get request from TFS or use the logic to write a custom PowerShell post-build script. Hope this helps!
As you are using TFS you get to use Release Management for Visual Studio out of the box. This is a simple install but at this time is separate. I have an instance of RM running in a VM and attached to my VSO instance for running deployments.
I would expect this tool, which was bought by MS last year, would become more integrated in vNext.
I am trying to get the most basic configuration of TFS 2012 up and running.
So far I installed the TFS server using the simplest option (the 1st option in the installer - the one that comes with a bundled SQL express),
I configured the build service (1 controller, 1 agent, both on the TFS machine).
My project consists of 2 parts: a C#/silverlight part, and a C++ part.
After adding the silverlight prerequisites the C# project builds correctly.
However I can't get the C++ project to build.
I guess I am missing a prerequisite since I am getting the following errors:
C:\Builds\1\proj1\Client\src\Code\Client\proj\main (VC11).vcxproj
(19): The imported project "C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\v110\Microsoft.Cpp.Default.props" was
not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
Indeed, the TFS server does not have a "C:\Program Files (x86)\MSBuild\Microsoft.Cpp" folder (while my dev machine has one).
I installed the windows SDK, but that didn't help.
I saw on some posts that I need to install VS 2012 on the build machine. Is that correct? will VS express do?
I have been banging my head on this for the last 2 days, and any help would be appreciated.
Installing Visual Studio on your build server seems like a strange thing to do, but having been around the TFS block a bit, I have found it to be the simplest way to manage build servers.
You can copy the files manually from your dev machine to your build server, but if an update to visual studio comes out, you will need to figure out what has changed and make sure you update all those files too. These files typically include Targets files and associated dlls.
Also with all the extensions and packages that are available now, it is just easier to load Visual Studio on your build server and install the required packages than try to work out what is needed to replicate the functionality.
This was made very clear to me recently when Microsoft released ASP.Net and Web Tools 2012.2. This altered the publishing pipeline for Web Sites and Web Projects and I needed to use this in my TFS build. It was so much easier to just be able to log onto my build server, load Visual Studio and download the new update.
I would definitely support installing Visual Studio on your build server.
I want to create MSI build package as part of a TFS build.
What options there are?
i know about:
install VS on TFS server (http://geekswithblogs.net/jakob/archive/2010/05/14/building-visual-studio-setup-projects-with-tfs-2010-team-build.aspx)
Use 3rd party software on tfs
I do not wish to rely on 3rd party software or install vs 2010 on server as i have no licence to spare
Wix: http://wix.sourceforge.net/
It can be invoked using MsBuild.
I am using it quite successfully in one of my projects
This page gives some info on what is needed http://wix.sourceforge.net/manual-wix3/authoring_first_msbuild_project.htm
You should create the MSI Build package on TFS Build the same way you do it locally.
If you don't have anything yet, I strongly encourage you to look at Wix and use it. However Wix is mainly lowlevel package generation for MSI.
If you have complex needs for installation wizard you may rely on InstallShield to get the job done.
By using InstallShield (IS) you have two options:
Create a deployment project that will be 100% compatible with Windows Installer (the technology that builds .msi), no more no less. By doing that you can build your IS project pretty easily with Team Build.
Create a deployment project with the IS flavor (with a installation bootstrap) and you'll have to deploy the needed runtimes of IS in order to successfully build.
However I strongly encourage you to not choose the way you'll create your deployment package based on the Continous Integration constraints, if you have to install 3rd parties on your build agent, so be it, it won't be the toughest thing to do. (especially if those are VM you can clone)
We recently moved to Team Foundation Server 2008 from Source Safe. We are setting up some automated builds and have run into some issues with the publish of click once apps that seem to require additional installs on the build server.
I've seen posts that indicate that the Visual Studio IDE needs to be installed. I've also seen posts that say that installing the .Net Framework SDK would fix the issue. We don't want to install more than we need on the build server, but we also don't want to have to make multiple requests to our server team to install different pieces at different times. So, I'd like to know what most teams end up installing.
If it's important, we don't have a dedicated build server at this point. We are a small team (6 devs, all local). Builds are happening on our main TFS box, the SQL Server piece is the only part that is on a separate server.
If you are just compiling applications in with Team Foundation Build, then the .NET Framework will do - however as soon as you start wanting to do anything more advanced (such as running unit tests and having their results published into TFS) then you will need to bite the bullet and install a Visual Studio Team Edition on your build server. I usually just install a copy of Team Suite on the build server so that people who are licensed to use the various features can have those features run as part of any automated build.
Having to have it installed on your server is not ideal, but gives you the best experience at the present time.
Regarding using your TFS server as your build server, this is not recommended for larger teams because builds tend to be pretty CPU and IO intensive beasts - however for a small team such as yours and assuming that you don't have too many build definitions that could run at once you should be able to get away with it.
According to this, Visual Studio shouldn't be required--just the .NET Framework. One other note to consider from the link is that they recommend against builds happening on the TFS box.
Yes, I installed VS on the build server. I followed their manual for setting up TFS.