I blogged about TFS and the maximum file path length issue a while back, and thought I had covered it pretty well.  However, the issue came back to sting me again, so I thought it deserved another post.

Our issue was, sometimes, but not all the time, we would get this error on our team build on the build server (but the local developer build would always work fine).

[Any CPU/Release] CSC(0,0): error CS0006: Metadata file '..\..\..\..\SharedAssemblies\MSApplicationBlocks\Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll' could not be found

It took some time to figure this out... the path was correct on the server and the DLL was there.  Now if you are the intuitive type, you may have already guessed from this blogs title that the problem is related to Windows path length limitation, but why was the problem intermittent?

It turns out that this assembly reference was on a VS.NET Team Test Unit Test project.  When you used the right click "Create Unit Tests" menu to create a new test, the wizard automatically adds assembly references, including a reference to this ExceptionHandling.dll.  This would break the build on our build server.  Our quick solution was to remove the reference from the unit test project, everything still compiled and it didn't seem to be needed.  The builds now worked again on the build server, UNTIL someone added a new unit test and the cycle would start over again.  This explained our intermittent problem.

It still didn't explain why the build failed when this assembly was referenced, until I happened to find this blog entry... the same blog entry I noted in Part 1 of this blog series, but I didn't connect the dots until now. Aaron's blog entry talks about the 260 character path limit, but doesn't mention the error message we were seeing.

It turns out, that for our unit test project,  this ExceptionHandling.dll reference was the longest path of all of them, and was just long enough to be too long, but ONLY on the build server.  The way the build server paths are structured is different than our dev boxes, which was shorter by about 25 characters and this explains why the build would break on our build server but not on our local boxes.

The other severely annoying thing is that the actual error message mentions NOTHING about the path length... just that the file cannot be found.

Using Aaron's tip about these variables ($(BuildDefinitionPath) and $(BuildDefinitionId)) in the properties of the Build Agent I switched to using the $(BuildDefinitionId) which shortened the path on our build server by about 23 characters.  Now the builds always work.

The moral of the story is... if you see the error message above, double-check your path lengths.

So I had a good fight today with a SQL Server 2008 connection that would not work.  The error was:

Cannot open database requested in login myDbName. Login fails. Login failed for user 'myDbUserName'

 This was dumbfounding.  Troubleshooting the usual suspects, the following were attempted:

• check the database server to ensure that the database exists
• check the user login to ensure it exists, check the permissions for the user for this database
• try to connect using SQL Server authentication using this username and password from the Enterprise Manager - this works perfectly fine - but the ASP.NET application still gives this error
• double, triple and quadruple check the connection string for the ASP.NET application - no problems found
• drop the database and the login, recreate and try again - no difference
• reboot the database server - no difference
• check the event log for error messages - only the one displayed above is shown - nothing else out of the ordinary

WTF?

I finally figured out, after a couple hours of head-scratching, from going through some event logs within SQL Server Enterprise Manager that the database name had 6 space characters appended to the name. Therefore what appeared in Enterprise manager and everywhere else as "myDbName" was actually "myDbName      ".  Something is obviously wrong with our MSBuild script which is autogenerating the database for us during the build process... I still have to figure out how it happened, but at least now I know why it would work in Enterprise Manager and not from the application.  The app defines the connection string explicitly (with incorrect name missing spaces), while EntMgr connects and gives you a list of databases to choose from, so you never need to define the database name.

Once I renamed the database to remove the blank spaces, everything worked again.

I confirmed my theory by running this query, which highlights the extra spaces:

SELECT '"' + name + '"' FROM sys.databases

Ahhhh, the world makes sense again.

After returning from PDC 2008, I've finally had a chance to process some video that I recorded of Scott Guthrie who participated in an Open Space meeting for about an hour.  Unfortunately, I only recorded about 15 minutes of the action before my memory card filled up, but I guess that is better than nothing.

I did my best to clean up the audio, which had alot of ambient room noise.  I wish it could be better, but I think it is clear enough now to be understandable, if not somewhat enjoyable.

The video is hosted on YouTube and due to time restrictions on uploaded video, the content is split into 2 parts. 

In the first part,  Scott talks about:

• ASP.NET and MVC Framework - the future of both and them co-existing with each other
• Data Access - LINQ and the Entity Framework

In the second part, he discusses:

• Functional Programming - programming WHAT you want done, versus the more typical HOW to do something, citing LINQ as a simple example
• Moore's Law - gradually being replaced by new rules where the number of machine cores will begin doubling
• Parallelism - efforts to make it easier for developers to take advantage of multiple cores through explicit APIs and implicitly through improvements to the CLR
• F# and .NET 4.0
• Dynamic Languages
• WPF and Silverlight

Part 1
http://www.youtube.com/watch?v=9-62sSDTIMY

Part 2
http://www.youtube.com/watch?v=lXm60VnyZwo

While doing some research for something I was working on, I came across this blog about ASP.NET and the Viewstate.  This is a must read for those who are somewhat familiar with the viewstate and those who believe they know it all.   

http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

The following are some points that I took away from the article:

• an ASP.NET control will automatically restore entered/selected values even if the ViewState is DISABLED!  (wait, what? I thought that is what the ViewState was for?)
  
• the Viewstate is typically only required for simple controls if the controls will be hidden between post backs (otherwise, see point above)
• if you databind your control on each request in the OnInit event, you can disable the ViewState and the control will still automatically restore entered/selected values

I started working on a legacy web application that was comprised of both classic ASP and ASP.NET.  The development box was running win 2003 server x64 with IIS 6. 

The application typically uses the standard 20 minute session timeout period, however, for my dev box, I wanted to lengthen that time to avoid having to log in more times than necessary.  I set the classic ASP session to 240 minutes, and the ASP.NET session to 240 minutes in the web.config file.

I then proceeded to go to work.  A short time later, I was redirected to the login page.  Hmm, wierd I thought.  Ah, let it go this time.  Log in and keep working.

The next day, after my initial log in, once again my session timed out after about 40 minutes and I was redirected to the login page.  I double checked my session times, both were still set to 240 minutes.

After a little bit of head scratching, I found my way into the properties of the Application Pool for my web app in IIS.  My attention was drawn to the Recycling tab where I noted that my application pool would be recycled every 1740 minutes.  Since my sessions were stored "In Process", this recycling would kill my session, however, the timing didn't seem too likely.  Nonetheless, I changed the property to configure the worker process to recycle at a specifiec time instead:  3am.

On the Performance tab, I found something even more interesting.  An "Idle Timeout" setting that was set to shutdown the worker process after being idle for 20 minutes.  Bingo!

So even though my session timeouts were set correctly at 240 minutes, I could still lose my session after 20 minutes because the worker process would be shut down after 20 minutes of inactivity... which might be common on a development machine where you are the only web site visitor and you are distracted by other work or working in other applications for a period of time.

Once I turned off the "Idle Timeout" feature for my Application Pool, my premature session death is a thing of the past.