Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Jul 29, 2008 09:04 AM by dodygunawinata
Jun 15, 2008 11:53 AM|LINK
The last update to IronPython for ASP.Net was back in July 2007. There hasn't been any movement for almost a year now.
Jun 15, 2008 12:13 PM|LINK
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:
Jun 15, 2008 01:11 PM|LINK
Jul 04, 2008 12:23 AM|LINK
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?
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,
Jul 04, 2008 10:25 AM|LINK
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
Jul 04, 2008 10:39 AM|LINK
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.
Jul 04, 2008 07:36 PM|LINK
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).
Jul 05, 2008 09:57 AM|LINK
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.
Jul 05, 2008 03:39 PM|LINK
No, it only reprocesses the aspx files when they have changed, so for the majority of requests it's very fast.
Jul 06, 2008 08:27 AM|LINK
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?