Script# Programming in the Large

Some large-scale Ajax apps and frameworks - the Live Framework and Office 14, both announced at PDC - built using Script#...

Yesterday's PDC keynote featured a number of interesting products and technologies, such as Office 14 and Live Services, that today involve fairly large-scale (code size, team size and project length) Ajax development. The demos were just amazing - Kudos to the product teams!

Behind the scenes, on the engineering front, Script# provided the toolset and script authoring model. I've been working with both teams for quite a while now, and am really excited to be able to finally share these particular uses now that they are public (since to be honest, I was myself quite pleasantly surprised to see the model of compiling down to script scale up in this manner).

Live Mesh features an online desktop experience within the browser to enable remotely accessing files from any browser. The Live Framework exposes the underlying platform to .NET applications and script applications alike. The script framework portion of the SDK, like the UI, is based on Script#. The documentation for this framework on msdn was built from doc-comments in the originating c# code, which double up to enable script intellisense in Visual Studio.

Next in the keynote was a quick peek at what is to come in a web-ified Office 14. Some of the highlights included Excel, OneNote, and the Ribbon interface. These apps bring document sharing and collaboration to a whole new level. What is really cool is the live editing and continual sync'ing with the actual good-old, full-fidelity Office document file on the server or with another concurrent editing session in the full-blown desktop Office suite. These apps build on top of the ASP.NET Ajax framework, and were for the most part coded in c# and converted to javascript using script#.

The devs clearly recognized the value from using standard .NET tools and C# for engineering the thousands of lines of script and Ajax code that power these great consumer and developer experiences.

Posted on Wednesday, 10/29/2008 @ 2:34 PM | #Script#


Comments

19 comments have been posted.

Philip the Duck

Posted on 10/29/2008 @ 6:32 PM
That's awesome, Nikhil - congratulations, it's always nice to see "your baby" being appreciated and used for serious purposes.

So, does this mean Script# will soon be coming "out of the closet" and become an official part of .NET 4.0 / ASP.NET 4.0 / AJAX ?

Faraz Shah Khan

Posted on 10/29/2008 @ 10:33 PM
Indeed Live Mesh is one great thing specially when you actually see 2 distinct computers in 2 different countries synchs seemlessly. The way this Live Mesh helps me I am very happy with it. Here one suggestion I want to place I tried the remote access but I found it a little slow as compared to some other Web Remote Access tool. I believe it can pace up the speed if we have option to change the quality of picture as low/medium/high and color/black and white. It will really work. Since it tried to get the display in High Quality its little slow on my side. Pardon me if this option is there and I couldn't find it :)

thanks and best of luck.

zproxy

Posted on 10/29/2008 @ 11:44 PM
congratulations :)

dummy_customer

Posted on 10/30/2008 @ 12:44 AM
Hmmm....... Script# is becoming more and more interesting. I think I'll give it a try. And congrats Nikhil. Nice to see your tech is being used in such a big way.

dummy_customer

Posted on 10/30/2008 @ 12:56 AM
One question comes to mind though? Isn't Microsoft scared that the Office Web application can be more easily copied, because it's a Browser based JavaScript/Ajax application?

How do you intend to protect your intellectual property? Or do you think the current state of technology already allows competitors to build 'slick' Office Web Clones (and therefore don't care). And I emphasize slick, because a lot of Office Web Clones are just well..... 'sub-prime' :P

I think the industry needs an obfuscator for JavaScript!

Salman Farsi

Posted on 10/30/2008 @ 2:30 AM
Amazing...Its mean Script# is going to play important role and replace some existing technologies. Congratulations to you, Nikhil.

Steve

Posted on 10/30/2008 @ 6:31 AM
I would really like to see you include jQuery - the syntax of jQuery is very easy to work with. (Especially after the announcement of it's inclusion into asp.net mvc - I take that as 'MS adoption' - lol)

Selectors, etc... are very easy to work with and the ubiquitous style of attaching to elements without cluttering the html is extremely powerful.

Some questions:
1. Any samples of using this with asp.net mvc ? how to build it with mvc, etc...

2. In many senario's I need ajax calls on 'lists' dynamically built at runtime with in place editing where I want to use javascript.

I'm having a hard to wrapping my head around how you would do this in Script# since the whole nature of this is dynamically attaching to elements at runtime, etc... ?

I haven't used asp.net webforms in over a year - primarily doing asp.net mvc or even Silverlight. I'd like to see the pdf documentation show how to use your Script# on non-webform applications.

Is this possible?

Great work

Nathan Totten

Posted on 10/30/2008 @ 2:33 PM
Script# is awesome. I am looking forward to the future releases and jQuery support.

Thanks for taking the time to make this tool.

BjartN

Posted on 10/31/2008 @ 12:08 AM
Sweet ! I saw on your Script# project site that unit testing is coming soon. How soon ? Can we hope for a DI framework as well ?

secretGeek

Posted on 10/31/2008 @ 4:42 AM
good stuff Nikhil!

Dave Townsend

Posted on 11/1/2008 @ 5:55 PM
Thanks Nikhil , When can we get a framework?

Nikhil Kothari

Posted on 11/1/2008 @ 7:43 PM
@BjartN - unit testing is still in the works. I'd really like to get it out soon - I need to work on a few different ends in terms of features and getting releases out before I have a more definitive ETA...

@Dave Townsend - could you tell me what specfic framework you're looking for? jQuery support is same as the unit testing answer above. Script# also supports asp.net ajax. Script# has its own framework as well, if you'd like (the Live Framework uses it).

bbqchickenrobot

Posted on 11/10/2008 @ 5:32 PM
I cannot seem to find script# on the codeplex site anymore? Simple mistake? Is it going live at M$? Also, some simple tutorials and documentation would really help new comers a lot!

Nikhil Kothari

Posted on 11/10/2008 @ 9:42 PM
Working on getting back some forums capability for script# - please stay tuned.
For documentation, I'd recommend checking out the pdf on the script# project site, as well as the samples.zip that is installed when you install script#. I know these could use more work, but they're still useful for the new comers... I think.

kreester

Posted on 11/18/2008 @ 3:55 AM
Great stuff - I have an .js API from a 3rd party that i would like to convert into Script#, is there a simple way to do this - the documentation is unclear.
It seems i have to manually create the reference assembly myself. Thanks

Nikhil Kothari

Posted on 11/19/2008 @ 12:00 AM
@kreester - the answer, somewhat unfortunately is yes - there isn't a script parser that will generate an import.

lubos

Posted on 11/19/2008 @ 3:47 AM
I know that S# supports methods overloading by [AlternateSignature]. I'm wondering is there any way how to implement overloading of constructors and methods in interfaces?

S# is great piece of work. best of luck

Abhinav Vohra

Posted on 12/10/2008 @ 9:25 AM
Hi Nikhil
We've been using S# since 0.4.5 and have built our complete UI framework with it. Now we've been looking to develop our client code on non -windows environments using Mono 2.01 and monodevelop.

The IDE is able to read the sln and csproj files but I run into the following issue when I try to compile without mscorlib.

Any thoughts?

Abhi

Unhandled Exception: System.TypeLoadException: Could not load type 'System.Object' from assembly 'sscorlib, Version=0.5.1.0, Culture=neutral, PublicKeyToken=8fc0e3af5abcb6c4'.
at (wrapper managed-to-native) System.MonoType:GetMethodsByName (string,System.Reflection.BindingFlags,bool,System.Type)
at System.MonoType.GetMethods (BindingFlags bindingAttr) [0x00000]
at Mono.CSharp.MemberCache.AddMethods (BindingFlags bf, System.Type type) [0x00000]
at Mono.CSharp.MemberCache.AddMethods (System.Type type) [0x00000]
at Mono.CSharp.MemberCache..ctor (IMemberContainer container) [0x00000]
at Mono.CSharp.TypeHandle..ctor (System.Type type) [0x00000]
at Mono.CSharp.TypeHandle.GetTypeHandle (System.Type t) [0x00000]
at Mono.CSharp.TypeHandle.GetMemberCache (System.Type t) [0x00000]
at Mono.CSharp.TypeManager.LookupMemberCache (System.Type t) [0x00000]
at Mono.CSharp.MemberCache..ctor (System.Type baseType, IMemberContainer container) [0x00000]
at Mono.CSharp.TypeContainer.DoDefineMembers () [0x00000]
at Mono.CSharp.Class.DoDefineMembers () [0x00000]
at Mono.CSharp.TypeContainer.DefineMembers () [0x00000]
at Mono.CSharp.RootContext.PopulateTypes () [0x00000]
at Mono.CSharp.Driver.Compile () [0x00000]
at Mono.CSharp.Driver.Main (System.String[] args) [0x00000]
make[1]: *** [bin/FrameworkScripts.dll] Error 1
Post your comment and continue the discussion.