Debugmode issues

Dec 21, 2009 at 5:08 PM

Is there a way to make debug mode watch local resources using FileSystemWatcher or something so when changing css a developer does not have to build the project to get an updated combined file?

We have a large project, and when I am tinkering with styles I would much rather just save the sub-css file and then refresh the browser and not have to wait the ~30 seconds to build everytime i change one line of css

Dec 22, 2009 at 3:32 PM

I don't get it, debug mode doesn't even cache your resource set, so every time you hit F5 the latest combined content should be returned.  Plus, the file watcher also monitors change even in debug mode to update the version of resource set (if you use auto version).  Or do I misunderstand the situation?

Dec 22, 2009 at 3:54 PM

You understand my situation.. I think I am having an issue with my configuration then.  When I have debug enabled the files are not minified but any css or js changes do not get served unless I rebuild my site.

I'll take a deeper look now that I know this is not designed behavior.

Dec 22, 2009 at 4:29 PM

Ok so I am still having issues after trying many different things

When debug is enabled:

  • What is working
    • Browser cache headers are not making it cached.  I even have turned off my cached using firefox developer toolbar just to be safe
    • Files are not being minimized
    • Works perfectly in production server
  • What is NOT working
    • Generated version is not changing when a resource is updated after hitting F5 in browser (with DefaultVersionGenerator, Sha512VersionGenerator, and a custom one that uses last modified time)
    • When manually changing resource set url in browser, new changes are not pulled


Change set I am using: 32282


Dec 24, 2009 at 8:30 AM

Your config file looks right.  Can you turn on logging and send me the log file?  (The sample Mvc project's web.config consist the log4j config section that you can reuse.)

Jan 8, 2010 at 7:04 AM

I had exactly the same issue. The issue appears to be that the files are still in the ResourceContentCache, so the DebugProcessingWorkflow gets the files from the cache instead of the file system.

To fix this I modifed the execute method of DebugProcessingWorkflow.cs to the following

 public void Execute()
            using (var memoryStream = new MemoryStream(4096))
                var singleContents = processor.GetSingleContents(processor.ResourceSet);
                var combinedContent = processor.GetCombinedContents(processor.ResourceSet, singleContents);
                var compressedContent = processor.TryZipContent(combinedContent, memoryStream);
                processor.SendOutputToClient(compressedContent, false);

All this does is clear the cache before getting the file contents.

Hope this helps



Jan 8, 2010 at 1:30 PM
Edited Jan 8, 2010 at 1:40 PM

Hi Buu,


The problem is related to the way in which the resource files are being read. The code that is causing the issue is in the ResourceContentReader.ReadFromCache method, and I think it just needs to check whether the resource is in debug mode, and either not cache the resource or to ignore the cached version when reading, which pretty much amounts to the same thing?

Kind Regards,




Jan 8, 2010 at 1:46 PM

Actually looking at the latest version of the code, you could put the change in get method of the ResourceContentCache i.e.


public string Get(Resource resource)
return !resource.ParentSet.DebugEnabled && cache.ContainsKey(resource) ? cache[resource] : null;
Jan 8, 2010 at 2:10 PM


Thanks a lot for submitting the solution.  Unfortunately, although I am trying hard, I still can't reproduce the issue.  Under auto-versioning mode, Combres automatically detects change and invalidate the cache - so an additional cache invalidation in the DebugProcessingWorkflow should be redundant (by design).   I have tested with the same configuration settings posted earlier by howardr but the issue doesn't appear in my machine.  The only reason I can think of is that you might have a versioning collision (2 different contents of 1 resource set return the same hash), which is rare but can happen (I've created a ticket to track this issue here:

If that above fix helps your app run okay, that's great.  But I'd like to understand the real bug to address the root cause.  Can you do me a favor by checking the following steps?

  • Remove the fix.  Modify some JS or CSS in the resource set and observe if the version & content is changed (try a couple of times to make sure it's not a problem of version collision).
  • If it's not because of version collision, it's obviously some other bug in the code.  If you can get the latest Combres code, put a breakpoint in line 215 of Configuration.cs and line 299 of ChangeMonitor.cs and then debug the app
    • Note the version generated for the resource set
    • Modify a resource in that set 
    • Line 299 of ChangeMonitor should be hit by the debugger
    • Hit F5 in browser
    • Line 215 of Configuration.cs should be hit by the debugger.  Step into the foreach (var set in settings.ResourceSets) loop until it comes to the iteration of the resource set in question (not the iterations of other resource sets), at line 227, notice whether modifiedResources contains 1 resource (the one you changed) or not.  If it does, you see that the call at line 227 remove the content cache for that resource.  And as the cached content for that resource is removed, the version hash should be fresh new and the final response should be new too.
  • Now, the above is the intended workflow, if it doesn't work that way then there's a bug, with a debugger in place and the desired workflow in place I hope you can see what might cause the issue.

Note that I assume we're talking about local resources here, for remote (dynamic) resources, depending on the configured change monitor interval that a change is picked up accordingly (after the interval).

Jan 8, 2010 at 10:53 PM

I should have been clearer. I'm using the minimal configuration from the sample (the one without auto versioning).

Jan 10, 2010 at 4:55 AM


Thanks, that clarifies it.  I was able to reproduce and fix the issue now.  You can get the latest code commit for that.


Thanks a lot of the suggesting a solution.  That definitely works & helps me understand where the issue comes from. 

In the latest code commit, I do thing a little bit differently: instead of having domain logic (i.e. debugEnabled in this case) leak into the cache or ResourceContentReader, I address it by having the DebugProcessingWorkflow take care of that (by invoking GetSingleContents() in RequestProcessor with proper parameters).  That makes it easier if there's new workflow added later or if we have to modify the "idea" of debugEnabled.


Jan 11, 2010 at 10:03 AM

My pleasure, and I agree your solution is much better. Sorry I was in a bit of a rush when I suggested the change.

Jan 11, 2010 at 4:38 PM

Sorry for my lack of participation in this thread.  I took an overly long Christmas holiday. 


I pulled your changes, and now debug mode is working.  Thanks