Shared posts

03 Sep 11:03

Introducing Gulp, Grunt, Bower, and npm support for Visual Studio

by Scott Hanselman

Web Development, specifically front end web development, is fast becoming as complex and sophisticated as traditional back end development. Most projects don't just upload some JS and CSS files via FTP. There's now a front end build process that can include expansion of SASS and LESS, minification of CSS/JS, running JSHint or JSLint, and much more. These build tasks and processes are coordinated with tools like Gulp and Grunt. Additionally, client-side libraries are managed as packages using management systems like npm and bower.

Why client-side package managers for ASP.NET? Why not NuGet? Why not MSBuild?

Some of you may ask, why not use NuGet for JavaScript? Why not extend MSBuild for building CSS/JS? Simple. Because there's already a rich ecosystem for this kind of thing. NuGet is great for server side libraries (and some client-side) but there are so many more CSS and JS libs on npm and bower. MSBuild is great for server-side builds but can be overkill when building a client-side app.

So, use both. These are tools in your toolkit. Adding support for Gulp, Grunt, Bower, npm (and other stuff, in the future if needed) means a more familiar environment for front-end devs doing ASP.NET and it opens the doors for ASP.NET devs to bring in the JS and CSS libraries communities use every day.

Introducing Task Runner Explorer

We’ve received a ton of feature requests regarding Grunt/Gulp support from many of you as well as the community at large. We are building first-class support for both Grunt and Gulp in Visual Studio “14” with full extensibility. Now we’re ready to ship a preview of this support as an extension to VS2013 and would appreciate your help testing and exploring this feature. 

Today we're introducing a preview of the "Task Runner Explorer" as a VSIX extension. We're also recommending two other VSIXs to round out the experience for this feature.

NOTE: Much of the functionality included in these multiple VSIX extensions will be built into Visual Studio so you won't need to install so many things. However, for VS2013 and this preview we needed multiple VSIXs in order to get you the bits sooner than later. Also note that today only Task Runner Explorer will work on Visual Studio Express but for VS14 all  the features will work in the free VS Express version.

Consider these features as a "DevLabs" preview for now, much like the VS Productivity Power Tools. They'll graduate into the final product.

What do you need?

First, you'll need Visual Studio 2013.3 - that 3 means "Update 3" which is a free update.

  1. TRX - Task Runner Explorer Visual Studio Extension
  2. NPM/NBower Package Intellisense - Search for online NPM and Bower packages directly with Intellisense
  3. Optional Grunt Launcher (gives right-click options in Solution Explorer - including "npm install")
    • Without this extension, for now you'll need to run npm install yourself to restore/add packages.
    • If you DO have this extension, right click on packages.json and "npm install" before running a grunt/gulp task.

To open the TRX (Task Runner Explorer), simply right-click any gruntfile.js in your project:

image002 

The TRX sits at the bottom of VS by default and looks like this:

 image001

Here we can see that it found a gruntfile.js in the root of one or more projects in the solution. It also shows the task bindings feature that allows any task or target to be triggered by 4 different Visual Studio events.

To associate a task/target with a VS event, just right-click and setup bindings.

image003

To run any task/target, just double-click it and a console appears:

image004

When you've got the Package Intellisense Extension you'll find it easy to add and update packages when directly editing your package.json for both bower and npm.

completion-name

You'll even get metadata tooltips populated asynchronously.

tooltip-animated

As you go testing it, remember you'll need to run "npm install" before you use the Task Runner Explorer to run Grunt tasks.

Big thanks to Mads Kristensen, Dan Chartier, and Van Kichline for their great work on this feature!


Sponsor: Many thanks to Intersoft for sponsoring the feed this week! Enterprise cross-platform native apps development made painless with Intersoft Crosslight. Sounds too good to be true? See it for yourself and get started today! 



© 2014 Scott Hanselman. All rights reserved.
     
27 Aug 09:00

How to run Background Tasks in ASP.NET

by Scott Hanselman

A few years back Phil Haack wrote a great article on the dangers of recurring background tasks in ASP.NET. In it he points out a few gotchas that are SO common when folks try to do work in the background. Read it, but here's a summary from his post.

  • An unhandled exception in a thread not associated with a request will take down the process.
  • If you run your site in a Web Farm, you could end up with multiple instances of your app that all attempt to run the same task at the same time.
  • The AppDomain your site runs in can go down for a number of reasons and take down your background task with it.

If you think you can just write a background task yourself, it's likely you'll get it wrong. I'm not impugning your skills, I'm just saying it's subtle. Plus, why should you have to?

There's LOT of great ways for you to do things in the background and a lot of libraries and choices available.

Some ASP.NET apps will be hosted in IIS in your data center and others will be hosted in the Azure cloud. The spectrum of usage is roughly this, in my opinion:

  • General: Hangfire (or similar similar open source libraries)
    • used for writing background tasks in your ASP.NET website
  • Cloud: Azure WebJobs 
    • A formal Azure feature used for offloading running of background tasks outside of your Website and scale the workload
  • Advanced: Azure Worker Role in a Cloud Service
    • scale the background processing workload independently of your Website and you need control over the machine

There's lots of great articles and videos on how to use Azure WebJobs, and lots of documentation on how Worker Roles in scalable Azure Cloud Services work, but not a lot about how your hosted ASP.NET application and easily have a background service. Here's a few.

WebBackgrounder

As it says "WebBackgrounder is a proof-of-concept of a web-farm friendly background task manager meant to just work with a vanilla ASP.NET web application." Its code hasn't been touched in years, BUT the WebBackgrounder NuGet package has been downloaded almost a half-million times.

The goal of this project is to handle one task only, manage a recurring task on an interval in the background for a web app.

If your ASP.NET application just needs one background task to runs an a basic scheduled interval, than perhaps you just need the basics of WebBackgrounder.

using System;

using System.Threading;
using System.Threading.Tasks;

namespace WebBackgrounder.DemoWeb
{
public class SampleJob : Job
{
public SampleJob(TimeSpan interval, TimeSpan timeout)
: base("Sample Job", interval, timeout)
{
}

public override Task Execute()
{
return new Task(() => Thread.Sleep(3000));
}
}
}

Built in: QueueBackgroundWorkItem - Added in .NET 4.5.2

Somewhat in response to the need for WebBackgrounder, .NET 4.5.2 added QueueBackgroundWorkItem as a new API. It's not just a "Task.Run," it tries to be more:

QBWI schedules a task which can run in the background, independent of any request. This differs from a normal ThreadPool work item in that ASP.NET automatically keeps track of how many work items registered through this API are currently running, and the ASP.NET runtime will try to delay AppDomain shutdown until these work items have finished executing.

It can try to delay an AppDomain for as long as 90 seconds in order to allow your task to complete. If you can't finish in 90 seconds, then you'll need a different (and more robust, meaning, out of process) technique.

The API is pretty straightforward, taking  Func<CancellationToken, Task>. Here's an example that kicks of a background work item from an MVC action:

public ActionResult SendEmail([Bind(Include = "Name,Email")] User user)

{
if (ModelState.IsValid)
{
HostingEnvironment.QueueBackgroundWorkItem(ct => SendMailAsync(user.Email));
return RedirectToAction("Index", "Home");
}

return View(user);
}

FluentScheduler

FluentScheduler is a more sophisticated and complex scheduler that features a (you guessed it) fluent interface. You have really explicit control over when your tasks run.

using FluentScheduler;


public class MyRegistry : Registry
{
public MyRegistry()
{
// Schedule an ITask to run at an interval
Schedule<MyTask>().ToRunNow().AndEvery(2).Seconds();

// Schedule a simple task to run at a specific time
Schedule(() => Console.WriteLine("Timed Task - Will run every day at 9:15pm: " + DateTime.Now)).ToRunEvery(1).Days().At(21, 15);

// Schedule a more complex action to run immediately and on an monthly interval
Schedule(() =>
{
Console.WriteLine("Complex Action Task Starts: " + DateTime.Now);
Thread.Sleep(1000);
Console.WriteLine("Complex Action Task Ends: " + DateTime.Now);
}).ToRunNow().AndEvery(1).Months().OnTheFirst(DayOfWeek.Monday).At(3, 0);
}
}

FluentScheduler also embraces IoC and can easily plug into your favorite Dependency Injection tool of choice by just implementing their ITaskFactory interface.

Quartz.NET

Quartz.NET is a .NET port of the popular Java job scheduling framework of the (almost) same name. It's very actively developed. Quartz has an IJob interface with just one method, Execute, to implement.

using Quartz;

using Quartz.Impl;
using System;

namespace ScheduledTaskExample.ScheduledTasks
{
public class JobScheduler
{
public static void Start()
{
IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
scheduler.Start();

IJobDetail job = JobBuilder.Create<MyJob>().Build();

ITrigger trigger = TriggerBuilder.Create()
.WithDailyTimeIntervalSchedule
(s =>
s.WithIntervalInHours(24)
.OnEveryDay()
.StartingDailyAt(TimeOfDay.HourAndMinuteOfDay(0, 0))
)
.Build();

scheduler.ScheduleJob(job, trigger);
}
}
}

Then, inside your Application_Start, you call JobScheduler.Start(). There's a great getting started article on Quartz at Mikesdotnetting you should check out.

Hangfire

And last but definitely not least, the most polished (IMHO) of the group, Hangfire by @odinserj. It's a fantastic framework for background jobs in ASP.NET. It's even optionally backed by Redis, SQL Server, SQL Azure, MSMQ, or RabbitMQ for reliability.

The Hangfire documentation is amazing, really. Every open source project's document should be this polished. Heck, ASP.NET's documentation should be this good.

The best feature from Hangfire is its built in /hangfire dashboard that shows you all your scheduled, processing, succeeded and failed jobs. It's really a nice polished addition.

image

You can enqueue "fire and forget" jobs easily and they are backed by persistent queues:

BackgroundJob.Enqueue(() => Console.WriteLine("Fire-and-forget"));

You can delay them...

BackgroundJob.Schedule(() => Console.WriteLine("Delayed"), TimeSpan.FromDays(1));

Or great very sophisticated CRON style recurrent tasks:

RecurringJob.AddOrUpdate(() => Console.Write("Recurring"), Cron.Daily);

Hangfire is just a joy.

Check out the Hangfire Highlighter Tutorial for a sophisticated but easy to follow real-world example.

There's a rich ecosystem out there ready to help you with your background tasks. All these libraries are excellent, are open source, and are available as NuGet Packages.

Did I miss your favorite? Sound off in the comments!


Sponsor: Many thanks to my friends at Raygun for sponsoring the feed this week. I *love* Raygun and use it myself. It's amazing. Get notified of your software’s bugs as they happen! Raygun.io has error tracking solutions for every major programming language and platform - Start a free trial in under a minute!



© 2014 Scott Hanselman. All rights reserved.