Probably like most programmers, I enjoy coding a lot more than I do writing documentation. To combat this, I've decided I should force myself to write one new doc for every release of tf4mono that I make.
To that end, for the upcoming 0.4.7 release, I've whipped up a summary of the differences between the tf4mono TF client, and the standard MS client. In particular, where is tf4mono's TF better, and where is it worse. Lately, I've personally found myself leveraging the tf4mono client on my windows boxen to great benefit. YMMV.
As an aside, if you are looking for help with tf4mono, consider the new Google Group.
Tuesday, June 26, 2007
Thursday, June 21, 2007
tf4mono on windows and ntlm authentication
Recently, I've had occasion to run not just the tf4mono "tf client", but also the tf4mono TeamFoundation assemblies on a windows virtual machine.
This uncovered several platform related issues, like code that was deleting or updating files that were read-only and deleting files that we still held open.
More importantly though, I got a new perspective on the longstanding issues I've seen with NTLM authentication on Mono from my linux box. Tf4mono basically is a client for a bunch of Team Foundation web services that frequently are setup to use NTLM for authentication. So here is what I found:
When I dug into the issue previously on mono/nix, I saw something somewhat similar to bugzilla bug 80687. Jim Matysczak suggests the problem is "that the the type 1 message and the type 3 message are not being sent in the same socket connection which is required by the protocol."
By the way, all the windows related changes are all in the project subversion and git repositories, but not in any release yet.
This uncovered several platform related issues, like code that was deleting or updating files that were read-only and deleting files that we still held open.
More importantly though, I got a new perspective on the longstanding issues I've seen with NTLM authentication on Mono from my linux box. Tf4mono basically is a client for a bunch of Team Foundation web services that frequently are setup to use NTLM for authentication. So here is what I found:
- on mono/linux I see periodic, somewhat predictable NTML authentication failures
- on mono/windows, it fails every time
- on msclr/windows, it works every time
When I dug into the issue previously on mono/nix, I saw something somewhat similar to bugzilla bug 80687. Jim Matysczak suggests the problem is "that the the type 1 message and the type 3 message are not being sent in the same socket connection which is required by the protocol."
By the way, all the windows related changes are all in the project subversion and git repositories, but not in any release yet.
Saturday, June 09, 2007
TechEd Musings
I spent the last week at TechEd Orlando and blogged about much of it on the internal company blog site. I thought I'd take a minute to post some thoughts for the Mono community as well.
It seems like "platform services" like Windows Sharepoint Services and Active Directory present a unique challenge when we're talking about Mono enabling cross platform solutions. They seem challenging to me because they're not just about writing more library code, you've got copyrighted UI images, underlying database engines, directory services, etc..
At TechEd, I definitely got the impression that developing ASP.NET solutions on top of Windows Sharepoint Services would become increasingly common and of course, be encouraged by MS. You get the seem impression about ADFS, which enables federated claims-based applications.
Does this mean more and more ASP.Net applications will become unportable, or will the community rise to the challenge of building out these type of server "platform services"? I'm wondering.
On another note, it was neat to see how MS is building on the .Net 3.5 System.ServiceModel.Web stuff and the ADO.Net Entity Framework, to build out Project Astoria, which is a REST based framework for data access for Ajax/Silverlight type clients. I'm sure hoping that the WCF mono bits around System.ServiceModel.Web that enable this don't prove hard to implement.
It seems like "platform services" like Windows Sharepoint Services and Active Directory present a unique challenge when we're talking about Mono enabling cross platform solutions. They seem challenging to me because they're not just about writing more library code, you've got copyrighted UI images, underlying database engines, directory services, etc..
At TechEd, I definitely got the impression that developing ASP.NET solutions on top of Windows Sharepoint Services would become increasingly common and of course, be encouraged by MS. You get the seem impression about ADFS, which enables federated claims-based applications.
Does this mean more and more ASP.Net applications will become unportable, or will the community rise to the challenge of building out these type of server "platform services"? I'm wondering.
On another note, it was neat to see how MS is building on the .Net 3.5 System.ServiceModel.Web stuff and the ADO.Net Entity Framework, to build out Project Astoria, which is a REST based framework for data access for Ajax/Silverlight type clients. I'm sure hoping that the WCF mono bits around System.ServiceModel.Web that enable this don't prove hard to implement.
Subscribe to:
Posts (Atom)
