Command line compiler doesn't work in 64bit process

Hi,

We are using the command line compiler to implement our own ASP.NET IBundleTransform so we need to run it in-process. This is more or less the code we use. The problem is that the command line tool is set as 32bit binary. Would you guys be able to release a 64bit version of it ?

  var files = Directory.EnumerateFiles(sourcePath, "*.less", SearchOption.AllDirectories).Where(f => !Path.GetFileName(f).StartsWith("_")).ToArray();
            var s1 = Stopwatch.StartNew();
            foreach (var f in files)
            {
                CommandLineCompiler.Run(new[] { f }, (p, c) => File.WriteAllText(p, c), (s) => Console.WriteLine(s));
            }

Thanks a lot for your work. We are nearly where we want to be :). It looks like those guys managed to package V8 into both 32 and 64 bit assemblies: http://javascriptdotnet.codeplex.com/

BTW. We switched to LESS and our compilation time dropped from 30sec to 0.6sec.

Pawel

BTW. We switched to LESS and our compilation time dropped from 30sec to 0.6sec.

Same here. The default template for .scss should be a warning saying that you're about to screw yourself and to use .less instead.

That Ruby-based tool is some sort of bad joke. I can't believe the tooling the Ruby guys put up with. The 37 signals guys preach from the top of the mountain and credit Frank Lloyd Wright as inspiration. Meanwhile they're rubbing two wet sticks together trying to build a fire.

I believe Ruby on Mac is muuuuuuuuuuuuuuuuch faster.

Regarding Sass compilation speed, the issue isn't Ruby; it's IronRuby. In current nightlies we've switched over to Ruby proper, and we're now seeing compilation times comparable to Less. Your mileage may vary of course...!

We all run 64-bit Windows here and we are able to run the command line compiler fine... from the command line.

Hosting the compiler EXE file as a DLL in your own process is rather outside the scope of what we were aiming to support. The implementation of the command line compiler is undocumented and we make no promises that it will remain stable from version to version -- to be honest the only reason the classes are even public is because our test suite uses them and it was easier than mucking around with InternalsVisibleToAttribute!

I'll talk to the powers that be about whether we want to make the compiler hostable, but for the time being I'd suggest you shell out to the EXE using Process.Start -- not as efficient, I know, but it will solve the 32/64-bit problem and it means we won't unexpectedly break your code if/when we change the command line internals!

That's what we are using but it feels like a hack to start a console app in a web app :). I really like Sass/Less and I'm not coming back to Css. Having a VS based editor and a seamless and fast integration with MVC it my ultimate goal. In this way I could convince more of my clients that CSS is a matter of the past :)

BTW, the compiler does not work on boxes without VS installed. You need this to make it happy: http://www.microsoft.com/en-us/download/details.aspx?id=5555

Hi Guys,

I'm giving a talk at a user group at the end of this month and I want to show how to do Less correctly (VS + runtime transform). Is there any chance you will have 64bit version ready by then? Even early version is fine.

Thanks

Pawel

I'm not sure that calling a DLL that wraps an EXE that hosts javascript that loads a script that converts a static file to a different static file -- inside your IIS process -- shows "how to do Less correctly."

Because, really: why spend a tenth of a second building and minifying it in VS on your dev machine by checking a box when you can write and maintain code using a beta API and shell out to a convoluted third party process from your server app?

If you want to make a tech demo why not call less.js from node.js inside IIS? I'm still not sure of the value, but at least you get 3x the buzzwords in your presentation.

https://github.com/tjanczuk/iisnode/wiki

Hi Pawel,

We've discussed this internally but I don't think it's something we're going to be added specific support for. There are other libraries available for runtime compilation such as dotless.

We're focused on building the best toolset for Sass/Less/CoffeeScript for Visual Studio.

Kind regards,

John-Daniel

@chadw, sometimes it makes sense to ask questions instead of making wrong assumptions.

Anyway, the command line compiler uses the same code as the VS plugin so I'm not sure where did you get "Beta" from. The main reason why I want to use the compiler is to make sure I use the same tool(code) in VS and at runtime. The reason why this is important is explained here: http://www.mindscapehq.com/forums/thread/278891. Nodejs is an option but it is another dependency. Minscape guys are nearly there so that's why I asked for 64 bit version of the tool. I don't want to develop it myself as I'm not in the business of writing dev tools and I'm happy to pay for it as long it does what I need it to do.

@john-daniel, Using dotLess(runtime) and less.js (Workbench) at the same time is simply asking for trouble. I can imagine that both implementation are slightly different and debugging the differences is going to be a nightmare.

I explained here (http://www.mindscapehq.com/forums/thread/278891.) why VS based solution can cause trouble but I understand your decision. Thanks for all the hard work.

Thanks

Pawel

System.Web.Optimization / IBundleTransform is the beta API I was referring to.

I don't get that whole framework frankly. I remain a bit confused why bundling static assets should happen 180 times across my web farm instead of once on my build server.

Reading your other post it seems you're doing this to keep your developers from modifying the .css files instead of the .less files and checking them in to source control? Dealing with generated files is a pretty common engineering situation. If you think the solution is to push the build out to IIS (!!!) you may want to reconsider other options.

To be honest I don't pay too much attention to the fact that something is marked as beta/RTM/RC/etc. All I care about is that it works. Many OS projects are marked as "beta" and people use it in Prod.

Personally I think that keeping auto-generated files in the source control is a bad idea. The main reason behind it is that the source of truth (Less) can diverge from its auto-generated counterpart (Css).

I don't run Facebook and I can spare 0.6sec. At the moment my main goal is correctness and quick feedback cycle so my team can go as fast as possible.