Friday 10 October, 2008 (.Net | BizTalk | Fixes | Tips)
The BOM is a two to four byte sequence at the start of an encoded file which tells the recipient if the characters are encoded using big-endian or little-endian byte order. In BizTalk generally the byte order mark is added when a file is UTF-8 or UTF-16 encoded using an XML assembler in a send pipeline. Sometimes applications cannot handle the initial bytes and you don't want them to be added to your message. I recently read two articles about removing the Byte Order Mark (BOM) from outgoing messages in BizTalk 2006 one by Saravana Kumar and the other an official Microsoft KB article. Both of them recommend creating a custom pipeline with an XML assemble stage where the PreserveBom property is set to false. I find it a little strange that they don't point out that you can accomplish this using the default XMLTransmit pipeline also. Just open the pipeline configuration in the Send Port properties and set PreserveBom to false... No custom Pipeline, no coding required.
Friday 04 July, 2008 (BizTalk | Security | Tips)
There is a nice little SFTP adapter for BizTalk on CodePlex http://www.codeplex.com/SftpAdapter/. I have been trying this out for a couple of days and it works quite nicely. I have been using freeSSHd as SFTP server and WinScp as a client to see that the SFTP functionality works. WinScp comes with PuttyGen for generating key pairs for authentication and there are a couple of guides on the web which offer clues as to how this should all be configured but I still had to resort to trial and error to get the SFTP authentication working. So this is my super concise guide to getting it up and running for local testing (presuming you have installed all the software first).
Generate a keypair with PuTTYGen
Under WinScp in the start menu you have "Key Tools/PuTTYGen"
Click "Generate" and move the mouse about. When PuTTYGen has created your keypair enter a comment so that you key is easier to identify, you can use a passphrase for your master key if you like. Save your private key as a .ppk file somewhere safe this is your master file and you can open it in PuTTYGen later if you need to export it again. Export the key (under the Conversions menu) as an OpenSSH key, but remove the passphrase first since the SFTP adapter doesn't currently support passphrases for private keys, save this key somewhere where the SFTP adapter can access it. This key should also be kept safe since it is the equivalent of a password. Select the entire textbox with the public key and copy to the clipboard.
Configure freeSSHd for public key authentication
Open up the freeSSHd settings dialogue and go to Authentication. Enter a directory where the public keys for your users will be stored. Make sure that "Public Key Authentication" is not set to disabled and that "Password Authentication" isn't required.
You also need to set a directory under the SFTP tab for storing the files. Add users in the Users tab selecting "Public key (SSH only)" as the authorization method. Also make sure that the SFTP checkbox is selected.
Go to the directory that has been configured for freeSSHd keys. Create a text file named "username" ( the users login name and no extension) and paste the public key string from PuTTYGen into it making sure it is all on one line.
Test it with WinScp before trying it from BizTalk. Now you should be up and running with your SFTP adapter and an SFTP server.
Tuesday 09 January, 2007 (Team System | Tips)
I have had several discussions with people I work with about where to put your documents when using Team Foundation Server. Obviously there are several places to put documentation depending on what sort of document it is. There are at least three places that make sense to me:
- In the SharePoint Portal
- In the Version Control repository
- As attachments on Work Items
Each of these places has their advantages and disadvantages. I have found two interesting blog posts on one by Jason Barile and one by Jeff Atwood. For me I only use Work Item attachments for documents that have no project-historic value and only cover a single work item. Screen shots for bugs is a classic example. Anything that is scoped to more than a single work item or might be of value for new project members as background material or details of why the system has been built the way it is must be stored somewhere more visible.
The Version Control repository is great for code, but for me I really don't want to see documentation in there for two reasons. All project members might not have Team Explorer installed. That means that anything that is placed under source control is effectively hidden to project members who don't work in Visual Studio. In addition the documents might not be fully visible to project members who do use Visual Studio since generally we map up our Solutions and projects and get the latest version through the IDE integration in the Solution Explorer not by using the Source Control Explorer. So if someone creates a new folder in Source Control that is not part of one of the projects that I am working on then I generally won't see it straight away. The SharePoint Portal has two advantages visibility and accessibility. All the documents are clearly visible in one place (Documents and Lists) and in addition we are not restricted to documents we can also use lists and WebParts to display additional data like reports and external links to help project members understand whats going on in addition to just getting hold of the right documents. Users who want to find information aren't required to have Visual Studio installed and configured they only need a browser to get hold of the documents.
- Use the SharePoint Portal for info that needs high visibility.
- Use the Version Control repository for code.
- Use Work Item attachments for documents that only relate to a single work item.
Thursday 07 December, 2006 (.Net | Speaking | Tips | Web)
A couple of days ago I did my first big talk, a colleague and I held a 50 minute session on migrating from ASP.NET 1.x to ASP.NET 2.0 at DevDays 2006 in Stockholm. Luckily it was a big success! I credit our success almost entirely (obviously we had some part in it...) to Scott Hanselman, we found many tips and links on the topic of public speaking on Scott's blog. The most important tip and what we worked on most was "be prepared", we studied our subject vigorously the days before, preparing for any questions that the audience might ask. We also practised our talk, including all the demos, about 6 or 7 times to get the timing right and just feel confident with the content.
In order to Google-boost these great resources and to make it easier for myself to find them again I list them here:
http://www.hanselman.com/blog/content/radiostories/2003/01/22/scottHanselmansTipsForASuccessfulMsftPresentation.html
http://www.hanselman.com/blog/PresentationTipsPPT.aspx
http://www.hanselman.com/blog/PowerPointTipsBeyondBullets.aspx
http://www.toastmasters.org/pdfs/top10.pdf
http://sociablemedia.typepad.com/beyond_bullets/
http://www.venkatarangan.com/blog/PermaLink.aspx?guid=dab57735-2976-40d7-a5d0-2e641ddea515
http://www.presentationzen.com/
http://www.hanselman.com/blog/InSearchOfThePerfectMonospacedProgrammersFontInconsolata.aspx
http://www.hanselman.com/blog/ReadySetVSNETChrisKinsmanAHrefhttpwww.aspx
http://www.hanselman.com/blog/PresentationTipsForPeopleRunningVirtualPCOrVMWare.aspx
http://www.hanselman.com/tools