April 2007 - Posts
Upgrading to CS2007 was really painless, but there was a hole left in my site because of no CAPTCHA support. Well, that has all changed now. A huge thanks and shout out to Brendan who has produced the CAPTCHA goods.
His implementation was so easy to install. It leverages the control adapter capabilities of ASP.Net which avoids any impact on the existing code base. Another thing I like about this implementation is that it doesn't require authenticated users to enter the CAPTCHA value. This is absolutely awesome! Thanks Brendan.
Every now and then, and sometime more often than that, I happened to not have my fingers on the right keys. The results are usually terrible, but can sometimes be kinda cool. I just tried typing "similar" and came up with "sunukar" instead. Maybe that should be the name of my next piece of software.
Following in one of the trends of Microsoft, I have been naming software according to town names. Could this be the new method of generating code names? Just bash the keyboard in semi-random positions.
If you have an ASMX client, you can get it to call a WCF endpoint with some restrictions. You have to use the basicHttpBinding on the WCF service and the service implementation (or contract) needs to be decorated with the XmlSerializerFormat attribute.
I have encountered a problem under SSL though. I am wanting to use username/basic authentication with the service over SSL. This article makes the following reference:
The easiest straightforward way for a successful interoperability scenario is to leverage on transport-layer security. This also means that a properly configured WCF implementation can interoperate with a Basic Profile 1.0 compliant ASP.NET Web Service (ASMX) that is currently deployed via SSL / HTTPS as well as with a WSE 2.0 service or client and likewise.
WCF has a standard binding called “<basicHttpBinding>” which derives its name from the Basic Profile specifications. There is a security mode within this binding called “TransportWithMessageCredential”. You can choose either a transport or a message credentials in this security mode. Setting it to <message clientCredentialType="UserName"/> uses Transport-Level Security (SSL / HTTPS) with SOAP-Level Username token security credentials. This is in accordance with the WSS SOAP Message Security Username Token Profile 1.0 and it implements WSS SOAP Message Security 1.0 specification for username/password (for client authentication) over HTTPS (for privacy).
My WCF client consumes the endpoint correctly as the authenticated user. However, when using an ASMX web reference, I end up with the following error:
System.Web.Services.Protocols.SoapHeaderException: An error occurred when verifying security for the message.
So far, I haven't got a solution.
Update:
Still no solution, but I have read in more places that indicate this should be fine. The following articles refer to the same kind of setup I am running. The only difference I that my client is an asmx client, but with a basicHttpBinding, this should be fine.
MSDN Library - Bindings and Security:
BasicHttp
In code, use BasicHttpBinding; in configuration, use the basicHttpBinding Element.
This binding is designed to be used with a range of existing technologies, such as the following:
-
ASMX (version 1) Web services.
-
Web Service Enhancements (WSE) applications.
-
Basic Profile as defined in the WS-I specification (http://www.ws-i.org).
-
Basic security profile as defined in WS-I.
By default, this binding is not secure. It is designed to interoperate with ASMX services. When security is enabled, the binding is designed for seamless interoperation with IIS security mechanisms, such as Basic authentication, Digest, and Integrated Windows security. For more information, see Transport Security Overview. This binding supports the following:
William Tay - Enterprise .NET Community: Securing your WCF Service
Michele Leroux Bustamante - Fundamentals of WCF Security
I was doing some reading a while ago about digital certificates. The kind of certificate I was after was so that I could use HTTPS in IIS. It looked like the certificates were all very expensive for what they are. I finally came across a post that referred to StartCom. These guys offer free digital certificates for domain or email validation. At this stage, the only hitch is that the CA certificate is not on client machines by default, but can be installed from the StartCom site.
Check it out here.
I have found that I encounter the same problem in CS2007 as I did in 2.1. The tag cloud url encoding converts spaces to the + character. When IIS on my Vista box processes the request, it produces a 404 error. If a %20 combination is used instead, the url is valid.
I have checked out the CS2007 source to look at the TagCloud control that is responsible for the rendering of this part of the page. The code winds its way right down to the UrlEncodePathComponent method in the WebHelper class in Telligent.Components.dll. The method simply contains the following:
public static string UrlEncodePathComponent(string text)
{
return UrlEncode(text, _pathComponentTextToEscape, '+', '_');
}
This is where the + character is specified as the replacement for spaces in urls. But is this a problem? Well, no. A + character is a valid space character to use. So is it a problem with IIS on Vista, or a problem with how Community Server is rewriting the url?
I have noticed that spaces in tag names on the Community Server site doesn't cause a problem. I wonder which OS they are hosted on.
I got CS2007 installed on my server last night. It was easy enough, but I was quickly hit with comment spam overnight. I can't wait for Dave to release a new version of his awesome CAPTCHA control. Using his control, the only time I got comment spam was one night when someone manually entered about 8 comment spam entries through the CAPTCHA. What a goose!
Given the recent problems on CodePlex, I have had to change the TFS server that one of my projects is hosted on. I found this to be a problem because I wanted to use the same directory for the source on my local drive. Even after removing the source control bindings and removing the TFS server settings, Visual Studio still complained that the directory is configured for the old server address.
TFS stores workspace directory mapping information in a VersionControl.config file located in C:\Documents and Settings\[YOUR PROFILE]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\. The old server isn't removed from this configuration when you remove the server from TFS in Visual Studio. This bit, you have to do yourself.
CodePlex suffered from more than a little human error last Tuesday. I just checked my project page for a project that was hosted on tfs03.codeplex.com. The project is now available again, but I noticed that it is now on tfs02.codeplex.com. Well, at least it looks like I can use the project space again. I am guessing that the data is gone though.
Looks like the good people at Telligent have done it again. Community Server 2007 has been released into the wild. Congratulations guys. Time to upgrade 
.
Over the last week at work, we have been doing some testing of our Windows Communication Foundation services that call into a business layer that uses Windows Workflow Foundation. We have the services set as single instance, and we are using a new instance of the WorkflowRuntime for each service call. There are obvious inefficiencies of creating the runtime for each call, but that isn't the issue. The problem is that we noticed that the memory went up and didn't get released (until the AppDomain was unloaded).
After a lot of testing, it came down to the WorkflowRuntime instances that were remaining in memory, even through all of our other objects were cleaned up and disposed. We did everything we could to release the runtime from our code but the memory issues remained. So, is there are memory leak in the runtime?
The solution seems to be to wrap the runtime as a singleton. Singletons have been bashed a lot over recent months and while I agree with the criticism over the misuse/overuse of singletons, I think this is an appropriate case for one. Initial testing has shown that there is no memory problems once only a single WorkflowRuntime was used. This also comes with the performance benefit of not having to create and destroy the runtimes for each call.
Scott Allen has some more pitfalls to watch out for with the runtimes.
I am a little curious about how the garbage collector cleans up CLR objects. From what I understand, it will wait until objects are de-referenced and then will go through a couple of generations (as required) to release objects from memory.
The following is a simple scenario of GC:
Object A that has a reference to B that has a reference to C. When A goes out of scope, the GC can collect it. When it removes A, B is has a reference count of 0 and can also be removed and then likewise for C as B is removed.
Side question: does this happen in the same GC cycle or is this over three GC cycles?
Ok, simple enough. But how does the GC handle the following scenario:
Object A has a reference to B which has a reference to C. C has a reference back to B.
When A goes out of scope, is B available for the GC as it is still referenced by C? How does the GC handle these circular references?
Using MCE has been quite a good experience for me. The exception to this is PRIME which for me is notoriously jittery. One thing I did notice recently is that when the daylight saving change happened recently, my recording times got thrown out by an hour.
I find it strange that if I want to record from 8:30pm-9:30pm that this is stored against (presumably) a UTC value. Surely it would be better if MCE just stored the local time. It's not like I'm going to take my box to another time-zone and still have relevant scheduled recordings.
What is this? Well, that would be Mt Rogers. You will have to trust me on that score.
Looks like this is the first decent fog of the season. Now if we can just get some of this stuff, everything will be shiny!