We have some SSIS packages which we are trying to automate using TFS so that the packages will be picked from repository instead of local machine of developer and then those packages can be deployed to file system. I tried to build the SSIS package solution file using TFS but there is no output, might be because MSBuild cannot understand SSIS packages. Please let me know if you have any idea of how to deploy the SSIS packages from TFS repository to a file system. Well I can easily change the configuration and setup to one environment, but my need is that it has to happen through TFS.
I tried to configure my SSIS Project but I was unable to do so because I was using SQL Server 2008R2 and TFS was 2012. So, I was facing compatibility issue.
However! These links might help you automating your deployment.
Integration Services (SSIS) and Visual Studio Team Foundation Server
Automating SSIS Package deployement using TFS
Automating SSIS 2012 ‘Project’ Deployment
TFS vs SSIS project versioning
Many pardons for this Linkuish answer!
Related
I am looking for some more specific support details.
I have managed to persuade our management to use Artifactory.
We currently use the following, mostly for WinForms development. We have several dozen products we support.
Visual Studio 2015 Enterprise
TFS 2012 on Prem (working to persuade management to upgrade this soon)
NuGet 3.5. with Project.JSon
I am just not sure if Artifactory can support some of the older tools we use. I can't find any details on their website that are version specific. It just says it supports "TFS".
I read mention in some samples of Packages.config, but we got rid of those bad boys some time ago. Project.json is much better. Once we move to VS 2017 the project.json goes away too.
Does Artifactory support TFS 2012? Project.Json files?
Artifactory NuGet support is agnostic of how you manage your project, the only requirement is that your builds use supported clients (like the one integrated into VS). You can deploy and resolve your own packages or have Artifactory proxy a remote location (as long as it supports the NuGet API)
TFS support is provided by the MSBuild Artifactory Plugin which collects info from your build and also enables you to resolve dependencies via Artifactory, and deploy build artifacts.
If you are on TFS2012, it's still using XAML build. Which means you need to use MSBuild Artifactory Plugin.
The MSBuild Artifactory Plugin is installed as a "Project
Template" using Visual Studio as follows:
Under Tools, choose Extensions and Updates..., select the Visual Studio Gallery source under the Online section, and run a search for
"Artifactory".
Select Artifactory Template Package extension found, and click Install.
So, instead of TFS version limitation, it should be more related to VS version.
And according to the Artifactory Template Package in VisualStudio Marketplace, which including VS2015.
I am very new to Jenkins and sort of new to build .net application, but the guy left team so I have been assigned to do this. I have read tons of articles online about setting up Jenkins master, but little about slave configuration. The guy created a new slave and connect with Jenkins master successfully before he left. And he told me that slave is responsible for 1) downloading source code from TFS server and 2) building them.
now my issue is what do I need to install in the slave machine( windows system) to be able to perform that two tasks?
1) for downloading source code, do I need to install TFS client on slave ?
2) for building source code, do I need to install MSbuild or entire Visual studio ?
Thank you very much !
Assuming you installed a recent version of the Team Foundation Server Plugin, then no TFS Client is required (see https://github.com/jenkinsci/tfs-plugin#400-and-later-new).
Depending on what you are building, installing Visual Studio maybe required or not. In my experience, only a limited set of project types build with just MSBuild and without Visual Studio. There are hacks or supported tips but they work only in specific cases: YMMV.
The new Build Tools for Visual Studio 2017 RC are making this requirement a thing of the past: if you can migrate your code to Visual Studio 2017 you will be able to use them.
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'm trying to get our TFS server to build a solution with an azure project. To get up to speed fast, I installed the azure SDK 1.6 on the build server/agent. I only needs to build and not publish the project for the moment. But I get the error below.
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.6\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Both the development machine and the build agent is x64, but on the development machine the azure stuff was installed in to "programfiles (x86).
Now I really need an advice on how to get the build agent to build the project, do I really need to include some dll's in the project, or how do I best fix this?
Up and running. A quick and dirty installation of the azure sdk and azure tools for visual studio did the trick.
I'm trying to configure automated build of BizTalk 2009 projects using Team Foundation Server 2008.
We have a staging server which has BizTalk 2009 installed. I ran the Team Foundation Server Build Setup on this server, and it can build non-BizTalk projects OK. However, BizTalk projects fail to build. I suspected something was amiss when "Deployment" was not a valid build type! I tried copying various things over from a developer PC which has BizTalk and Visual Studio 2008 installed, but still couldn't get it to work.
I don't really want to install Visual Studio on the staging server, but without it the "Developer Tools and SDK" option in the BizTalk install is greyed out. I guess I need this in order for BizTalk projects to compile.
So, my question is can a BizTalk 2009 server be used as a TFS build agent to build BizTalk projects without having Visual Studio installed. If the answer is no, what's the smallest part of VS that can be installed to get this to work?
Randal van Splunteren answered on MSDN:
There is a BizTalk installable feature called 'Project Build Component' (under 'Additional Software'). You can select/unselect it during installation of BizTalk. . . . It allows for builds without Visual Studio.
Be aware that you can only build stuff. For generating MSI packages you will need a BizTalk server (remote or on the build server itself).