Error Calling GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer]) - powershell

Attempting to follow the example to access data on builds. I am doing this in PowerShell on the TFS Server being referenced. TFS 2015 Update 3 is installed. The server was stood up about 6 months ago with TFS 2015 Update 2 as the original version installed.
I have successfully loaded all assemblies mentioned, mostly via Add-Type but a couple using reflection.
Successfully created ProjectsCollection object and verified that it authenticated.
On this call:
$buildServer = $projectCollections.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
I get the following error:
Exception calling "GetService" with "1" argument(s): "TF214015: The build client object model does not support Team Foundation Server 2005 or Team Foundation Server 2008"
Does it think I'm running an old version of TFS and, if so, how is that possible when those versions have never been installed. Googling the TF214015 in the error finds only one unhelpful link.

When I experienced this (with TFS 2017 and assemblies even more up-to-date than freakydinde's out of date copies on GitHub) it was an error in the URI being passed in the construction of the TfsTeamProjectCollection. The URI was http://example.net/tfs/, rather than http://example.net/tfs/DefaultCollection/ which was of course the URI of the team project collection.
The same goes for calling TfsTeamProjectCollectionFactory.GetTeamProjectCollection() in the API.
Erroneously accusing us of using TFS 2005 or TFS 2008 is, it seems, Microsoft's rather odd spelling of "That is not the URI of a 2013+ team project collection." ☺

i'm the writer of the mentionned article.
i think you are loading old TFS assemblies, you should take the kit from GITHUB and use the Modules-TFS.psm1 and\or Assemblies folder provided, dll are from TFS2015.
https://github.com/freakydinde/Powershell/tree/master/tfsKit

Related

Cannot set up SAP NW RFC with Azure DevOps

In our solution we are interacting with SAP using the "Classic" API of the SAP RFC SDK.
We have hosted the application in Azure Services, hence not possible to place the librfc32.dll in the required path of C drive.
We have added the librfc32.dll in the solution and marked it Copy Always to the folder.
While we publish the solution locally and deploy using FTP in Azure Services, it works fine.
However when deployed using ADO pipeline, it gives the below error.
We have checked both published and ADO generated artifact and in both places the librfc32.dll is present fine.
Cannot call classic RFC API. See help for details. Please put a recent 64-bit version of librfc32.dll in your System32 folder (typically C:\Windows\System32). See SAP note 413708. Please make sure you have installed Visual C++ 2005 SP1 ATL Security Update (x64). An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Any suggestion?

Database first with EF6 SqlAnywhere provider in VS2017

Having already followed the advice in the SAP website documentation and installed the developer edition of SQLAnywhere 17, and also having manually run the installer for VS integration that is provided by this installation I still could not see any providers other than the MSSQL ones while creating an EF6 model in Visual Studio 2017.
I found this https://www.nuget.org/packages/Sap.Data.SQLAnywhere.EF6/17.0.7.3399
Does anyone know where to find documentation on how to use it? Nuget provides no links to documentation and does not list a repo.
I installed the package without incident and it appears in project references but it does not appear in the provider list when I try to create an EF model.
A request to the package author provoked this response:
Hi Peter,
For information and documentation go to:
https://sqlanywhere-forum.sap.com/
or with SyBase
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01776.1604/doc/html/san1357754863708.html
Kind Regards, Erwin Bakels
While I appreciate the prompt response, the documentation link leads to information about doing another thing with a different version -- it's for code-first with EF4.3 while the library is for EF6 and I need database-first. To be fair to Erwin, I didn't explicitly tell him I wanted database-first, but it's still not a usable answer.
Further research suggests that changes in VS2017 prevent the installer from registering the provider correctly. This implies that until such time as SAP updates the installer to suit VS2017 there is no possibility of designer support for EF with SQL Anywhere.
I have confirmed with SAP support, that Sql Anywhere ADO.NET integration with Visual Studio is not supported in VS2017. You will have to use VS2015 or earlier.
SAP DocCommentXchange
I suggest you download the SQL Anywhere, developer edition. You will get all the files necessary to use EF.

Red gate DLM Automation binding error using VSTS

I'm using Red gate DLM Automation version 2 on VSTS. I installed DLM on the build server, it's fully licensed, and I have noth the build and release VSTS plugins installed. But now, when I perform a build on VSTS, I receive the following error message:
System.Management.Automation.CmdletInvocationException: A parameter cannot be found that matches parameter name 'transactionIsolationLevel'. ---> System.Management.Automation.ParameterBindingException: A parameter cannot be found that matches parameter name 'transactionIsolationLevel'.
My initial guess is that I have a version conflict between some Red Gate PowerShell libraries, but I cannot find any further information on this error.The build server is running PowerShell v4. The SQL code being built does not have any references to "transaction isolation" in it, but I don't think that's the problem. I have completed successful builds on this VSTS server in the past and am now confused what caused this error to start appearing.
Thank you!
You need at least 2.0.3 of the DLMA install on the local agent to work with the VSTS plugin - we added the Transaction Isolation Level option very recently, and VSTS auto-updates, but the DLMA install doesn't.
Sorry about that - we are looking into better update / communication mechanisms to keep these things in sync in future (or at least tell you what the problem is) but aren't quite there yet.
If you're still having trouble after updating the DLMA install on the local agent, please do get in touch via support#red-gate.com and we'll sort it out for you.

TFS VSO REST API workitems (wit) paths give 404 errors

I recently discovered that TFS has a RESTFul API and I am trying to pull information about workitems based on the documentation here: Work Items
I've been able to get information about projects using this path:
[host]/tfs/TFS_DefaultCollection/_apis/projects
but when I try
[host]/tfs/TFS_DefaultCollection/_apis/wit/workitems
or
[host]/tfs/TFS_DefaultCollection/_apis/wit/workitems?version=1.0-preview
I get a 404 error. I've tried a bunch of things based on various examples but I've not yet gotten anything back for any URI under the /wit/ path.
This question has an answer that suggests that this feature may not yet be supported in on-premises installations. Has anyone gotten this to work? There's a blurb about how you can get a 404 if you don't have premissions on the main REST Basics page for TFS. Is there some authorization setting required or am I just going to have to wait for a later version? We are running 2013 (Version 12.0.31101.0)
You're getting a 404 because those particular APIs aren't in the on-premise TFS 2013 product. They APIs are available from TFS 2015 CTP1 onwards.

How to deploy ASP.NET MVC4 application with SQL Server CE to Azure website

I deployed a ASP.NET MVC4 app with SQL Server CE database, but I'm getting
Sorry, an error occurred while processing your request
I am using VS2012 to publish this app to azure website. How can I solve this issue? Thanks.
To summarize and so an answer can get marked on this to help the next person that comes by.
When running into issues on azure-web-sites FTP is a handy debugging tool which enables you to:
Verify that the dll exists in your bin directory
Sometimes the .gitignore file blocks directories from being checked in
Verify that your web.config file has the proper version of the assembly configured
NuGet can help, but it's ultimately up to you to verify your dependencies
Here is a good article to follow on the subject: http://www.dotnetcurry.com/showarticle.aspx?ID=883
Unfortunately with VS 2013 Compact edition is not supported any more, so things are somewhat tricky.