The last update to IronPython for ASP.Net was back in July 2007. There hasn't been any movement for almost a year now. 

 Hi,

I'm not using this myself but it seems to me that the latest version was from January 27th, 2008. Check out the official downloadsite at codeplex: http://www.codeplex.com/IronPython. 

Grz, Kris. 

Yep, we feel your pain with there being no update to the IronPython support for ASP.NET in the past year. Or what about supporting IronRuby? Or even integration with ASP.NET MVC?

http://blog.jimmy.schementi.com/2008/07/aspnet-and-dynamic-languages.html

The dynamic languages are definitely not dead. IronPython 2.0 Beta 3 was released on June 13, 2008 on http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12988, and IronRuby refreshes it's SVN repository (http://ironruby.rubyforge.org/svn/trunk/) almost daily. Managed JScript is released monthly, but only for Silverlight in http://codeplex.com/sdlsdk, along with IronPython and IronRuby.

As far as ASP.NET integration, we're picking this project back up on it's feet and you should hear things very soon; the best place to watch for this is my blog: http://blog.jimmy.schementi.com. As far as "when" you'll get it, we're not sure ourselves, but again, watch my blog for updates.

Let me know if you have any other questions,

~Jimmy

Why is there no more information about managed jscript? If you search around the web, the freshest information about managed jscript was about a century ago and they were mostly about announcement than the information about the implementation itself. There are far more information about other javascript on the server implementation like Rhino on JVM than the blip on managed jscript.

And will we ever see a sane managed jscript for a desktop (instead of it being tied to Silvelight)? Is there any plan to support Javascript 2.0 specification, etc. 

 One more thing, since you are starting working on asp.net dynamic language support, can you please add an "interpreted" mode so that the source is run interpreted for every http request (just like those PHP or Python frameworks)?

 This will allow automated code generation for every single HTTP request via Virtual Path Provider. Right now the "No Compile" implementation still create an assembly for each page for  first time  execution which creates a massive problem for automated code generation because ASP.Net simply ignore the newly generated code for the second request and go directly to the cache. This is not a good thing for code generation scenario.

 With VPP and Interpreted mode, one can do a lot of cool thing by having a full control of the code to be sent to the ASP.Net http handler to process.

This is mostly an unrelated topic, but note that VPP has caching APIs that you can implement to invalidate the cached content (look at GetFileHash).  But note that this is not directly related to dynamic language support, and applies to all pages (compiled or not).

David

 That's the technique I am using right now, but doesn't that makes asp.net runtime to keep rewriting the generated dll to the disk for every request to the same Url? I think with "interpreted" mode, the requests can simply processed in memory after VPP returns the source to be processed.

No, it only reprocesses the aspx files when they have changed, so for the majority of requests it's very fast.

David

Hmm..I'm confused.

In a VPP scenario, it is possible to have full control the "source code" generation - so when asp.net asks for the source for say "/default.aspx", we generate the content of the template based on some condition. (This is a common scenario in CMS situation when the whole pages are based one some template generated output.)

So when User A request /default.aspx, she's given a source A1 and when User B request /default.aspx, he's given a source A2 via VPP because his status is "Guest".

In this case, doesn't ASP.Net treat each A1 and A2 as two different files and reprocessed it for each request?

Normally, a given virtual path always represents the same resource, just like a physical path on a file system always means the same file.  But I think you should be able to make this work by overriding GetCacheKey, and returning a cache key that depends not just on the path but also on your other factors (e.g. the current user).  This way, ASP.NET will use a different cache entry for each user, but will not need to reprocess the page if the same user makes the same request multiple times.

David

dodygunawinata:

Why is there no more information about managed jscript? If you search around the web, the freshest information about managed jscript was about a century ago and they were mostly about announcement than the information about the implementation itself. There are far more information about other javascript on the server implementation like Rhino on JVM than the blip on managed jscript.

http://codeplex.com/sdlsdk has information about Managed JScript in Silverlight, and every month or so updates Managed JScript bits for Silverlight. Honestly, the team working on it is very focused on making the language implementation, and I'm doing them a favor by releasing their bits for Silverlight regularly. It's aimed at being a ECMAScript 3 implementation, but outside of that, what would you like to see?

dodygunawinata:

And will we ever see a sane managed jscript for a desktop (instead of it being tied to Silvelight)? Is there any plan to support Javascript 2.0 specification, etc. 

Sane? As in the origional JScript for the desktop was insane? Well, no arguments there. =)

Today Managed JScript can build on the desktop, but there still needs to be work done in providing a REPL console, VS integration, ASP.NET integration and other useful things like that. The DLR is pushing towards 1.0 in the fall, so I'd expect to hear a lot more about Managed JScript then.

dodygunawinata:

 One more thing, since you are starting working on asp.net dynamic language support, can you please add an "interpreted" mode so that the source is run interpreted for every http request (just like those PHP or Python frameworks)?

The DLR will have an interpreter as well, so you can choose either to compile or interpret. This helps for startup a ton. However, as Dave said, the ASP.NET integration today doesn't recompile on every http request.

jimmysch:

Sane? As in the origional JScript for the desktop was insane? Well, no arguments there. =)

JScript.Net has always had a feeling off J# all over it since its introduction in .Net 1.1, in short, "this sucker is going to get dropped real soon". Which version of ECMAScript did JScrip.Net actually support? One will have a hard time to find JScript.Net language specification (does it even exist?)

jimmysch:

Honestly, the team working on it is very focused on making the language implementation, and I'm doing them a favor by releasing their bits for Silverlight regularly. It's aimed at being a ECMAScript 3 implementation, but outside of that, what would you like to see?

 I would like to see Managed JScript to actually get a proper treatment as a language, which means a language spec (or even confirmation that it supports ECMAScript 3 specification like what you just outline above), a place that you can actually learn on how to use the language within the .Net ecosystem, etc. Right now Managed JScript is being treated like a *** child - just like JScript.Net (and see how well it went)  without proper support being given in terms of information and documentation. IronPython and IronRuby have very vibrant community - Managed JScript has none - and it's a shame.