Friday, December 12, 2014

ASP.NET "page has not been precompiled" after publishing


The file '/bla.aspx' has not been pre-compiled, and cannot be requested.


Yeah, thanks ASP.NET!  The site was most definitely pre-compiled.  This very un-useful error message has myriad causes, but for me, 8 wasted hours later, I discovered that at least this time, it was due to use of NTFS compression on my development computer.

Microsoft invented the NTFS compression scheme, so you'd think they knew how to make products that worked well with it..  Or at worst, give an error message clearly stating that use of NTFS compression is incompatible with whatever you're trying to do at the time.  But no, we get useless error messages like the above.

8 extra hours spent on a website deployment that should've only taken 30 to 60 minutes!  It was enough to have me seriously wondering whether I should join the band of happy Ruby On Rails developers!  But then I suspect they have their fair or unfair share of technology gripes too.

My main gripe is that this was what programming was like 20 years ago - extremely unhelpful error messages, things that should work but don't, and many hours and days of wasted time for no good reason.  It is the 21st century now.  We've made so much progress.  Programming is so much easier - by far - than it's ever been before.  But c'mon, we still have stupid problems like this?  Yes, I know, it's a major advance on how things were, but these vestiges of "the old way" have to go.

And as for the particular project I was working on : an extra full day of work for what should've been a simple deployment, might well have cost me a sale.  Not impressed!

If you've published your website using Microsoft Visual Studio .NET (VS.NET) and you chose the option to precompile, and yet are getting this "has not been pre-compiled" message on the server you deploy to, check to see whether any *.compiled files exist in the website's "bin" folder.  If not, then go back to your development machine, and ensure NTFS compression is disabled for the "obj" directory nested within the top-level website project directory - or whatever other location is hosting the files you're precompiling.

Here's hoping you don't lose 8 hours on this stupid bug!

And thanks to a commenter on this blog for helping me find the problem after many hours of searching.

Thursday, December 11, 2014

ASP.NET, symbolic links, and directory junctions

We like to put new versions of live ASP.NET websites in version-numbered folders.

Hitherto, that involved updating the IIS metabase so that the web site or web application "physical path" would point to the new location.

I thought it might be a little easier to use mklink to create a directory symbolic link or a directory junction with a name that I don't change (e.g. "curver" for "current version"), pointing to whatever is the current website version folder at the time.

It doesn't work.

For directory symbolic links, ASP.NET seems to totally fail to use them properly.  Instead of getting the output of each ASPX page when visiting it in a web browser, I get the ASPX source!

For directory junctions, ASP.NET seems to use them just fine, but at the point you update where the directory junction points to, it's hit & miss whether ASP.NET will notice the change or not.  If you're happy to trigger a restart of the website in IIS, then it works but if you're back to mucking around with IIS (i.e. to trigger the website restart), you might as well stick to updating the "physical path" setting of the website.

Conclusion?  It was worth a try - would've been nice if it worked, but it doesn't.