Some days ago I got the security token project back to the surface (from the deepest part of my repository) to use in in another current project. Unfortunately I got an error message as I started the project for the first time. I didn't know where it came from, so I went through the code step-by-step. Fascinated I recognized that it didn't appear again. I reloaded the page several times, but everything seemed to work fine. Because of this I thought it would have been a cache problem and forgot it.

Some hours later I had deleted my cookies and tried to issue myself a new token - but there the error was again - and again it disappeared during the step-by-step debugging.

Because I couldn't find a specific reason for this I spread several breakpoints all over the code and just hopped from one to the next to narrow the place of the exception. As I finally found the place in the code, I got the following error message:

"The SamlToken is not time valid. The current time "5/14/2008 11:29:21 AM" is outside the Effective "5/14/2008 11:29:59 AM" and Expiration "14.06.2008 11:29:59" time of the token.

What happened? First I guessed that there could be a bug in the calculation of the date, until I recognized: The token was valid some seconds AFTER the issuing. But why? Could that be a build in method?

After some research in the internet I found someone who had the same problem. He already had answered the question for himself: "I think I should correct the time of the server" ... right ... there was a time difference of 30 seconds between my PC and the dev-server I used - that has been the reason why the token was not YET valid as I it was issued to me - and this was the reason why I couldn't find it as I went through the code step-by-step, because I needed a longer time to step through than the differnce between both machines.

As I recently worked on a private project, where I had to compare several files with each other, I also came across the integrated "Diff" method of SVN. To compare two files, you can call the SVN with the following command:

svn diff -r OLD_REVISION:NEW_REVISION FILE

and you get instantly your output in the diff-format.

To call SVN I wanted to start the process from an ASP.Net class in the background and capture the output. Unfortunately I got a problem. The output seemed to be empty all the time.

As I tried the same thing some days later, I suddenly got the desired output. When I came home, I replaced my old code with the new one, but again the output remained silent. Because of this I started to compare both applications (my test app and the app for the file comparison). At first I thought Vista would suppress the output, because the PC on my workplace has XP installed on it, while my private PC has Vista, but this seemed to be the wrong reason, because it also didn't work as I executed the testapp from my "work"-PC on my private one... But that was the moment I recognized it. The difference was the application type: While my project itself was a web application, the test project was a Consolen application.

This is the code I used: 

ProcessStartInfo ps = new ProcessStartInfo("svn", "diff -r 4:6 file:///MY_LOCAL_FILE");
ps.UseShellExecute = false;
ps.RedirectStandardOutput = true;

Process p = new Process();
p.StartInfo = ps;
p.Start();
p.WaitForExit();

string output = p.StandardOutput.ReadToEnd();

The string "output" was always empty (not null), while the console application showed the right output:

Console:

Web application:

That problem I had to solve, because I didn't want to use a desktop application. So I tried several things. At first I thought there would be problems with the TrustLevel of the application and that the web application was more restrictive, but no matter which changes I made at the security settings, there was no change, until I found a code snippet, which I copied 1:1. It worked in the web application, but when I reduced the copied code to the needed parts by removing the "senseless" stuff, it didn't work again... So I took the code from the internet and removed line-by-line to find out which of the lines made the clue - in this way I found the reason:

The magic property was "RedirectStandardError". As soon as I changed its value to "true", everything worked fine:

HINT:  

As I started to write this blog entry, I first wanted to use another application than SVN, so I chose "PING" (because it's available everywhere). Interestingly it worked without any problems:

So obviously it depends also on the type of the called application, if you have to change the property or if it works also without.