Creating script files on demand during runtime..

[Praveen]

I have script files embedded as resources in my dll. During runtime, I would
like to write it out into the app dir (or a app sub-dir) and send the
appropriate virtual path to the client. This makes deploying my dll much
easier - just a single dll, not having to worry about deploying script
files.

However, the runtime doesn't seem have enough permissions to write out to
the app dir (or any of it's subdir), by default. The folder where I will be
writing out needs to provide "Full Control" to "Everyone", for example, for
this to work. It's not very elegant any more.

Is there a workaround for this? I would like to write out my script files
some where dynamically and without the user having to provide permissions on
folders.

Thanks
Praveen

 

[Brian Lowe]

How about using one of the user-specific system folders? MyDocuments,
Desktop, etc or even the user's temp folder should all be writeable under
the context of the useer running your dll.

 

[Praveen]

But then I cannot synthesize an appropriate URL for the script files (or the
image files) that the client can download, because it won't be within my app
dir - or any other virtual dir. Can I?

 

[Steven Cheng[MSFT]]

Hi Again Praveen,

As for the creating script files at runtime, if you do want to dynamically
create physical script files on your server's folder(maybe under your
application virtual dir's sub folder), you need to grant write permission
to your asp.net's process identity. But I don't think this is a good idea.
Alternatively, we can consider using a httphandler to render out script
resources (from resource assembly or other template files...).

Is it ok that your web appliation add an addiontal httphandler as global
script resource handler? Since httphandler can dynamically render out any
stream to clientside, we can let the httphandler to retrieve the script
resource from the assembly and write out to client. Then, in our asp.net
page, we can reference the script file through a url point to the
httphandler (with some querystring parameters to specify the assembly name
and resource file name).
For example:

<script
src="Http://servername/appname/scriptHandler.axd?asm=xxxx&filename=xxx" >
</script>

To make the url more sophisticated, we can encode or encrypte them. How do
you think of this?
Here is a tech article discussing on the similiar idea:

#Image Generation Service for ASP.NET 1.1
http://msdn.microsoft.com/msdnmag/issues/04/04/CuttingEdge/default.aspx

Hope helps,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Praveen]

Steven,

Thanks again for the feedback. That is a very good option. I alreay use such
a custom handler to generate images dynamically, I could extend it for this
scenario as well.

But (here I go), this would again require the user to setup the handler in a
web.config file (or machine.config file) during deployment and that breaks
the transparency. I do NOT want my user to know about these things I am
doing in the background. But, if I could register a httphandler in code -
from within my control implementation that would good. Is that possible?

Thanks
Praveen

 

[Steven Cheng[MSFT]]

Hi Praveen,

Yes, you're right. Using HttpHandler will certainly require the deploy
server to install the httphandler( configure in IIS and application config
file). Also, there hasn't any means to dynamically register httphandler at
runtime. So generally, when our custom webcontrol will need to expose some
external resource files such as script files images, we could:
1. put them into some global resource folders in IIS. For example, the IE
Webcontrol and ASP.NET buildin control put the global script files under
the root folder of the IIS site.

2.Using httphandler or aspx page to dynamically render out resources
streams.

Both of them will need preconfiguration before runtime execution since the
runtime applicaiton's execution identity has restricted permissions.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)