We want to run our unit tests on our TFS server. We are running the database, TFS and the build agent on the same machine.
We have set it up and it appears to work up to the point that MStest tries to publish the results to the TFS server.
We get the following error:
The "TestToolsTask" task is using "MSTest.exe" from ......
Invalid switch "/publish".
Invalid switch "/publishbuild".
Invalid switch "/teamproject".
Invalid switch "/platform".
Invalid switch "/flavor".
For switch syntax, type "MSTest /help"
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1.
We think that the reason why we are getting this is that we have installed the professional version of Visual Studio on the build server.
Question is: Do we have to install a Team System Edition of Visual Studio on the build server or will it work if we just install the TFS client?
Thanks
Shiraz
We did this and I am pretty sure you need to install a version of Visual Studio Team Edition in order to publish a test to TFS :(
Found this link that says the same thing.
I am not 100% sure on this, but I'm fairly certain you need to install the Team System Edition of Visual Studio.
The client is just that, client software. Including items such as Work Item Tracking, Source Code Control, etc ... What you're looking for is the server side of the functionality and that comes with the team system edition.
To publish unit test results from the build, then you need to install a Team Edition of Visual Studio - either the Developer or Test edition will do. MSTest.exe is available in other versions of Visual Studio however when you go to publish test results it will throw an error. IMHO, the way that licensing works is that you can install the team edition on the build server provided the people checking in code (such as test code) have licenses - however you'll want to check with your Microsoft representative.
Yes, you need to install (at minimum) the extra tools that come with VSTT (Team Test) or VSTS (Suite) editions. The basic ability to write & execute unit tests inside VS were moved down from VSTT -> Professional in the 2008 product editions, but the specific scenario around publishing tests on the server was not.
As a general rule MS developer tools are licensed per-user, not per-machine. 2008 adds a few exceptions to the rule when it comes to non-IT staff use of work item tracking, but for the most part it still holds. Complete details: VSTS 2008 licensing white paper
Well, you can go a bit hacky and adding some registry data everything works ... Reflector is your friend ... just in case it helps ...
Related
I'm hoping to get some assistance from you smart people!
I had my CI tool, TeamCity, compile solutions without a problem when VS 2015 was installed however I read from multiple sources that TeamCity does not need VS
Subsequently, I created an EC2 instance and installed JDK, MS BuildTools 2015, the Build Agent, and PsExec on my Build Server and connected it to the EC2 server housing the TeamCity client.
Unfortunately, it is giving off errors for a simple solution. -- http://imgur.com/M8sdDRs
I moved folders from my dev machine to the CI build agent server
Actually, you don't need to install Visual Studio 2010 or Visual Studio 2012 on your CI server. You only need to copy a few folders from a development machine to the same location on the CI server.
• C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web
• C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications
The problem is still persisting and I've come to a stand-still and frustrated with the problem.
THANKS SO MUCH!
If you're using the Visual Studio (sln) step runner type then you will need VS installed because that requires devenv.exe to build the solution. Unless you've got specific requirements for that, you should probably switch to using MSBuild as your build engine to remove the dependency on devenv.exe. Configure a build step of type MSBuild, point it at your solution and select Microsoft Build Tools 2015 / 14.0.
I doubt all your problems magically go away though, as you'll still need to stage bits of MSBuild like you've mentioned (WebApplications targets etc). I've had major hassles over the years trying to get a stateless, dependency 'free' agent build configured; Windows / .NET SDK is a can of worms.
Recommendation from TeamCity - Install VS on the CI Server to minimize the potential for errors. I installed the full Community Version, though VS Isolated Shell was fine as well, I wanted to minimize the room for error.
I ensured that: Administration > [Project] > Build Configuration Settings > Agents Requirements had MSBuildTools14.0_x86_Path existing and set my parameters to follow the following great resource - http://blog.anthonybaker.me/2013/04/how-to-automate-builds-with-teamcity_3119.html
I've carried out a lot of work here and want to be able to use my DTSX packages
But I get the version incompatibility and the Error message is specific
But there must be some way I can run my packages. They appear to not be able to be run from within VS2013 Pro editor
My question is, what do I need to install exactly to all allow me to execute these saved packages?
By asking here i can save time since there are many versions and many add ons etc
First - how to run a SSIS 2008 package?
There is a good overview here, by Ashish Kumar Mehta of MSSQTips, on how to execute packages both remotely on the server or locally. Either way you need the SQL Server Client Tools installed from the SQL Server media (CD, image, etc.). There's no possibility of running a package locally from Management Studio or raw Visual Studio. You can run the package remotely through Management Studio only if that package was stored within the SQL Server. Theoretically, you can run a package in development mode via VS2013, see below.
Second - how to modify a SSIS 2008 package?
Unlike subsequent SQL Server (and SSIS) versions, with 2008 you couldn't just use your regular Visual Studio with a downloadable plugin. You had to install one Business Intelligence Development Studio (BIDS), a Visual Studio 2008 derivative (i.e. not a plugin) available on your SQL Server media. That's the way to go if you want to edit the package but also maintain its 2008 version. Otherwise, you're free to upgrade the package to Integration Services 2014 level by several methods, and start hacking at it via Visual Studio 2013 with a downloadable Data Tools - Business Intelligence plug-in. Be advised, it's not possible to convert the package back to 2012 nor 2008 versions.
I have the following error on the build server for code that compiles and passes tests fine locally.
(150): The imported project
"C:\Program
Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path
in the declaration is
correct, and that the file exists on
disk.
I've added the WebApplications folder from my local machine to the appropriate path on the build server but I'm still getting the same error on build.
I believe the recommended approach with TFS2008 was to install VS2008 in it's entirety on the build server. Is this still the case with TFS2010 and VS2010 accordingly? a.k.a Sledgehammer to crack a nut.
Pretty much, especially if you plan on using other features like MSTest. You can try just adding the targets file but you'll probably still have some missing dependencies. You could go through the whole process of fixing the dependencies as you go along but it's probably easier just to install VS 2010 and be done with it.
This blog post seems to describe a way to do what you want without having to install additional software on the build server, if all you need is the .net compilers. It does not cover C++ compiler setup.
I discovered that if you're going to do just "standard" (i realize that's open to interpretation) web apps and non-web apps (e.g. services), you can get away with installing just Visual Studio 2010 Shell, plus Visual Studio 2010 SP1 on the build server. That will get you the missing .targets files.
Since a full VS install is required for advanced features, does anyone know if the build-server-install license cost is waived?
A lot of people new to CI (Continuous Integration) install VS (Visual Studio) on their CI server "because it is required to compile the code". MSTest is a common reference brought up here.
Why should I not install VS (or generally speaking, any software not out-of-the-box) on my CI server?
(This question has not been asked before apparently, so I'm adding it for reference. If it already exists, sorry, I missed it, please merge. If no answer is provided to this question within some time I can add one myself)
Because you don't need to. A Visual Studio license is pretty expensive, so having one just lying around on a server where no one's using it is just a waste.There are a couple of arguments why you would still need to install a full blown Visual Studio instance on your Continuous Integration server - but here are their counter arguments:
Reason 1: I need it to compile.
Reality: No, you don't. You need MSBuild to compile, but that is available for free, in the Windows SDK. Note that there are several versions for different operative systems and .NET versions, so be careful to download the correct one.
Reason 2: I need it to make quick fixes on the server.
Reality: No, you don't. You shouldn't make quick fixes on the server - you should check out from your version control system, make the fix, build and run tests locally until it works, check in, and have the CI system do the rest for you. That's why you have a CI system.
Reason 3: Without Visual Studio, I can't run MSTest no my CI server.
Reality: Wrong. AFAIK, the MSTest runner is also part of the SDK (at least that's what it seems like on our CI server here - although I can't verify it since we don't have any tests at the moment...). However, a quick googling found this blog post which explains how to do it without the SDK as well. I haven't read through it in detail, so I can't promise that it works, or that it's legal. You have been warned.
Feel free to add more reasons in comments, and I'll counter them.
You might need to install Visual Studio anyway, out of practicality
I was going to try and refute the accepted answer, posted by #TomasLycken, in the comments, but found I needed more space to talk. Even though I technically agree with what #TomasLycken has asserted, here, I'll list some of the dependencies that I found difficult to install on my CI server - and leave it to you to decide how right the accepted answer is...
1 - 'mshtml' primary interop assembly
You can see the problem I was getting in my build output at this S.O. question I created and answered. Mind you, I spent several hours figuring out how get the desired PIA registered - and it was a result of running some .exe's on the server that came from my V.Studio installation - hmmmmmm
CONTEXT: I had a win forms project that used the Web Browser control.. and in the 'WebDocumentCompleted' event, I was casting the DomDocument to hshtml.IHTMLDocument2 .. and that's why I had a reference to Microsoft.mshtml in my project.
RESULT: Now #TomasLycken suggests I deal with this by fixing my code. At first, I wanted to bawk at this suggestion. My code is deployed and working! But, when I do a web search, I see that Microsoft doesn't really recommend using their mshtml PIA outside of the Visual Studio environment they developed it for.
The offending 10 lines of code was effectively doing a little screen-scraping of data on behalf of our users who do research on technical topics in several well-known web portals. But, when I tested this code, written in 2009, it appears that the DOM it once manipulated has now changed in 2016. I know shocking. Probably not my smartest bit of code. Probably time to retire this function - in other words, fix the code and recommit it.
#TomasLyken I think is right on this one.
2 - Win Forms Project post-build script
CONTEXT: So I had come across this cool post-build technique on S.O. that allows my app.config file in my WinForms project to undergo an XDT transform similar to the way my web projects' web.config files are transformed. Well, it just works OOTB, so-to-speak, if you copy from S.O. and into the .csproj or .vbproj source file. But, once you put all this onto a build server with no Visual Studio, the critical piece fails due to a dependency on:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Now this is straightfoward enough to rectify.. I just copied over to the CI server my C:\Program Files (x86)\MSBuild\Microsoft directory. But, should I? Since I've kinda went off the reservation of what Visual Studio normally would support.. one could argue that #TomasLycken's accepted answer is still right on this point, too.
3 - Just getting all the .NET Frameworks and Multi-Targeting Packs in place
Points 1 and 2 above, were actually the last things I conquered in my attempt to get my first build job to run. And my first build job is for a solution stack that I've created and maintained over the past 8 years.. so it has weathered a few frameworks and would have some non-trivial texture to it. I knew it wouldn't be easy. In fact, I hoped by making a CI server that could build this .sln, that it would in fact be ready to build most any other solution we threw at it.
When I first received my clean "Windows 2012 R2" server, it simply had a lot of things missing.. and I'm wondering if I had installed Visual Studio first, if it would have rectified some of these things straight off?
Below is my synopsis of what I had to do - but it doesn't show the pain and suffering involved figuring it all out and the false starts. Maybe it'll help someone else, though.
> First, uninstalled 4.6.1 framework
-- (find Update for Microsoft Windows (KB3102467) and click Uninstall.)
-- also uninstalled anything from MS labeled with C++ redistributable (a later step will restore these)
> Then, install Windows 7 SDK (installs critical "reference assemblies" and a proper baseline 4.0 framework)
-- Then, install Multi-Targeting Pack for Framework 4.0.1 (netfx_401mtpack.exe)
-- Then, install Multi-Targeting Pack for Framework 4.0.3 (netfx_403mtpack.exe)
> Then, reinstalled 4.6.1 framework for 2012 R2 (KB3102467)
> Then, installed Microsoft .NET Framework 4.6.1 Developer Pack (DP461-DevPack-KB3105179-ENU.exe)
> Then, installed "Visual Studio 2015 Build Tools" (BuildTools_Full.exe)
> Downloaded a copy of nuget.exe and put it in the C:\Windows directory
4 - Getting rid of 'missing ruleset' warning MSB3884
From #kevinbosman's post on this GitHub issues thread
If you don't want to edit your Microsoft.CodeAnalysis.Targets file, please note that it is not enough to merely copy the folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server.
You also need to create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\Setup\EDev and add the string value StanDir = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\
5 - Getting MSTest to run correctly
Need dlls copied into your build machine, some must register w/GAC more info here specifically:
Microsoft.VisualStudio.QualityTools.Resource.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Need a hive out of your dev machine's registry copied into build server
some warnings, if you want them to go away, according to this Microsoft visual studio help forum require a VS 2010 and feature pack 2 installation.
I am thinkin about building my first TFS 2008 Build Server. However, I would like to use it with VS 2010 solutions targeting both .NET 3.5 and 4.0. Will this work and what should I watch out for?
Take a look at this post to get some insights on setting this up...
http://blogs.msdn.com/willbar/archive/2009/11/01/building-net-4-0-applications-using-team-build-2008.aspx
Also, take a look at the following. My build failed due to the change in workspace name. I deleted the existing workspace names and had the build process recreate them correctly...
https://connect.microsoft.com/VisualStudio/feedback/details/538958/deleteworkspacetask-fails-on-2008-build-machine-after-installing-visual-studio-2010-rc
Will VS2010 test results get integrated back into TFS2008 for reporting, if this approach is followed?