12 Comments

As documented in recent posts, I've been tinkering getting the LESS and CoffeeScript compilers running on Windows Script Host. I've now got round to wrapping these up as ASP.NET HTTP Handlers so you can easily use them in ASP.NET-based websites. You simply reference the *.less and *.coffee files and they get served up as CSS and JavaScript directly. For example:

<link href="content/style.less" rel="stylesheet">
<script src="content/site.coffee"></script>

No need to install add-ins into Visual Studio or add build steps to your project. The main downside is that it won't run on non-Windows platforms under Mono (although I'm tempted adapt it to use Mozilla's SpiderMonkey JavaScript Shell).

If you're running Visual Studio 2010 then simply use the LessCoffee NuGet package.

PM> Install-Package LessCoffee

If you're using Visual Studio 2008 you'll need follow these manual steps:

  • Copy LessCoffee.dll to your web application's /bin directory
  • Add the following entries to your web.config file:
    <system.web>
        <httpHandlers>
            <add path="*.coffee" type="DotSmart.CoffeeScriptHandler, LessCoffee" verb="*" validate="false"/>
            <add path="*.less" type="DotSmart.LessCssHandler, LessCoffee" verb="*" validate="false"/>
        </httpHandlers>
    </system.web>

    <!-- IIS 7 -->
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
        <handlers>
            <add path="*.coffee" type="DotSmart.CoffeeScriptHandler, LessCoffee" verb="*" name="DotSmart.CoffeeScriptHandler"/>
            <add path="*.less" type="DotSmart.LessCssHandler, LessCoffee" verb="*" name="DotSmart.LessCssHandler"/>
        </handlers>
    </system.webServer>

If you're using Windows 2003/IIS 6 then you will need to map the file extensions *.less and *.coffee to aspnet_isapi.dll.

The source is on GitHub, obv: https://github.com/duncansmart/LessCoffee

4 Comments

With the release of IronJS 0.2, the code below is the result of a 30-minute play I had this morning, which shows how easy it is to embed a fully .NET JavaScript runtime in your application by simply referencing IronJS.dll.

It’s changed quite a from prior versions and I think you’ll see it has become much easier to host since  Dan Newcombe’s experiments last year.

//reference IronJS.dll
using System;
using System.IO;

class IronJsDoodles
{
    static void Simple()
    {
        var context = new IronJS.Hosting.CSharp.Context();
        object result = context.Execute("1 + 2;");

        Console.WriteLine("{0} ({1})", result, result.GetType());
        // "3 (System.Double)"
    }

    static void InteractingWithGlobal()
    {
        var context = new IronJS.Hosting.CSharp.Context();

        context.SetGlobal("a", 1d);
        context.SetGlobal("b", 2d);
        context.Execute("foo = a + b;");

        double foo = context.GetGlobalAs<double>("foo");

        Console.WriteLine(foo);
        // "3"
    }

    static void AddingHostFunctions()
    {
        var context = new IronJS.Hosting.CSharp.Context();

        // Effectively the same as context.CreatePrintFunction() :-)
        var print = IronJS.Native.Utils.createHostFunction<Action<string>>(context.Environment,
            delegate(string str)
            {
                Console.WriteLine(str);
            });
        context.SetGlobal("print", print);

        context.Execute("print('Hello IronJS!')");
    }
}

Hope it helps you get started.

29 Comments

I tried to find some mechanism to get the current machine's NetBIOS domain name (the machine domain, not user domain), but couldn’t find anything in the usual places (e.g. System.Environment). If you want the fancy-schmancy Active Directory DNS domain then you can use Domain.GetComputerDomain().Name from System.DirectoryServices.ActiveDirectory, or another one that I stumbled across in Reflector was IPGlobalProperties.GetIPGlobalProperties().DomainName that lives in System.Net.NetworkInformation. But a simple way of getting the old-skool NetBIOS/LanManager-style machine domain name proved elusive.

Some googling suggested that WMI would provide the answer but I find WMI a little heavyweight, and not always reliable. The information is also probably in the registry somewhere, although I couldn’t find it after a cursory scan. The proper, supported way it would appear is to use the Network Management API. So my solution entailed P/Invoking to netapi32.dll.

If you’re after the same information I hope you find the code below useful. Once you've incorporated this in your project, just call the GetMachineNetBiosDomain method. It will return the machine's Workgroup name if the machine is not domain-joined.

UPDATE: Now works on 64-bit thanks to update sent by Rp Brongers.

using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

class NetUtil
{
    [DllImport("netapi32.dll", CharSet = CharSet.Auto)]
    static extern int NetWkstaGetInfo(string server,
        int level,
        out IntPtr info);

    [DllImport("netapi32.dll")]
    static extern int NetApiBufferFree(IntPtr pBuf);

    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
    class WKSTA_INFO_100
    {
        public int wki100_platform_id;
        [MarshalAs(UnmanagedType.LPWStr)]
        public string wki100_computername;
        [MarshalAs(UnmanagedType.LPWStr)]
        public string wki100_langroup;
        public int wki100_ver_major;
        public int wki100_ver_minor;
    }

    public static string GetMachineNetBiosDomain()
    {
        IntPtr pBuffer = IntPtr.Zero;

        WKSTA_INFO_100 info;
        int retval = NetWkstaGetInfo(null, 100, out pBuffer);
        if (retval != 0)
            throw new Win32Exception(retval);

        info = (WKSTA_INFO_100)Marshal.PtrToStructure(pBuffer, typeof(WKSTA_INFO_100));
        string domainName = info.wki100_langroup;
        NetApiBufferFree(pBuffer);
        return domainName;
    }
}

41 Comments

Like most .NET developers,  I used to do VB/VBA coding before C# came along. But, one thing I always missed in in the C# code editor was the lines that the VB editor puts between methods. An an avid user of CodeRush and Refactor! Pro, which itself does code structure painting in Visual Studio, I've created a DxCore Plugin that draws lines between methods which (IMHO) improves on the ones in the VB code editor.

Here's a screen shot of it in action:

Draw Lines Between Methods - in action

And here's the exciting options page:

Draw Lines Between Methods - settings

Even if you're a VB.NET person you might like to try it to see if it works any better for you than VB's built-in lines (although I guess you'd need to turn off the built-in method-separating lines somewhere in Tools Options).

The project is hosted on Rory Becker's DX Core Community Plugins Google Code project, where you can download the source and binaries.

Let me know how you get on with it in the comments :)

2 Comments

One the first issues that you have to deal with when writing unit tests is - where do I put the the tests? Here's where I prefer to have them: as close to the code that's being tested as possible, like so:

tests behind 1

The tests class is hooked up to the original source file in the same way that ASP.NET code-behind files are, as a dependent project item.

You can do this by hacking the *csproj file directly using the <DependentUpon> tag, but to automate it I've written a Visual Studio macro (works in Visual Studio 2008, should work in Visual Studio 2005) that creates an appropriately-named tests class that can be invoked like so:

Here's the macro code (copy and paste into a code module in the Visual Studio Macros IDE: Tools > Macros > Macros IDE)

Sub AddTestsFile()
   Dim item As ProjectItem = DTE.SelectedItems.Item(1).ProjectItem
   Dim fileName As String = item.FileNames(1)
   Dim dir As String = System.IO.Path.GetDirectoryName(fileName)
   Dim bareName As String = System.IO.Path.GetFileNameWithoutExtension(fileName)
   Dim newItemPath As String = dir & "\" & bareName & ".Tests.cs"

   Dim codeClass As CodeClass = findClass(item.FileCodeModel.CodeElements)
   Dim namespaceName As String = codeClass.Namespace.FullName

   System.IO.File.WriteAllText(newItemPath, "" _
     & "#if DEBUG" & vbCrLf _
     & "using System;" & vbCrLf _
     & "using System.Diagnostics;" & vbCrLf _
     & "using NUnit.Framework;" & vbCrLf _
     & "" & vbCrLf _
     & "namespace " & namespaceName & vbCrLf _
     & "{" & vbCrLf _
     & "   [TestFixture]" & vbCrLf _
     & "   public class " & codeClass.Name & "_Tests" & vbCrLf _
     & "   {" & vbCrLf _
     & "       " & vbCrLf _
     & "   }" & vbCrLf _
     & "}" & vbCrLf _
     & "#endif" & vbCrLf _
    )

   ' Add as sub-item and show
   Dim newItem As ProjectItem = item.ProjectItems.AddFromFile(newItemPath)
   newItem.Open().Activate()

End Sub

' Utility used by AddTestsFile
Function findClass(ByVal items As System.Collections.IEnumerable) As CodeClass
   For Each codeEl As CodeElement In items
      If codeEl.Kind = vsCMElement.vsCMElementClass Then
         Return codeEl
      ElseIf codeEl.Children.Count &gt; 0 Then
         Dim cls As CodeClass = findClass(codeEl.Children)
         If cls IsNot Nothing Then
            Return findClass(codeEl.Children)
         End If
      End If
   Next
   Return Nothing
End Function

The right-click Project Item context menu shortcut can be wired up to the macro with the help of Sara Ford's tip about customizing Visual Studio context menus.

Update 11 March 2008: Fixed findClass subroutine which resulted in null reference error, it now recurses correctly.