I'm developing a set of server controls in ASP.NET 2.0 that use several JavaScript, image and stylesheet (CSS) files.  One of the problems with distributing controls is that you usually have to send along these files and tell the end user to install them in the appropriate directory.

Along comes ASP.NET 2.0 and the ability to embed resources right into assemblies and then access these resources via URLs.  My first impression is that this seems like a good idea but I'm wary because I've been burned by MS's good ideas in the past.  My main concerns are debugging and the effect this embedding has on caching. 

Caching

One of the problems with frameworks like ASP.NET is that they sometimes take you too far away from the underlying system.  HTTP and HTML is rather straight forward.  Embedded resources in ASP.NET call the the resources via URL's and  use cache headers to insure the browser caches the content correctly.  Also the output cache in the form of disk output cache is automatically used to cache these resources.  So these embedded resources should still allow a fairly performant solution.  My question is still whether this is as good as a plain static file and the caching IIS can perform on these files.  I still need to research this.

Debugging

One of the problems I've run into involves debugging.  When a JavaScript file is embedded and it contains an error, Visual Studio.NET 2005 will open a file dialog asking for the location of the file.  This is a pain as you lose the precious JavaScript debugging ability that we gained with VS 2005.  Is this behavior by design or is there something I'm missing in regards to debugging JavaScript as an embedded resource?  My tempo ray solution is to keep the JavaScript files in a static folder while I'm debugging and then switch them to Embedded Resources when I'm deploying the control. 

However on the plus side of debugging when you change the JavaScript file it is automatically picked up the next time you do a build.  The URL of the embedded resource is changed and thus the browser grabs the newer file.  However this has a downside in that you must stop the running project to make changes to the JavaScript file and then rebuild the project to have the changes show up.

I've found that the static file path is much easier for debugging.

 An excellent article that I've referenced for this post:

http://www.nikhilk.net/WebResourceAttribute.aspx