Microsoft TFS Build and Release Notes - Write-Host errors in PS Script

When developing out TFS 2015/2107 build and release definitions, it is good to log your steps when you queue out a build or release.  I write out to the logs when I'm using any of the PowerShell tasks ('Run a PowerShell script' or 'Execute PowerShell scripts on remote machine(s)', for example) in a build or release.


There is, however, a good and bad way to log in a PowerShell script in VSTFS 2015/2017.


In your PowerShell tasks, do NOT use Write-Host, as this will fail when you try to run a Build or Release. 

Instead, use Write-Verbose in the PS script and you will get the results you need.

BizTalk 2016 - WCF-Custom Transport: Unrecognized attribute 'ApplicationName'

Today I came across an error with the WCF-Custom Transport.

I have a send port that uses the WCF-Custom/sqlBinding type as a send port on my local dev machine.  Everything works as expected, so I exported the MSI and bindings to use on our Test environment.

When I imported the bindings file, I received an error: "Error loading properties. (System.Configuration.ConfigurationErrorsException) Unrecognized attribute 'ApplicationName'.

I compared the settings on my local dev to the Test environment and noticed some differences.  This screenshot is from our Test environment

and this is from my local dev environment

Notice the highlighted configurations don't exist in the other one.

This is because I have installed BizTalk 2016 Feature Pack 1 on my local machine, and the Test machine does not have this installed.

See https://docs.microsoft.com/en-us/biztalk/core/connect-to-sql-server-always-encrypted-columns-with-biztalk-server?redirectedfrom=MSDN.

Cannot delete a send handler that is used by a send port

We had a mislabeled Host/Host Instance name in one of our lower environments - it wasn't the same name as our production or qa environments, and a request was sent to rename it. So, a colleague performed the following:

1. Create a new Host and Host Instance with the desired name.  
2. Once that was done, add the Host to the appropriate adapter. For us it was adding it to the FILE adapter.
3. Then re-configure all appropriate send ports to use the new Host Instance.

Restart Host Instances, and the send ports were properly using the newly created Hosts.

Once that was done, the thought was that the old host could be deleted. We came across a few things (some are obvious, others aren't so):

1. You need to remove the Host Name from all adapters using the (old) Host you wish to remove:

At this point, an error popped up - "Cannot delete a send handler that is used by a send port":

The issue is that, although all the static send ports were updated to use the new Handler, the dynamic send ports weren't - this isn't as obvious. Here's how to do that:

1. In the BizTalk Admin Console, select Applications/All Artifacts/Send Ports
2. Sort by Transport Type. Here is where you will see some that don't have the Transport Type as blank. These are your Dynamic Ports.
3. For each Dynamic Port, open one up and, in the General tab, select 'Configure'.
4. You will see a list of Send Handlers associated to each Adapter. You will need to make your changes in this list according to how you made your changes with your static Ports.

Once these changes are made throughout, you should be able to now remove the Handler completely, and thereby able to remove Host Instances, then the Host itself.

Further explanation here by the-one-and-only Saravana Kumar:

https://blogs.biztalk360.com/can-you-use-dynamic-send-port-without-orchestration-yes-you-can/

The "Behind the Scene" section was the eureka! moment for me. 







FYI - This was tested in BizTalk 2016.  I don't believe you can navigate the same way in BizTalk 2010.

TFS Build Error - works in Command Prompt, doesn't work in TFS Build Definition

I've been getting into TFS Builds lately (using VNext, Wix, etc - not XAML).  In particular, I'm using TFS 2015, which I installed to a local VM.

I was able to successfully build a project off a DOS prompt (it's now called the "Developer Command Prompt" in more modern Windows Servers... ☺) using the MSBuild.exe command.  However I was not able to get a successful build when using the MSBuild step.  I even went a little further and decided to use the Command Line step in the definition and typed in the exact same command line that I used off the dos prompt above.  Even that didn't work.

The errors I kept on seeing in the log files were ambiguous to me - a whole bunch of ICE and LGHT errors.  Almost all of them referred to an "incorrectly registered scripting engine":

The errors didn't make much sense to me.  So instead of getting too focused on the error messages, I took a step back and reviewed what is going on: I was using the same exact command line - one using via the local server Command Prompt (success), and the other being called within TFS Build Command Line step (fail).


Conclusion:  permissions


I talked with a co-worker about this (he is a bit more seasoned with TFS Builds) and one of the first question he asked was: "How is your Agent set up?"

Looking at a few things we (he) figured it out.  My settings.json file in the appropriate agent folder was not properly set up.  In particular, the "WindowsServiceName" setting was blank.  I *think* that if it's blank, it uses 'Local Service' or something like that.  Either way, it's not a best practice.

I reconfigured the agent to use the appropriate service.  I reviewed the updated configuration to make sure that the setting was now populated.  After that my MSBuild step was running without a hitch.