I’ve been reading some articles (this one in particular: http://speaksql.wordpress.com/2013/06/07/a-journey-to-db-deployment-automaton-ssis-build-using-msbuild/) about using msbuild.exe to build and deploy an SSIS package (.ispac). I had no problem with that from my computer which has all the required assemblies, and only using the msbuild.exe command.
Once I tried to use the TFS Build Server I had some problems. First I realized that using a project with msbuild.exe (SSIS.MSBuild.proj) was not recommended with TFS 2013 since it was used with TFS 2008 and 2010. Anyway, I just wanted to make it work and it sounded plausible, but I had to use the TFSBuild.proj. That was not a problem, but my next problem was that the project I was being using (Microsoft SQL Server Community Samples: Integration Services) references a SQL Server assembly (Microsoft.SqlServer.ManagedDTS) which is not installed on my build server.
Then I realized that even if I managed to install that assembly on the gac, or referenced it on a relative path I would have a bigger problem next, I am using custom activities on my packages which I need to install using gacutil.exe on the host server, and I was wondering how to install, remotely, those dll.
That’s when I started to lose faith, and here I am, is there an “easy” way to implement continuous integration for SSIS packages without installing third party tools (http://remotegacutil.codeplex.com/ for example), and adding missing assemblies to the gac of a build server?
Did any of you have a similar issue? Did you solve it? How?
Thanks!
Use devenv.exe to build the ispac. Add an invoke process task and call out to devenv.
Add an Invoke Process to the Build Template, the one above shows a Sequence container, which assigns the path to the correct version of DeVenv to call, VS2010 /12 /13 etc. this is shown as hard coded but can be put into an argument, so it can be populated in individual build definitions. the one you can't see clearly is "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.com"
Next is the invoke Process, this call out to the specified devenv.exe and passes arguments used to build the ISPAC file.
The arguments are passed in localProject would get you the actual project you wanted to build in previous versions, you may have to do something different for 2013, due to the changes to the new templates.
this gives a TFS2012 way of doing it, as i say you may have to do something different to get the project that you want to build under 2013, but the build will run and an .ISPAC file will be generated.
at this point i would deploy the ISPAC using powershell, you may want to add additional scripts to the powershell calls to handle creating the SSIS Catalog and scheduling of the job.
deploying with Powershell can be found here Deploying ISPAC's with Powershell
Related
I have a build definition in Visual Studio Team Services (a.k.a. Visual Studio Online? I'm not really sure the right name for it honestly) that is not producing an artifact, and I'm really not sure why. The main project in the solution file is a Windows service that is built using TopShelf. I suspect that maybe the MSBuild arguments in the Visual Studio Build task might be wrong. I copied them from a build definition for an MVC project that is working, but it occurs to me that they might not work for a Windows service.
Here they are:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\\"
I have a Copy Files task and a Publish Build Artifacts task later on in the process, but apparently the $(build.artifactstagingdirectory)\\ is empty. I get this warning:
##[warning]Directory 'd:\a\1\a' is empty. Nothing will be added to build artifact
Oddly enough, in another task in the process where I publish the symbols, everything appears to go off without a hitch.
One more bit: I'm using a hosted build agent. Not sure if that matters or not.
That's all of the pertinent information I can think to provide. Am I way off base here? I've used Octopus Deploy in the past and I know I had to install Octopack on my services. Do I need to do something similar here?
You don't need any of those MSbuild arguments; most of them apply to ASP .NET projects and will do nothing for a console application.
Replace them all with /p:OutDir=$(Build.ArtifactStagingDirectory). That will tell MSBuild to put the build outputs in the artifact staging directory.
I have a console application that I am building on a on-premises tfs 2015 with a Visual Studio Build. What I want to achieve is:
If the application is executed on a dev machine during normal development there will be a simple message "Hello Developer" and if it was deployed in a qa environment and the tester runs it from there it should print "Hello Tester". Just a simple demo.
So I think I need an App.config to be able to store a configuration that will than be changed during the build process. I was confident that this is a no brainer as I found a lot of websites describing something like this but it turns out, that they all are not revealing the interesting bits like
How does the App.config needs to look like?
How is the variable used in C# code?
What are the needed settings in the Release Management Client?
What are the needed settings in the on-premises TFS Build Definition?
or were out-dated (TFS 2013 (1), RM Client 2013 (2)) or were using Visual Studio Online/ Team Services or were using custom tasks.
Can someone explain me, how to achieve the described scenario "Hello Developer"/ "Hello Tester"?
Thanks a lot!
We use MSDeploy for this type of setup. You can extend MSBuild by adding an Import line in your csproj file to a new .targets file in your project. Reference the MSDeploy task and use that to create a MSDeploy package for your console app. Finally create Parameterization files to define the config section you want to transform and SetParameters files for each environment with the appropriate message.
This blog post is for a database project but the basics steps are the same.
Within RM you would use MSDeploy to deploy the package with the appropriate SetParmeter file against the target server via a PowerShell command.
Have you tried with SlowCheetah?
This package allows you to automatically transform your app.config (or
any file) when you press F5 in Visual Studio. You can have different
transformations based on the build configuration. This will enable you
to easily have different app settings, connection strings, etc for
Debug versus Release. If you want to transform other files you can do
that too.
Not too sure if what I'm asking here is possible, or if it requires an upgrade. My problem is that I have a local install of TFS 2013 (that is, on-premises), and all dev machines have now upgraded to VS2015. However, when using new features (such as $"test {teststring}"), we get build errors.
The build machine has both VS2013 and VS2015 installed, and is using the default build template (TfvcTemplate.12.xaml). Looking at the "Run MSBuild" task inside the build workflow, there doesn't seem to be any way to point it to one MSBuild or another.
Is it possible to hint to the build to use the later version of VS / MSBuild and, if so, how?
Try adding /tv:14 to the msbuild commandline arguments in your build template, if that doesn't work, edit the xaml file for your build process template and override the "ToolPath" property of the "Run MsBuild for Project" task. Or make that field configurable through further customization of the build template.
Set that path to C:\Program Files (x86)\MSBuild\14.0\Bin (or your equivalend location in case your machine uses alternate default directory names).
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.