resource set version number

Nov 12, 2009 at 8:29 AM
Edited Nov 12, 2009 at 8:30 AM

First of all thanks for having built such a great and useful piece of software. I'm struggling with a problem with Combres, how to correctly manage versioning. Essentially I've to manually change the version number on the resourceSets every time I make a change to a js file (which happens quite usually...) to force the reload of the resource set (CTRL+F5 doesn't solve my problem, which instead works fine for css changes).

It would be nice to have a way to tie the resourceSet version number with the application version number, in that way every time the application will be compiled the resourceSet version will be different (if you adopt a dynamic version scheme like 1.0.*.* obviously).

Does that make sense?

Coordinator
Nov 13, 2009 at 5:35 AM

Combres should behave exactly the same for JS & CSS files - if you change the CSS and see the effect immediately, then it's likely that your CSS file is put in a resourceSet which has debugEnabled set to true.  Otherwise, unless the version of the resourceSet (or resourceSets, in case the child resourceSet inherits) is modified, Combres keeps serving content from the cache and you won't see the latest content.  (If this is not what you observe, it maybe a bug and I'd love to see the XML file you have so that I can reproduce & fix it.  Also, let me know which Combres version or SVN commit ID you use.)

The requirement to update version whenever one needs to invalidate the browser's cache & server's cache & force Combres to kick-off a full processing workflow (i.e. reading resources, combine, minifying and compressing them etc.) is by design.  The whole workflow is too expensive to be done frequently (and accidentally) so I thought it's better to have programmers take complete control of it (by managing the versioning themselves).  That said, there's no reason why Combres shouldn't provide options here (i.e. serve the needs of developers who want to control version themselves as well as those who don't want to do so).

I'm not sure about the suggestion to tie resourceSets version with the application version though.  When you recompile your web app and re-deploy the DLLs, ASP.NET already restarts your application (which clears the cache) and thus Combres will kick-off the full workflow for new requests w/o requiring you to modify resourceSets' version at all.  The only benefit of this is that as the URL to the resource set is changed (with the new version number), the browser won't serve the content from its cache and simply request the server for the content. 

Another solution is having Combres monitor all resources in a set and if there's any change, Combres will automatically generate new version for the set as well as invalidate the server's cache.  Thus latest files are assured to be served without requiring developers to manually modify version themselves.  What do you think about this? 

Nov 13, 2009 at 8:50 AM
Edited Nov 13, 2009 at 8:52 AM

>>Combres should behave exactly the same for JS & CSS files...
I will update to the latest version later and try again. I always set minifiers, version, etc on the resourceSets element:

<resourceSets defaultDebugEnabled="true" defaultVersion="1" 
 defaultDuration="30" 
 url="~/combres.axd"
 defaultCssMinifierRef="yui"
 defaultJSMinifierRef="msajax">
 
What I care about is the workflow during development, in production how Combres handles css/js is just fine. What I need is forcing the browser to make a new request when I change a css/js and the only way is changing the url that is serving resource sets.
 
>>Another solution is having Combres monitor all resources in a set and if there's any change...
That would be great!
Coordinator
Nov 13, 2009 at 12:03 PM

>>What I care about is the workflow during development...

That makes sense to me.  I've added a ticket for this issue here for tracking http://combres.codeplex.com/WorkItem/View.aspx?WorkItemId=5465. 

 

Coordinator
Dec 1, 2009 at 2:35 PM
buunguyen wrote:

>>What I care about is the workflow during development...

That makes sense to me.  I've added a ticket for this issue here for tracking http://combres.codeplex.com/WorkItem/View.aspx?WorkItemId=5465. 

 

I've already implemented this feature in the latest code commit.  See description about the feature here: http://combres.codeplex.com/WorkItem/View.aspx?WorkItemId=5465