Package and Compress with Google Closure via MSBuild 0

The Problem

So our problem is we are building a library of JavaScript files that we use all over the place. I’ve been pushing, on the project where I’m the sole developer, to wrote 99% of the JavaScript as jQuery plugins. This works great because we can compile that 99% into a single file, or to reverse the perspective, we can split that huge file into smaller, more manageable and logical files.

For example, we have a file called jquery.mycompany.core.js which does a variety of mundane tasks. The file is huge, but unlike C# code, it’s huge for a reason. We want the browser to make as few requests as possible so there is less handshaking, less overhead, and faster page loads.

Previously we had several files and we manually combine them to one and then run it through some online compressing tool once we get close to production. This technically worked, but changes found a way of making their way into the huge file and the segmented files become out of date and obsolete.

The Hack

So here was my plan, take a list of file, concatenate them, and then compress them. Simple enough right? Well, it actually isn’t that bad

  <ItemGroup>
    <JavaScriptFiles  Include="scripts\jQueryPlugins\Custom\core\**\*.js" />
  </ItemGroup>

  <Target Name="Default" DependsOnTargets="BuildAndCompressOrdersJavaScript">

  </Target>

  <Target Name="BuildAndCompressJavaScript">
    <ReadLinesFromFile File="%(JavaScriptFiles.Identity)" >
      <Output
          TaskParameter="Lines"
          ItemName="lines"/>
    </ReadLinesFromFile>

    <WriteLinesToFile File="scripts\jquery.mycompany.core.uncompressed.js"
                      Lines="@(Lines)"
                      Overwrite="true" />

  </Target>

Not so bad right? Lastly, just add a bit of Google Closure. I just shell out and run it from the command line here.

<Exec Command='java -jar ..\compiler.jar --js scpts\jq.myco.core.un.js > scpts\jq.myco.core.js' />

I shortened some paths and filenames there so it would fit better in the blog’s column, but you get the idea.

I threw this into a post build event even though I could have added it to the csproj directly. The post build event was easier and it avoids those nasty warnings when you open the csproj.

The only issue I see with it right now is it is not as portable as I would like it to be. You pretty much company and past the build steps if you need to use it again. This is my major gripe about MSBuild. It’s difficult to create functions you repeat in the build.

This is a total cheapskate way to accomplish this task. I should be creating a nice parameterized MSBuild task, or even better, dump MSBuild for Rake. MSBuild and I acknowledge we are never going to be friends and have come to a professional arrangement. MSBuild does nothing to accommodate me and I do as little as possible with it.

Font Rendering in Visual Studio 2010 RC 0

I have to admit, I haven’t used Visual Studio 2010 much, and only recently have I made an effort to switch to it as my daily editor. One thing I’ve noticed is the font rendering in Visual Studio 2010 is a bit bolder than in 2008.

Here we have Visual Studio 2008 on the left and Visual Studio 2010 RC on the right. Both using similar font settings (Monaco 10pt)

image

It’s easy to see how the fonts in 2010 (on the right) look bolder and a bit blurry. From what I’ve read, WPF has had problem with Clear Type font rendering. This is the first WPF application I use with any appreciation. 

Windows 7 has a tool to help you tune your Clear Type settings. Just type “clear type” into the start search bar, and you should find the tool. It only takes a few moments, and the outcome was pretty surprising. I’ve very happy with the results after the calibration.

image

Visual Studio 2010 RC + ReSharper 5.0 + Xunitcontrib all in harmony….finally. 3

madmen_icon

Working on the bleeding edge is painful. Very painful at times. Throwing away our Team City builds because TFS 2010 didn’t support it really hurt. It was a big woops that I regret.

Moving to Visual Studio 2010 Beta was painful too. Visual Studio worked fine, but no ReSharper made it painful. Even in the early days, ReSharper was not stable in 2010, but after a few months, things look good now. ReSharper and VS 2010 are playing nice together.

There is one last pain point. No Xunit.net test runner. Xunitcontrib provides a ReSharper 5.0 build, but I was never able to get it to work…until now. Previously I was getting the same problem seen by others.

The plugin xunit could not be loaded from "C:\program files(x86)\jetBrains\resharper\v5.0\bin\plugins\xunit.dll" or one of its dependencies.  Operation is not supported.  (Exception from HRRESULT: 0×801311515)

I tried the best I could to right-click | Properties | Unblock all the files in the plug-in, but the “Unblock” never worked. I would get the same error. Going back into the properties dialog, the unblock would appear again. It looked like the unblock wasn’t sticking.

After a quick Google search, I found an alternative way to unblock files. Copy the files to a FAT 32 and back. The block is stripped. Sweet! My USB key is FAT 32, and after a quick copy and back. No more errors! ReSharper sees and runs my Xunit.net tests.

Just a quick overview of how I installed the plug-in:

  1. Close Visual Studio.
  2. Copy the contents of the ExternalAnnotations to:
    C:\Program Files (x86)\JetBrains\ReSharper\v5.0\Bin\ExternalAnnotations
  3. Create a folder:
    C:\Program Files (x86)\JetBrains\ReSharper\v5.0\Bin\plugins\xunitcontrib.runner.resharper.5.0
  4. Copy everything else to the USB key.
  5. Copy it to the folder I just created in step #3.
  6. Open Visual Studio and run all my tests.

Visual Studio 2010 Cassini / IIS Deltas 0

We’ve recently upgraded to the shiny new Visual Studio 2010 Beta 2. With the go live license we hope we can transition to the RTM once it drops. It has some nice features everyone already knows about.

First step to the future, the conversion. The conversion went pretty smooth. It doesn’t like the MVC 1.0 project, but that’s OK since it was just a shell placeholder. We plan on converting that to the MVC 2.0 before we get any real work in there.

After fixing a few minor things the conversion wizard missed, we fire up the app in Cassini….and it looks awful.image

OK, well maybe it doesn’t look awful, but it doesn’t look how our talented designers want it to look. It is mostly there. That bottom block should appear to the right of the login. Fire up the same VS 2010 project in IIS and it looks fine. image

Weird huh? Looking at the HTML there are a few differences between the two, but none that we would really expect to cause the two to render differently. Some URL’s were changed to absolute URL’s and include the hostname and port of each site. There are some view state differences, but nothing else.  Hmm…Why don’t we just stop using Cassini and debug through IIS.

There were just a few steps needed to set that up. First, tell Visual Studio to use a different server besides the development server.

image

Here we’ve already setup a host header IIS site and added dev.mysite.localhost do the hosts file. We have a hybrid of ASP.Net and classic ASP, so we already used ISS for a lot of testing.

Second step, run Visual Studio as administrator. You can default the shortcut to always run as administrator by editing the advanced properties of the shortcut.

image

That’s it. It looks like Visual Studio automatically attaches to the IIS process. The best part; It is a worlds faster than Cassini. I don’t know why you would debug through Cassini, unless you had to because you were missing either administrator privileges or missing IIS with your Home version of Windows.