Velen onder jullie die de ontwikkelingen van Script# volgen zullen gemerkt hebben dat het nogal stil is van de zijde van Nikhil Kothari. Vragen worden inde community gesteld of het nog wel verstandig is om Script# te gebruiken met betrekking tot de ondersteuning van Nikhil. Op het asp.net forum is er nu wat duidelijkheid gekomen. Nikhil heeft hier zelfs zelf gereageerd -sinds lange tijd-. Bottom line, Script# is niet dood!

Hieronder het antwoord van Nikhil zoals geplaatst op het asp.net forum:

This is going to be a short reply, until I can put out a better articulated blog post on the current status and what to look forward to in terms of new script# releases.

The project is not dead - just that its reached a temporary plateau of a stable release, with lots of teams using it successfully to get their job done. Yes, there are bugs, but I haven’t heard things that are fundamentally blocking from all the folks using it day to day. There are also some features people want, as well as things I’d like to get done, but that needs to be balanced with available resources.

There will be forthcoming releases. In fact just over the last couple of weeks I’ve been including a number of bug fixes for a release hopefully soon, my hope is before, but more realistically right after PDC. And then a subsequent quick turn around release adding support for all the new stuff added to asp.net ajax in 4.0.

Sorry for the lack of explicit updates… should have been messaged better. I was hoping for something more concrete to share than continually saying, yes, I am hoping for a new build in the Fall of ‘09

Thanks, Nikhil

Lees de voledige post hier.

Gisteravond vertelde ik bij de maandelijkse bijeenkomst van de dotNed gebruikersgroep over mijn ervaringen met Script# en haalde ik het inmiddels veel besproken Volta aan. Het was een prettige bijeenkomst waarbij zeker de mooie locatie een grote rol heeft gespeeld. InterAccess heeft als host wederom een erg goede indruk achtergelaten.

Ondertussen is inderdaad de aanzet gemaakt voor het schrijven van een codeproject.com artikel waarin Robertjan Tuit, Jasper Gilhuis en ik zullen beschrijven hoe je een projectstructuur zo opzet dat je op een eenvoudige wijze webcontrols kan schrijven met behulp van Script#. Matthijs Krempel (InterAccess) bracht ons op het idee om deze projectaanpak te plaatsen in een software factory en vervolgens te plaatsen op codeplex. Briljant plan! Eens zien hoe snel we hieraan toe komen.

Een ander project dat wij op Codeplex willen plaatsen, is de Script# compatibiliteitslibrary voor de Ajax Control Toolkit. Meer hierover zodra dit beschikbaar is en uiteraard alvast de uitnodiging om daaraan te zijner tijd mee te bouwen.

Zoals beloofd plaats ik mijn presentatie en gebruikte demos online en geef ik nog een opsomming van resources die van belang zijn.

Presentatie

• Presentatie Script# & Volta (powerpoint 97-2003)
• Presentatie Script# & Volta (powerpoint 2007)
• Script# presentatie demos (2,3,4 en 6)

Script# resources

• Script# project page van Nikhil Kothari (handleiding, source, installatie)
• Nikhil Kothari’s blog (meer dan alleen Script#)
• Script# and Microsoft ASP.NET AJAX Demo (channel9 screencast van Nikhil Kothari)
• Client-side Model-View-Presenter (channel9 screencast van Andrew Davey)
• Mobile MVP in MVP webapp (channel9 screencast van Andrew Davey)

Volta resources

• De Volta project page
• Erik Meijer: Volta - Wrapping the Cloud with .NET - Part 1 (channel9 interview)
• Erik Meijer: Volta - Wrapping the Cloud with .NET - Part 2 (channel9 interview with demo)
• Tier Splitting Volta: Who. What. How. Why - Part 1 (channel9 interview)
• Tier Splitting Volta: Who. What. How. Why - Part 2 (channel9 interview with demo)
• Building a Volta Control : A Flickr Widget (dotnetslackers artikel van Tanzim Saqib)
• Microsoft architect compares Volta and Google GWT (ZDNet artikel)
• Microsoft wriggles on Volta concerns (REGDeveloper artikel)
• Interview: Didier Girard, are GWT and Volta GCC for the Web? (InfoQ artikel)
• Tier Splitting C# Screencast (aboutcode.net van Andrew Davey)

Wanneer ik meer resources tegenkom, zelf maak of van jou te horen krijg, zal ik ze toevoegen aan de lijst welke je het eenvoudigst kan bekijken op mijn Links pagina.

Aankomende 24 januari zal ik bij de dotNed gebruikersgroep het hebben over Script# en Volta. Ik zal vertellen over Script#, wat het is en wat je er mee kan doen. Dit aan de hand van een aantal voorbeelden uit de praktijk. Het experiment Volta zal ik aansnijden en de mogelijkheden van het scheiden van de tiers bespreken met het publiek. Ik hoop dat ik samen met het publiek een inschatting kan maken of Volta zal doorbreken als mainstream toepassing?

De laatste keer dat ik het over deze onderwerpen had -afgelopen SDE- kreeg ik van iemand de vraag wat nu de correlatie is tussen Script# en Volta. Welnu, Volta vertaald IL-code naar Javascript en verzorgt op die manier de mogelijkheid om backendcode op een eenvoudige wijze naar de frontend te brengen. Maar Volta kan meer dan dat.

Maar nog even in het kort: Script# is een compiler waarmee je C# omzet in Javascript. Volta is een toolset die je in staat stelt om met native .net code een web-clientapplicatie neer te zetten waarbij je later pas hoeft te bepalen wat op welke tier wordt uitgevoerd.

De bijeenkomst, zoals altijd op de vierde donderdag van de maand, kan je gratis bijwonen nadat je je hebt aangemeld op de site van de dotNed gebruikersgroep.

Hoewel de komst van Volta op mij een grote indruk heeft gemaakt, heeft het blijkbaar Nikhil Kothari niet van zijn stuk gebracht. Zojuist heeft hij een nieuwe versie van Script# uitgebracht. Een belangrijke (en onvermijdelijke) toevoeging in deze versie is dat Script# nu geïnstalleerd kan worden in Visual Studio 2008. Afgelopen SDE heb ik nog staan te verkondigen dat het niet kon, nou ja, op zich was dat toen geen leugen.

Je kan de laatste versie van Script# - 0.4.5.0 - downloaden van Kothari’s website.

Robertjan heeft in een van zijn laatste posts aangekondigd dat ik met een paar code voorbeelden voor Volta zou komen. Nou, dat is inderdaad ook de bedoeling en deze zullen binnenkort ook komen. Eerst de feestagen overleven.

Het fenomeen dat er af en toe truncated Javascript output door de compiler wordt uitgespuwd, mag dan wel opgemerkt worden door Custom MsBuild Task uit mijn vorige post. Het lost het probleem nog steeds niet op. Nu blijkt dat Script# een probleem heeft met het gebruik van volledige namespaces binnen je code.

Gebruik niet

myNameSpace.myClass a = new myNameSpace.myClass();

Maar liever

using myNameSpace;
myClass a = new myClass();

Dit lijkt in veel gevallen de oorzaak van de truncate! Er kunnen nog andere oorzaken zijn, dus let op!

Zoals ik in een vorige post al opmerkte, gebeurt het wel eens dat een Script# compile ogenschijnlijk werkt. Uiteindelijk blijkt dat een groot deel van de compiler output niet is weggeschreven in het resulterende Javascript bestand. Om er voor te zorgen dat je toch een compiler melding krijgt heb ik hier een voorbeeld van een Custom MsBuild Task die je kan gebruiken.

Download CheckCompleteCompile source en binaries.

Pas je .csprj bestand aan met de volgende code (plak dit gewoon aan het einde van het bestand, maar nog wel binnen de </Project> tag) :

  <UsingTask TaskName=”CheckCompleteCompile.Check”
	AssemblyFile=”path\to\CheckCompleteCompile.dll” />
  <Target Name=”AfterBuild”>
    <Check FileName=”$(TargetPath)” />
  </Target>

Zorg dat je niet vergeet het pad naar de CheckCompleteCompile.dll aan te passen.

Zodra nu het Javascript-output bestand NIET de regel  ‘// —- Do not remove this footer —-” bevat, verschijnt de melding:

“** COMPILE FOOTER IS NOT FOUND IN JAVASCRIPT OUTPUT!! **

Nu weet je zeker of je output volledig is of niet.
Voel jezelf uitgenodigd om aanpassingen/verbeteringen te maken en laat het me weten!.

Over het algemeen werkt de Script# compiler (versie 0.3.0.0) afdoende om de meest gangbare C# code om te zetten naar JavaScript. De volgende code echter niet:

   1:  using System;

   2:   

   3:  namespace TestClasses

   4:  {

   5:   

   6:      public class ClassA

   7:      {

   8:          private static ClassA _classa;

   9:          public static ClassA Empty

  10:          {

  11:              get

  12:              {

  13:                  if (_classa == null)

  14:                      _classa = new ClassA();

  15:                  return _classa;

  16:              }

  17:          }

  18:      }

  19:   

  20:      public class ClassB

  21:      {

  22:          private ClassA _classa;

  23:          public ClassA ClassA

  24:          {

  25:              get

  26:              {

  27:                  if (_classa == null)

  28:                      return ClassA.Empty;

  29:                  else

  30:                      return _classa;

  31:              }

  32:              set { _classa = value; }

  33:          }

  34:      }

  35:  }

 De foutmelding die hierbij wordt gegeven is :

Error 1 The “ScriptCompilerTask” task failed unexpectedly.
nStuff.ScriptSharp.Preprocessor.PreprocessorException:
Unable to resolve or open included file ‘%code%’ …

De oorzaak van de fout zit hem in de regels 23 of 28. Wanneer je de property ClassB.ClassA hernoemt naar iets dat niet overeenkomt met de typenaam van de property (bijv. ClassB.classa), of door het retourneren van de static ClassA.NullType weg te halen dan compileert het prima.

Dit fenomeen kan ook resulteren in de melding dat de compile gelukt is, maar dat de output in de vorm van het javascript bestand niet geheel compleet is.

Overigens, controleer sowieso of het javascript resultaat compleet is door te kijken of de commentaarregels van Script# de laatste regels zijn. Dit zou je prima kunnen automatiseren met een Custom MsBuild Task zoals ook beschreven in mijn post van 4 juli “Oplossing ‘numeric constant overflow’ in Script#.

Bij het gebruik van Script# is het nodig om de framework js-bestanden te includen. Nu is het geval dat wanneer men gebruik maakt van het BackBase framework, een bestand als ssfx.Core.js niet kan includen.
Dit heeft te maken met punt tussen ssfx en Core. Het enige wat je hoeft te doen is het bestand ssfx.Core.js hernoemen naar ssfxCore.js en het probleem is uit de wereld.
Constateer je dit fenomeen ook bij andere frameworks, laat het me weten!

Nu ik al een tijdje Script# gebruik en het anderen ook in hun schoot gooi, kon het niet uitblijven dat er bugs boven komen drijven. Zo kreeg een collega van mij de compiler melding: “Numeric constant overflow“. Dit trad op plekken op waar code stond zoals het eenvoudige:

private double a = 3.4;

Na wat speurwerk vond ik een soortgelijke bugmelding op de site van Nikhilk Kothari. En ook bij ons kwam deze melding voort uit het probleem van landinstellingen die verschillen per werkstation. Mijn collega had zijn landinstellingen op nederlands staan en ik op engels.

De Script# compiler ssc.exe (versie 0.3.0.0) blijkt nog niet goed om te gaan met afwijkende landinstellingen.

Nu kan je natuurlijk dit probleem snel oplossen door de instellingen op engels te zetten en vrolijk doorgaan met compilen. Nou ja, dit lijkt niet de oplossing die men wil horen. Een andere oplossing is een Custom MsBuild Task te maken en deze ervoor te laten zorgen dat de CurrentCulture van de huidige Thread op CultureInfo(”en-US”) wordt gezet. Deze custom task moet dan elke keer voor de compile worden uitgevoerd, et voila.

Plak de volgende regels onderin je script# project file:

<UsingTask TaskName=”envTask.SetLocalEnglish”
	AssemblyFile=”path\to\envTask.dll” />
<Target Name=”BeforeBuild”>
    <SetLocalEnglish />
</Target>

De assembly envTask.dll bestaat uit de volgende code:

using System;
using System.Globalization;
using System.Threading;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace envTask
{
    public class SetLocalEnglish : Task
    {
        public override bool Execute()
        {
            Thread.CurrentThread.CurrentCulture =
			new CultureInfo(“en-US”);
            return true;
        }
    }
}

Toegeven, het is niet de meest elegante manier, maar toch wat mooier dan elke keer handmatig je regional settings aan te passen. Nu maar wachten op een versie van Script# waar dit in is opgelost. 

Hoe smerig het plaatsen van business logic in je UI laag ook klinkt, er zijn momenten dat je er toch voor mag kiezen. Neem de volgende situatie:

Een website die een online hypotheekberekening aanbiedt geeft de gebruiker de mogelijkheid om met ’slider-controls’ voor eigen inkomen, inkomen van de partner en koopsom van de woning te bepalen hoe hoog de maximale hypotheek is. Door de sliders te bewegen verandert uiteraard de hoogte van het maximum hypotheekbedrag. Maar niet alleen het hypotheekbedrag wijzigt. Wanneer je je inkomen te laag zet met de slider, is het ook goed mogelijk dat de maximale koopsom wordt verlaagd.

De rekenregels die nodig zijn voor de bepaling van de samenhangende bedragen, moeten aan de cliëntzijde aanwezig zijn om een snelle UI respons te bewerkstelligen (dit wordt uiteraard makkelijker met Silverlight). Goed, dit is een prachtig moment om Script# uit de kast te halen.

Wanneer je met Script# je rekenregels hebt geschreven (middels een Script# ClassLibrary) , dan beschik je al meteen over een C# codebase. Wat is er nu mooier dan deze code te gebruiken aan de serverzijde, in je domein zelfs. Je weet meteen zeker dat je aan beide zijden dezelfde code gebruikt.
Eén van de voordelen van Script# is dat er na een compile zowel een .js-bestand als een .net assembly wordt gecreëerd.

De .net assembly ga je gebruiken in je andere projecten. Je maakt de reference, schrijft de code die de assembly consumeert en compileert… En dan ineens wordt je geconfronteerd met de melding:

The type ‘System.Object’ is defined in an assembly that is not referenced. You must add a reference to assembly sscorlib …

Je denkt dus dat je in het project waarin je de Script# .net assembly referenced een reference moet maken naar de Script# sscorlib. Op zich juist, alleen dit zal waarschijnlijk onder andere resulteren in een melding als:

The type ‘System.Reflection.AssemblyVersionAttribute’ exists in both ’sscorlib.dll’ and ‘mscorlib.dll’

En dat spreekt eigenlijk voor zich. Er zijn nu twee frameworks referenced in je project, met beide dezelfde namen voor uiteenlopende zaken (Script# is immers een port van het .net framework naar JavaScript).
Om dit snel op te lossen kan je een tweede project aanmaken voor je Script# project. maar dan met het C# ClassLibrary template. Zorg ervoor dat het gegenereerde .csprj bestand in dezelfde directory staat als het Script# project. Voeg alle .cs bestanden toe aan je C# project die ook in het Script# staan. De projecten die voorheen verwezen naar de Script# .net assembly laat je nu verwijzen naar de nieuwe C# assembly. Et voila! Twee projecten op twee verschillende frameworks, één codebase.
Voor de echte die-hard moet er natuurlijk een oplossing mogelijk zijn in het MS Build script (ofwel het .csprj bestand) om hetzelfde te bewerkstelligen. Ik hoor het graag van je….