Ok, so I’ve finally sucumbed to the Twitter phenomenon and I’m now twittering, or is that tweeting? Eitherway, you can follow me over at http://twitter.com/nickheppleston if you are so inclined…
Archive for February, 2009
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/02/20/useful-tooltip-in-the-biztalk-admin-console-with-badly-encoded-messages/
I noticed a new tooltip yesterday in the BizTalk Admin Console when a message had failed in the Receive Pipeline because of unexpected characters in the message (and because no encoding had been set in the Xml declaration). Interesting to see that the message body text view recognises that the text view might not be accurate:
Drilling into the binary view, I was also pleased to see that it was possible to use ‘find’ dialog to search for the offending text:
Two useful features that up until now I didn’t know were available in BizTalk 2006. No need for me to invest in the znazzy binary viewer after all….
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/02/17/gotcha-when-exporting-adapter-config-in-binding-files/
This one caught me out today – hope it might help others in the future…
If you export Bindings to get the lovely syntax for the ReceiveLocationTransportTypeData element, make sure that all of the properties in the adapter configuration dialog that you are interested in are populated *before* you do the export. Otherwise, it would appear not all properties come out in the Binding File Xml.
In the example below, I have mistakenly not set the username and password properties for the FTP adapter and they have not appeared in the ReceiveLocationTransportTypeData element when I export the bindings:
<ReceiveLocationTransportTypeData><CustomProps><AdapterConfig vt="8">&lt;Config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;&lt;serverAddress&gt;test-ftp-server&lt;/serverAddress&gt;&lt;serverPort&gt;21&lt;/serverPort&gt;&lt;representationType&gt;binary&lt;/representationType&gt;&lt;maximumBatchSize&gt;0&lt;/maximumBatchSize&gt;&lt;maximumNumberOfFiles&gt;0&lt;/maximumNumberOfFiles&gt;&lt;passiveMode&gt;False&lt;/passiveMode&gt;&lt;firewallType&gt;NoFirewall&lt;/firewallType&gt;&lt;firewallPort&gt;21&lt;/firewallPort&gt;&lt;pollingUnitOfMeasure&gt;Seconds&lt;/pollingUnitOfMeasure&gt;&lt;pollingInterval&gt;60&lt;/pollingInterval&gt;&lt;errorThreshold&gt;10&lt;/errorThreshold&gt;&lt;maxFileSize&gt;100&lt;/maxFileSize&gt;&lt;uri&gt;ftp://test-ftp-server:21&lt;/uri&gt;&lt;/Config&gt;</AdapterConfig></CustomProps></ReceiveLocationTransportTypeData>
Compare this to the ReceiveLocationTransportTypeData element after setting these properties and exporting the bindings – the userName and password properties are now included (yes, I know its like reading spaghetti, but you get the idea!):
<ReceiveLocationTransportTypeData><CustomProps><AdapterConfig vt="8">&lt;Config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;&lt;uri&gt;ftp://test-ftp-server:21&lt;/uri&gt;&lt;serverAddress&gt;test-ftp-server&lt;/serverAddress&gt;&lt;serverPort&gt;21&lt;/serverPort&gt;&lt;userName&gt;user&lt;/userName&gt;&lt;password&gt;******&lt;/password&gt;&lt;representationType&gt;binary&lt;/representationType&gt;&lt;maximumBatchSize&gt;0&lt;/maximumBatchSize&gt;&lt;maximumNumberOfFiles&gt;0&lt;/maximumNumberOfFiles&gt;&lt;passiveMode&gt;False&lt;/passiveMode&gt;&lt;firewallType&gt;NoFirewall&lt;/firewallType&gt;&lt;firewallPort&gt;21&lt;/firewallPort&gt;&lt;pollingUnitOfMeasure&gt;Seconds&lt;/pollingUnitOfMeasure&gt;&lt;pollingInterval&gt;60&lt;/pollingInterval&gt;&lt;errorThreshold&gt;10&lt;/errorThreshold&gt;&lt;maxFileSize&gt;100&lt;/maxFileSize&gt;&lt;/Config&gt;</AdapterConfig></CustomProps></ReceiveLocationTransportTypeData>
I can understand why the adapter config only exports those properties that are used – why clutter the config with empty values, but a gotcha to watch-out for nonetheless.
Originally posted by Nick Heppleston at: http://www.modhul.com/2009/02/02/permissions-to-add-assemblies-to-the-gac/
I received an interesting error today while setting up a new TeamCity build-server. When running the MSBuild Microsoft.Sdc.Tasks GAC uninstall task – GlobalAssemblyCache.GacHelper.Uninstall – I kept receiving the following error:
C:\Subversion\Trunk\BizTalk\Build\Common-Deployment\Common\Deployment-Cleanup.proj(59, 3): A task error has occured.Message = Failed to uninstall CandidateMarks.Canonical, PublicKeyToken=1b76b267b587386b from the GAC. AssemblyName = CandidateMarks.Canonical, PublicKeyToken=1b76b267b587386b at Microsoft.Sdc.Tasks.GlobalAssemblyCache.GacHelper.Uninstall(String name)at Microsoft.Sdc.Tasks.GlobalAssemblyCache.RemoveAssembly.InternalExecute()at Microsoft.Sdc.Tasks.TaskBase.Execute()
It turns out that the user attempting to uninstall or install assemblies to the GAC needs write permissions to the %systemdrive%\Windows\Assembly directory (as documented here and here). Adding that user to either the local computer Power Users or Administrators Group provides the necessary permissions and the above error is no longer an issue.