UserControl caching causing big delays in development time

Posted by Community Admin on 04-Aug-2018 19:19

UserControl caching causing big delays in development time

All Replies

Posted by Community Admin on 24-Nov-2011 00:00

Hi,

With Sitefinity 4.x (we are on 4.2), when we are developing and make a change to a UserControl .ascx file, Sitefinity doesn't seem to re-read that file, even after rebuild.  This means if we make a change and want to test it, we have to kill the Cassini web server and then rerun the project in order for SF to see our changes.  You can also edit the page and go to settings and change the caching there and save, but you have to do that every single time.

This make development 10x slower than it needs to be if SF could be set to re-read the .ascx files each time they are called (used). At least during development.

Is there a way to do this?

Please let me know

Thanks

Ben

Posted by Community Admin on 25-Nov-2011 00:00

Hello Ben Alexandra,

There are couple of reasons for this behavior:

- Sitefinity is a web application rather than a web site, and this by definition requires recompile/build of the entire project. There's no need to kill Cassini, but rather to recompile.
- Even if you open the web application as a web site, you still may not see the changes, due to the full page caching. You can disable the cache during development.

On the other hand, why do you use Cassini for development? It's much slower then IIS is integrated mode. Moving to IIS should provide you with some speed. Opening the project as a web site will also speed the things up, since it will not require compilation every time, but just on JIT compilation on the modified files. 

Kind regards,
Georgi
the Telerik team
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

Posted by Community Admin on 25-Nov-2011 00:00

Hi Georgi,

Well we use Cassini for the reason it was created.  It creates an instant website with debugging.  As far as I know, there is no other way to debug your code in Visual Studio.  You can't have breakpoints in IIS, right?

We have tried turning off page caching but it seems to have no effect.  We have done it under Advanced Settings in the Admin as well as under page setting for a page.  It has no affect on what I am trying to do.

Here is the scenario and frustration.

I have a UserControl that need to go onto a certain page
We'll call it uc.ascx and it has a code behind of uc.ascx.cs
I have code in the uc.ascx.cs file that I need to debug
I also need to make changes to the uc.ascx file and see those changes on the page in SF
I drop the UC onto an SF page and disable caching for that page
I disable caching for the entire site, but it seems to have no effect on this problem
I run the website and see the page with all my changes to the UC
I then go to uc.ascx and make a change and refresh the page in SF
I SEE NO CHANGE!
I hit build on the project
I refresh my page in SF
I wait for the web site to reload itself into memory and come up
I SEE NO CHANGE
I rebuild the site
I wait for the entire project and related projects to rebuild themselve
I hit refresh in SF
I then have to wait for the site to reload itself, usually longer than just a build
I the often see the message:  "The system is restarting... Please wait a few seconds. You will be redirected automatically."
I continue to wait for the system to restart.  This is a very long wait!
I then finally see the small change I made in the uc.ascx file!

(I am in debug mode in this particular scenario in order to be able to put breakpoints in the backend code (uc.ascx.cs) which is sometimes needed.)

This is a new issue in SF 4.x.  I imagine that this is a fairly common way to develop in Visual Studio.  If you are working on the layout and styling of a UserControl and need to be able to add divs and controls, change or assign classes to controls, etc. and then see your results, you have to sit there and wait a huge amount of time.

I haven't tested this particular thing in just IIS but I imagine it's actually the same problem.  Once SF reads a .ascx file it caches it and doesn't go back to read it again, even if its changed.

I'm sure this makes SF snappier but it also means developing UserControls is incredibly slow.  There should definitely be a place to turn on and off this feature for development.

We have been developing this way in SF for many years and it's only since you moved to 4.x that this has been a problem and honestly it make using SF almost impossible when you are talking about developing or styling a UserControl.

Thanks

Ben

Posted by Community Admin on 26-Nov-2011 00:00

@Ben You CAN debug in IIS and it's spectacular :). Easily twice as fast as casini. You just need to go to the attach to process menu option in vs2010 (build menu?) and then attach to the w3wp process...there might be multiples in there but if youve opened vs2010 as an admin then you can see the process names in one of the columns. Each w3wp corresponds to an IIS app pool. I will echo bens frustration with caching on usercontrols. I also I have a project with cache disaled (just page level though) and am experiencing caching of the ascx. Steve

Posted by Community Admin on 26-Nov-2011 00:00

Man I hate responding on an iPad, doesn't format my new lines at all. Anyway I'd like to see a cache substitution wrapper control (codeless) ...just wrap your code (the ascx) in that control and it won't be cached.

Posted by Community Admin on 26-Nov-2011 00:00

@Steve,

Thanks for the info.  I'll try it out.  Still doesn't solve my problem, though, which is the caching.  Seems like SF reads files off the disc once, then doesn't go back to re-read them and see if they've changed.  This is great for speed on big projects, but there needs to be an override so you can develop efficiently.  Even just a setting in the web.config of CacheLocalFiles="false" or something.  Once you are ready to deploy, you could turn that to ="true" for the live server.

Make sense?

Ben

Posted by Community Admin on 30-Nov-2011 00:00

@Georgi,

Any response?  I posted 4 long posts 5 days ago and haven't gotten responses on most of them.

An answer to this would be greatly appreciated

Thanks

Ben

Posted by Community Admin on 30-Nov-2011 00:00

I should Echo ben on this...

I am also being slowed down as it's hard to clear the cache on the control...when I have cache disabled.

Posted by Community Admin on 30-Nov-2011 00:00

Hello,

You can work with a website locally in Visual Studio. Instead of opening the SitefinityWebApp.csproj file go to Visual Studio -> File -> Open -> Website and navigate to the directory if your SF project. Now when you open it as a website and you create user controls instead of having CodeBehind they will be using CodeFile which is compiled by ASP.NET at runtime and changes in the CodeFile are visible upon refresh.

Best wishes,
Radoslav Georgiev
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

Posted by Community Admin on 29-Dec-2011 00:00

I have this issue as well.  Georgi, you are not understanding the question. You keep telling talking about the code files, but we are talking about the markup in .ascx files (what you might call a custom template).  This has nothing to do with re-compiling.  If you change the markup in any .ascx file, you have to restart the Visual Studio web server (or recycle the IIS app pool) or re-publish the page to see the changes.  That is incredibly unproductive as you might make dozens of changes and need to preview the results quickly if you're just working with the UI.

There must be a way to turn this .ascx file caching off.  Turning off caching on the page doesn't do it, and unchecking "Enable Output Cache" in the "Output Cache Settings" section of advanced settings does not do it (even though the description would lead me to believe this is would do it).

Posted by Community Admin on 31-Dec-2011 00:00

@Jeff,

You nailed it and I don't understand why the Telerik team is having so much trouble understanding the problem.  Development takes 10 times as long as it needs to because of this caching issue and Telerik doesn't even seem to understand what we're saying.

This is new in 4.x.  In older versions (e.g. 3.7) you could make a change to a .ascx file and refresh the site and your change would be immediately visible.  Now it seems that Sitefinity reads the .ascx file on startup of the site and if you make a change and refresh it says "Hey, I already read that file into memory, no need to recheck the disk" and therefore you can't see your change.  The only way around it is to restart the site and wait for Sitefinity to restart and it all to load up (which can take 10-40 seconds each time depending on the box.  For various reasons we use the site as a web application, not web site and we find the quickest way is to his Rebuild, which takes up to 10 seconds, then when we refresh we wait and wait for everything to reload and restart.

We could avoid this whole thing if we could just turn off Sitefinity thinking it always has the latest version of files on the disk!

A web.config setting would be ideal for local development, and then for live servers we would turn that back on so the site can run more quickly (I'm guessing that this is turned off to help with performance).

Thoughts?

Ben

Posted by Community Admin on 03-Jan-2012 00:00

Hello,

The behavior you are seeing is partly caused by Sitefinity and partly by ASP.NET web application projects. On the Sitefinity part you can disable page (output) caching and client-side caching from the Sitefinity configurations.

Let me explain what is happening on the ASP.NET part. Since Sitefinity uses the ASP.NET compiler to compile pages, templates and controls you need to build the application in order for ASP.NET to invalidate the already compiled version of the particular control you are changing. This is different from Sitefinity 3.x as we did not use the ASP.NET compiler for pages, templates and controls. This caused pages and other resources to built on every request, which I doubt that you would want that in an application. What you have to do is when changing user controls, build the web application to see the changes immediately.

Kind regards,
Radoslav Georgiev
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

Posted by Community Admin on 03-Jan-2012 00:00

@Radoslav,

Can you confirm that you are referring to the .ascx pages and NOT the .ascx.cs page?  You speak of recompiling but I am talking about the code in FRONT, not the code behind.  Are you saying that it is ASP.NET that is caching both the code in front and the code behind?  Is there really no way for you or us to make it so that the code in front is not cached and that on every refresh the site would read the markup from the disk again?

Thanks

Ben

PS I have turned off the caching options in SF without any results on this front

Posted by Community Admin on 03-Jan-2012 00:00

Hello,

Yes I am refering both to the ascx file and to the ascx.cs file. ASP.NET passes the control templates (ascx files) through its compiler and creates temporary assemblies for them in the temporary ASP.NET files folder. When you work with ASCX files you can build the SitefinityWebApp project so that ASP.NET knows that the files have been changed.

The other option while developing is to:
1) Disable page caching
2) Open the project as a website instead of as a webapplication. In this way when you make changes to ascx files they will be compiled by ASP.NET at runtime.

Regards,
Radoslav Georgiev
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

This thread is closed