This project is read-only.

Embedded Scripts

Apr 25, 2009 at 6:59 PM
Hi, love the project.

I did catch in the Readme that you will probably not address embedded scripts, and I don't disagree with your argument in regards to the project.  However, there are a myriad of custom controls that use embedded scripts so they can't be delivered as part of a single DLL for ease of use.  Therefore, they assume a ScriptManager to handle the delivery of the resource.  While these controls may have been designed as webform things, many of them aren't contrary to the MVC separation and I still want to take advantage of them.  I am running into a wall on that right now, where such a control actually needs to go in the Site.master page!  I would beg you to reconsider this point, it would enhance this projects scope.  I could address that myself, but I hate reinventing the world.  Or if you feel right off the bat that you have better direction for me to look in I'm open to suggestions :)

Joel Mussman
Apr 26, 2009 at 1:41 AM
Hi Joel,

I am afraid even if I enable the support for embedded scripts, because your custom controls assume a ScriptManager for rendering, it might not work for you. Note that the MVC ScriptManager in this project is not derived from ASP.NET AJAX's ScriptManager.

Do you have access to the source code of the custom controls and can recompile?

Jul 28, 2010 at 3:11 PM

What controls are you using?

For example, Infragistics ASP.NET controls support  a setting in the web config that allows the controls to reference static script files instead of requesting the scripts from their DLL's (via ScriptResourceRequests)

<infragistics.web javaScriptDirectory="xxx" /> <font size="2" color="#0000ff">


</font>thier ajax controls also support this (after i submitted some help tickets ;p)  but you need to manually include the reference to the static files in the script manager as they are dependent on this.

Nov 3, 2012 at 12:47 AM

We really do need support for embedded scripts.  For large projects, with multiple functional areas, we need the encapsulation and separation of concerns that assemblies provide.  For example, my team provides mapping support for a several large projects.  It is much cleaner to publish DLLs with all of our functionality that the applications can consume via an assembly reference.  Mapping is pretty much all JavaScript, with a few related resources such as CSS and html files, but with hardly any C#. 

We don't want to have to deploy an assembly, plus a bunch of scripts and other resources.  That is too messy.  Much better to embed the scripts in the assembly, and then have a method of serving those scripts. 

Besides, if my team changes any of our scripts, there would be a new DLL anyway, which already requires a rebuild. 

Thanks for the consideration.