This project is read-only.

Website will not update to reflect code changes

Topics: ASP.NET 2.0, Controls
Apr 17, 2012 at 4:40 AM

I've made several changes to an ascx control on the website I recently took over development for (which was implemented using BlogEngine.NET).  For some reason no changes I submit via ftp ever end up reflected on the website itself.  I've conferred withe the IIS administrator (it is IIS6), and they are indefatigable in their opinion that this is an issue with the code and not the server.  Is there some sort of cache that BlogEngine maintains that would prevent live updating of code?

Apr 17, 2012 at 1:37 PM


The simplest answer is often correct, as wacky as it might sound.  In this case, is it possible that you're not updating the site content?  Perhaps there is some permissions issue, though I suspect if so the FTP client log would display the error.  Is the .ASCX date time updated?  With only FTP access it's sometimes difficult to confirm updates.  And another wacky possibility, are you sure the site you're updating to is the production site?  

You also may want to touch the site web.config (though changes to a .ASCX should be reflected on reload.)

Good luck,


Apr 18, 2012 at 3:23 AM

Perfectly reasonable questions, but I can assure you that the FTP is uploading, I always verify my changes are reflected by reopening the file from the server.  In this case I did it from a different computer just to make sure it wasn't a caching on my FTP client.

In terms of production folder, that's a stickier question.  I'm just learning how BlogEngine.NET organizes itself, but the particular line of code I'm trying to modify is a control that puts up a link, I did a grep of all of the data on the server and found only one line that matches the ID that is attached to the link, in it certainly looks like what I'm seeing when I inspect the element, so process of elimination would suggest I'm modifying the correct file.  This gets to the root of my question, whether BlogEngine.NET might be caching the data someplace, as I am fairly certain I am modifying the source.  I did notice that there is an HTML compression setting that I thought might be the culprit, but disabling it did not resolve the issue.


In touching the web.config, is that a developer trick to force an update to a site?  Is the insertion of a null character (like a space or a carriage return) enough?

Thanks for your prompt response.


Apr 18, 2012 at 5:49 AM
Edited Apr 18, 2012 at 5:51 AM

In following up with your second suggestion, I am convinced I am editing the proper file as when I remove the file from the server it immediately throws an error for the requested page, but replacing the file again with my modified file does nothing to change the final output on the site.

Here is the code section of what I am attempting to change:


{{if website.Length > 0 && website !== "http://"}}               

<p><a target="_blank" href="${website}">Official Website</a></p>           



{{if website.Length > 0 && website !== "http://"}}               

<p><a target="_blank" href="TEST">Official Website</a></p>           



Here's the reason why I want to figure out how to get this code to change, when I inspect the element on the page I get this:

<a target="_blank" "href="">Official Website</a>


Note the extra quotation mark before href, this is causing the link to not function.

Apr 18, 2012 at 1:39 PM


Yes, a space on the web.config and saving does the job, or simply renaming the web.config via ftp momentarily and naming it back also restarts the site.

That was smart to remove the file.  

So the issue is the quote before the href?  That is very weird.  Is the quote on any other links?  It sounds like some sort of script that is modifying page elements somehow.  And this doesn't occur on the local machine?


Apr 18, 2012 at 9:51 PM

I suspect the quote is there from a typo that someone made and is being stored by whatever caching is going on on the site.  So while the quote is the phenomenon I'm trying to eliminate, I think the solution lies in figuring out how to get the site to stop using the cache or whatever it is that is causing this.

I don't have a local test environment, I only recently started working with this site and haven't gone through the process of cloning it yet.

Apr 18, 2012 at 9:57 PM

I tried changing and reuploading the web.cofig file, it did not make a difference.

Apr 20, 2012 at 1:41 AM

Anyone else able to weigh in on this one?  I'm running out of options here and anyone with experience with BlogEngine's inner workings would be appreciated.

Apr 20, 2012 at 3:19 AM

There is only client-side caching in BE, you should be able to clear it for example in FireFox by going to History -> clear recent history -> check "caching" and click "clear now" or do similar in other browsers then hit F5 to refresh. Not sure about those double curly brackets, it looks like jQuery templates and BlogEngine does not use it, probably custom code that can behave differently.

Apr 20, 2012 at 3:24 AM

Clearly this is not a local cache problem.

Apr 20, 2012 at 5:24 AM

Ok, the mystery is partially solved, though not fixed yet.  I discovered that there was a .ascx.cs file with the same file name that had the error in it.  I've fixed the typo, but I  know nothing about how C# works with this, do I need to recompile the code?  Where do I put the resulting file, or could this be part of a different compile for the whole site?  I really don't know if this is still BlogEngine.NET territory or if this is something that was added by another developer.  Any ideas?


I'm also not sure why there are seemingly redundant implementations of features on this site, I wonder if this was someone starting to convert the site from one format to another.

Apr 20, 2012 at 3:10 PM

BlogEngine is "website" project, which supports dynamic compilation. That .ascx.cs file should be compiled on the fly by If it doesn't, probably you have instance converted to "web application" project or someone integrated BE into existing web application. Then you would need to recompile. BE is relatively small and easily customizable, so you see people using it in all kinds of configurations piling redundant implementations ,as you said, on top :)