Scott Hanselman geeft aan dat hij voor Scot Guthrie bij Microsoft gaat werken. Zelf geeft hij aan dat hij niet verwacht dat zijn stijl van bloggen zal veranderen, ik denk dat het hem wel zal gaan lukken al verwacht ik wel dat de frequentie van zijn posts zal afnemen. Succes Scott!

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.