With the current process, you have to clone a repository that has all the other packages, add your package files to it, and submit a pull request.  Let’s first outline why this process is bad.

What’s wrong with the current process

Putting binaries in a DVCS is evil: DVCS like Mercurial work great for source code, but are atrocious for binary files.  When you pull down the packages repository, you’re not just copying all the other packages’ binaries, but you’re copying down any binary that has ever existed in there.  So whenever something is deleted or moved, we’re forever paying the price for that old binary.  Bottom line: the repo has become very large, and cloning it is painful.

It takes longer to get your packages live: after you send a pull request, you have to wait until it is accepted before your package can go live on the feed.  This is frustrating, as you should be able to push packages nearly instantly.

It makes *my* life difficult: somehow, I’m the sucker on the NuGet team who signed up for taking care of pull requests.  While I got pretty good at it, it’s still time consuming given that rate at which they’ve been coming.  And yes, there are other things I’d prefer to do with my time!

Though it does have a couple advantages

I get to catch some package errors: if I see something that doesn’t look right, I can reject the pull request and tell the author to fix things.  This results in a feed with less bad packages.  Though better tools will allow this to become unnecessary.

It allowed for global changes: since we have all the package pieces in one place, we were able to change everything at once when we made changes to the nuspec format, and this was very useful.  But once 1.0 goes out (soon!), we will keep the format backward compatible, so this won’t be necessary.

If the process is bad, why did we choose to use it?

We really wanted to get NuGet out there as early as possible, and we just didn’t have a gallery ready.  So we came up with this temporary process to get us going in the short term.  As it turned out, it has lasted longer than we were hoping.  Another factor is that you guys submitted way more packages than we were expecting.  Though don’t get me wrong, we are very happy about that part!

So this little system that we expected would be used for a month or two and handle 50ish packages ended up being used quite a bit longer than it should have been, and on a feed that now has 312 packages.

So when will get better?

The good news is that we’ve made some good progress on our gallery, and it will soon be ready to go public.  In fact, this gallery is being developed as open source, so there is absolutely nothing secret about it.  You can find the source at https://orchardgallery.codeplex.com/ and https://galleryserver.codeplex.com/ (it has a gallery piece and a backend piece).

With this new system, submitting a package will be as simple as building the nupkg file (using NuGet.exe), and uploading it to the gallery.  It’s basically the same thing as uploading a VSIX to the Visual Studio extension gallery.  The package will be live on the feed instantly.  There is even a way to do this from the command line.

I don’t know exactly when this will go live, but it should be soon…

Now I’ll let you in on a little secret

The truth is that we are already using the new gallery!  Some of you may have noticed that the fwlink now redirects to https://packages.nuget.org/GalleryServer/FeedService.svc, while a week ago it went to https://feed.nuget.org/rtm/odata/v1/.  And this new link is in fact running the new gallery’s backend code (note that the URL will likely change again).

Also, when you submit new packages, I’m now submitting them to the new gallery using the command line tool.  The part that’s not quite ready for prime time is the Orchard front end, which will let anyone create an account and submit packages.

But be patient, it’ll soon be ready!

The first blog post I ever wrote was titled “Turning an ascx user control into a redistributable custom control”.  It was almost exactly five years ago, and it still gets a lot of hits today.  And interestingly, this new blog post is about solving essentially the same problem, but with a much nicer Razor based solution than was available at the time.

The general issue we’re trying to solve is to encapsulate reusable pieces of UI.  Unfortunately, this has typically meant choosing between two approaches, each having their pros and cons (this mirrors the intro from my old post):

1. Custom code in a library project: this makes it easy to produce a binary that can be used in multiple projects without having to keep source files around.  But on the downside, it’s painful to author rendering logic without a view engine language
2. Using a non-precompiled markup file: in the WebForms world, that meant an ascx file, while in the Razor world, it means a .cshtml file.  This makes it easy to write rendering logic using ascx or Razor syntax.  But the drawback is that it’s hard to turn into a reusable library.

Here, I will show you have you can have the best of both worlds in the Razor world: write your helpers using the powerful Razor declarative helpers syntax, while still being able to build them into a reusable library.

The quick ‘getting started’ guide

If you don’t care about the details of how this works and just want to use it, here is what you need to know to run it.

• Go to the VS Extension Gallery and install the Razor Single File Generator.

• Here you may need to restart VS
• In a Library project, create a Razor file (.cshtml extension)
• Under its properties, set the Build Action to None, and set the custom tool to RazorClassGenerator

• Define various @helper methods in the cshtml file.  When you save it, it’ll produce a nested .cs file, e.g.

• Reference the library from your Razor view (in an MVC3 or Web Pages app) and use the helpers!

And if you’re looking for the source code, it’s all on CodePlex: https://razorgenerator.codeplex.com/

What are Razor declarative helpers?

Scottgu introduced the concept in his Razor post, under the “Declarative HTML Helpers” section.  Here is an example:

@helper WriteList(string[] items) {
    <ul>
        @foreach (var s in items) {
            <li>
                @s
            </li>
        }
    </ul>
}

Here, we are using the powerful Razor syntax to define what our helper will output.  The code in the method is basically the same thing as you write in regular Razor rendering logic, but the fact that it’s inside an @helper method turns it into a declarative helper.

Normally, those @helper methods must live either in your view itself, or in a .cshtml file in App_Code.  When it’s in the view itself, it’s only usable within that one view, while when it’s in App_Code, it’s usable from anywhere in your app.  But in either case, it really isn’t very reusable in the sense that you can’t easily turn it into a library of helpers that you can use in any app without having to carry the .cshtml file.

A VS Single File Generator to the rescue

If you’ve ever used T4 (which I’ve blogged quite a bit about), then you pretty much know what a Single File Generator is.  It’s something that you can attach to a file in your project, such that it generates another file underneath it.

In this case, the file we attach a SingleFileGenerator to is the .cshtml file, and what it generates is the source code that the Razor engine produces from it.

Writing a VS Single File Generator may seem scary, but luckily there is a good sample in the SDK: https://code.msdn.microsoft.com/sfgdd.  In fact, most of the code in my Razor generator is directly copied from this.  The only place that has interesting code that’s specific to Razor is the RazorClassGenerator.GenerateCode() method.  Here is the key code (simplified for brevity):

// Determine the project-relative path
string projectRelativePath = InputFilePath.Substring(appRoot.Length);

// Turn it into a virtual path by prepending ~ and fixing it up
string virtualPath = VirtualPathUtility.ToAppRelative("~" + projectRelativePath);

// Create the same type of Razor host that's used to process Razor files in App_Code
var host = new WebCodeRazorHost(virtualPath, InputFilePath);

// Set the namespace to be the same as what's used by default for regular .cs files
host.DefaultNamespace = FileNameSpace;

// Create a Razor engine nad pass it our host
var engine = new RazorTemplateEngine(host);

// Generate code
GeneratorResults results = null;
using (TextReader reader = new StringReader(inputFileContent)) {
    results = engine.GenerateCode(reader);
}

// Then results.GeneratedCode has the CodeDom CodeCompileUnit that the generator needs

So it’s all pretty simple.  In essence, all it does is give the content of the Razor file to the Razor engine and asks it to generate the right code for it.

Possible areas of improvement

The most obvious pain point when using this is that you need to manually set the custom tool to RazorClassGenerator.  It should be relatively easy to add behavior to the VSIX that would add a right click option on .cshtml files that would set this up.

Another potentially very cool thing is to not only use this to precompile @helpers, but also real Views.  This is trickier because it requires some logic that will allow the view engine to find the precompiled Views, but it can certainly be done.

Wow, it’s hard to believe that it’s been less than a week since NuGet went public.  We were hoping to get noticed, but the attention we got was way beyond my wildest expectations!  The buzz on Twitter has just been phenomenal, and for the most part the feedback has been very positive.  Thank you all for that, this is very encouraging for our little NuGet team :)

Going beyond assembly references

The most common type of NuGet packages bring in assembly references into a project.  It’s super useful, because it saves you from finding it, downloading it, adding the reference, getting dependencies and dealing with versioning.  If NuGet didn’t do any more than that, I think it could be very successful, because that is such a core step that gets repeated manually so many times by so many people.

But it can in fact do a lot more than that!  The first thing that you probably saw already is the config transform support.  I demoed that in my earlier screencast and various people blogged it, with the ELMAH package adding a bunch of things to web.config to make things work.

But not everything that configures libraries goes through web.config.  Thankfully, many libraries come with a code driven way of setting things up (I personally much prefer that over config).  A good example is Louis DeJardin’s Spark View Engine.  In order to use it in an ASP.NET MVC application, you need to create a SparkSettings instance, configure it, feed it to a SparkViewFactory, and then register it as a View Engine with MVC.  Pretty painful steps if you’ve not done it before and just want to get started with Spark.  See Step 5 in this page for an example of what I’m referring to.

So what can NuGet do to make your life easier in these scenarios?  Quite simply, NuGets can include some source code that ends up as part of the project.  For instance, if you install the SparkMvc package, you’ll notice a file named SparkMvc.cs under the App_Start folder, which contains this set up code.  How did the package pull that trick?  Very easy: all it needs to do is include a file named SparkMvc.cs.pp in its Content\App_Start folder.  The reason it has an extra .pp extension is to indicate that it should be preprocessed, which allows it to end up in the correct namespace.  SparkMvc.cs.pp contains (omitting one magic line that I’ll discuss later!):

using System.Web.Mvc;
using Spark;
using Spark.Web.Mvc;

// Secret line goes here! :)

namespace $rootnamespace$.App_Start {
    public static class SparkMvc {
        public static void Start() {
            var settings = new SparkSettings();

            // comment this if you want to use Html helpers with the ${} syntax:
            // otherwise you would need to use the <%= %> syntax with anything that outputs html code
            settings.SetAutomaticEncoding(true); 

            settings
                .AddNamespace("System")
                .AddNamespace("System.Collections.Generic")
                .AddNamespace("System.Linq")
                .AddNamespace("System.Web.Mvc")
                .AddNamespace("System.Web.Mvc.Html");
                // Add here more namespaces to your model classes
                // or whatever classes you need to use in the views

            settings
                .AddAssembly("Spark.Web.Mvc")
                .AddAssembly("System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35")
                .AddAssembly("System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35");

            ViewEngines.Engines.Add(new SparkViewFactory(settings));
        }
    }
}

So the only funny business here is the $rootnamespace$ token, which gets replaced by the namespace of the target project (as in Item Templates).  Other than that, it’s just a static method that contains all the Spark set up logic, which you can of course freely modify once it’s in your app.  It’s just starter code to get you on the right path.

Finally, you’d need to go in your global.asax’s Application_Start and add a line to call this static method.  That works, but that’s kind of a lame manual step that you always have to take after installing the package.  But wait, maybe you don’t have to!

Enter WebActivator

Luckily, there is a very simple way to avoid forcing the package’s user to manually call the startup code from global.asax.  And this mechanism is not provided by the NuGet engine itself, but comes simply as a result of taking a dependency on a little NuGet called WebActivator.  If you look for at the .nuspec manifest file for SparkMvc, you’ll see something like:

  <dependencies>
    <dependency id="spark" minversion="1.0" />
    <dependency id="WebActivator" version="1.0.0.0" />
  </dependencies>

Note that in addition to having a dependency on Spark core, it has a dependency on the WebActivator NuGet.  So what exactly does that do?  It lets you write the secret magic line that I omitted in the code above:

using System.Web.Mvc;
using Spark;
using Spark.Web.Mvc;

[assembly: WebActivator.PreApplicationStartMethod(typeof($rootnamespace$.App_Start.SparkMvc), "Start")]

namespace $rootnamespace$.App_Start {
    public static class SparkMvc {
        public static void Start() {
            // etc...

So WebActivator lets you define a PreApplicationStartMethod attribute which is used to mark your method as something that gets called when the Web app starts.  And that’s it!  Now when you install the SparkMvc NuGet in your app, Spark is completely ready to go, and you just need to add your spark views.

Note: the sources for WebActivator are on bitbucket.

Hey, this attribute looks familiar!

If the PreApplicationStartMethod attribute looks familiar, it’s because ASP.NET 4.0 actually comes with one named exactly the same, and that does the exact same thing (Phil Haack did a nice post on it).  So why the heck aren’t we using it instead of coming up with a new one named the same and that does the same thing?!  The reason is that we were short sighted when we designed this feature in ASP.NET, and only allowed this attribute to be used once per assembly.  This works fine for scenarios where you own the whole assembly, but fails terribly for our NuGet scenario where we want unrelated packages to each come with their startup logic.  ASP.NET fail!  Wait, I was involved in that feature :(

So the idea is that we can use WebActivator for now, and then we’ll make the ASP.NET attribute more flexible in a future release, at which point WebActivator will not be needed as a separate thing (that’s just a tentative plan, it’s not settled yet).  But until then, WebActivator does the job nicely, and using it is as easy as adding one dependency line in your .nuspec file, so we’re not in a bad place. :)

Update (2/15/2011): new switch to have method be called after global.asax App_Start

In some scenarios, the pre app start method gets called too early, as it happens before global.asax. In WebActivator 1.3, I added support for a new attribute that makes the method be called after global.asax's Application_Start. To use this, simply use PostApplicationStartMethod instead of PreApplicationStartMethod, e.g.

[assembly: WebActivator.PostApplicationStartMethod(typeof(TestLibrary.MyStartupCode), "CallMeAfterAppStart")]

What this does is register a module (using this technique), and then call your method the first time an instance of the module's Init is called. Note that your method will only be called once even though the module can get instantiated multiple times. So the fact that it uses a module should mostly just be an implementation detail. What matters is that you method will get called later than Application_Start (but still very early in the appdomain start up sequence).

Other NuGets that use WebActivator

Here is the current list of NuGets that make use of this mechanism:

• Spark.Web.Mvc3, as discussed here
• Ninject.MVC3 uses it to register the Ninject DI Container with ASP.NET MVC (new MVC3 feature, see Brad Wilson’s post!)
• EFCodeFirst.SqlServerCompact uses it to make the EF CTP4 bits use SQLCE 4
• 51Degrees.mobi
• AddMvc3ToWebForms
• AttributeRouting
• Combres
• DataAnnotationsExtensions.MVC3
• entile-server
• FubuMVC
• MefContrib.MVC3
• NuGet.Server
• RestfulRouting
• SimpleMembership.Mvc3
• StructureMap-MVC3
• VirtualPathTemplates

And I’m sure more will come!  Pretty much any NuGet that needs to execute startup code should make use of this.

Feedback welcome

WebActivator is still very new, and I’d love to hear feedback about it from NuGet users.  You can leave a comment here, or start a discussion on https://nuget.codeplex.com/.  The latter is probably best as it makes it easier to have a discussion among many folks.

So what the heck is NuGet?  In short, it’s an Open Source package manager that lets you import libraries into your .NET applications with much less effort than what you’re used to.  Note that NuGet is not a Microsoft project, but an Outercurve Foundation project (previously Codeplex Foundation).  It has both Microsoft and non-Microsoft contributors, and is run as a true Open Source project.  See https://nuget.codeplex.com/ for more info on this.

What problem is NuGet solving exactly?

If you’re a .NET programmer, you’ve likely experienced the pain of getting a 3rd party library into your project.  It usually goes something like this:

1. You know what it’s called, but you have no idea where it lives, so you search for it in your favorite engine.  You often find multiple pages that could legitimately be the want you want.
2. You look around the main page for a link to the download page.
3. Once on the download page, you’re often presented with way more choices than you’d like: several builds, for several platforms, …
4. You download a zip file that you then unzip somewhere on your machine (after remembering to ‘unblock’ it in Windows!).
5. You copy the relevant assemblies into some folder in your solution.
6. In VS, you add a reference to the assemblies.
7. In some cases, you need to make changes to your web.config file to properly enable the component.  This is quite non-trivial if you’re not familiar with it.

Needless to say, all of that is pretty painful and error prone.  Sure, once you’re familiar with a library, you’d probably just copy it from another project instead of getting it from the web, which makes things a bit easier.  But it’s still an overall very ad-hoc process.

And that doesn’t even cover the common case where a library has a dependency on some other libraries, which raises the complexity to the next level.

NuGet to the rescue!

With NuGet, you get a PowerShell window directly in Visual Studio.  You just type a simple command like ‘Add-Package CoolLibrary’, and it takes care of everything.  You can also right click on References and choose ‘Add Package Reference’ to do the same thing through a dialog.  It’s all very very easy, and it just works!

But instead of giving you all the details in writing, I put together a screen cast that shows NuGet in action!  It’s 14 minutes long, so a little bit on the long side, but it demonstrates using NuGet to install all kind of libraries into an MVC 3 app, so it’s pretty action pack.  If that doesn’t convince you of the awesomeness of NuGet, then I will have failed :)

Note: to watch it optimally, you can click on it a second time to view it directly in YouTube.  In there, change it to 720p and play it in full screen.

Another small note is that I made this video with a slightly older build, so you will see some small UI differences with the public bits.

NuPack in Action

I’ll be blogging some more about NuGet in the coming days, so stay tuned!

The first thing you need to know is that there is no Designer Support for using this feature, and that means you have to be prepared to edit your .edmx file as XML.  If this sounds too scary, stop here! :)  The difference is that the technique I found lets you make extremely simple changes, whereas the ‘standard’ technique is plain scary.

So let’s take a quick look at the standard technique, which is explained on MSDN.  Basically, you have to add a ton of XML in many different places, and I personally wouldn’t want to do this by hand.  With my ‘trick’, you don’t need to change any XML.  All you have to do is paste your SQL query in there.

So what exactly is my trick?  It relies on temporarily creating a real database View (i.e. a server view), and have that drive all the XML creation for you!  Here are the basic steps:

1. Create a regular SQL View
2. Map it into the EF model using the designer
3. Copy the SQL View’s query, and paste it into the SSDL’s <DefiningQuery> tag, replacing the query that’s there!
4. Now you can delete the SQL View

A step by step example using everyone’s favorite database

Note: the sample is available on BitBucket.

So let’s say our goal is to create a Defining Query for Northwind called ProductsWithCategoryName, which returns products along with the name of the category they’re in.

Step 0: setting things up

Not really a step, but let’s assume that you already have some app (could be a console app) that has imported Northwind, so you’re able to go in Server Explorer and see the Tables, …

Step 1: Creating a real SQL View

So even though our goal is to create a Defining Query, we’ll create a real SQL view here (we’ll delete it later).  So let’s create our simple View:

• Right click on Views / Add New View
• In the Add Tables dialog, pick both Products & Categories and click Add.  It’s smart enough to guess that you want to use an INNER JOIN here.
• Click the columns that you care about.  e.g. let’s pick ProductID, ProductName and UnitsInStock from the Products table, and CategoryName from the Categories table.

This automatically creates the View’s query for you, so you don’t actually need to know any SQL.  Your query should look like this:

SELECT        dbo.Products.ProductID, dbo.Products.ProductName, dbo.Products.UnitsInStock, dbo.Categories.CategoryName
FROM            dbo.Categories INNER JOIN
                         dbo.Products ON dbo.Categories.CategoryID = dbo.Products.CategoryID

• Save that query in your clipboard, you’ll need it soon!
• Now just save the View as ‘ProductsWithCategoryName’

Step 2: Import the view in an EF model

So far, we haven’t touch EF.  Now is the time!

• In your project, add a new “ADO.NET entity data model”
• Choose Generate From Database, and pick your Northwind
• When you get to ‘Choose Your Database Objects’, pick your ProductsWithCategoryName View.  You can also include other things if you want.

Step 3: paste your query in the edmx file

This is the step!  The one that we actually start talking about your ‘defining query’.

• First you’ll need to open your edmx as XML: right click it, Open With, and choose Automatic XML.  In there, near the top , you should see something like this:

<EntitySet Name="ProductsWithCategoryName" EntityType="NorthwindModel.Store.ProductsWithCategoryName" store:Type="Views" store:Schema="dbo" store:Name="ProductsWithCategoryName">
  <DefiningQuery>
      SELECT
      [ProductsWithCategoryName].[ProductID] AS [ProductID],
      [ProductsWithCategoryName].[ProductName] AS [ProductName],
      [ProductsWithCategoryName].[UnitsInStock] AS [UnitsInStock],
      [ProductsWithCategoryName].[CategoryName] AS [CategoryName]
      FROM [dbo].[ProductsWithCategoryName] AS [ProductsWithCategoryName]
  </DefiningQuery>
</EntitySet>

It already has a DefiningQuery, but it’s defined in term of your server View, which is no good since we plan to get rid of that view!  So simply paste the query you copied in step 1 on top of it.  You now have:

<EntitySet Name="ProductsWithCategoryName" EntityType="NorthwindModel.Store.ProductsWithCategoryName" store:Type="Views" store:Schema="dbo" store:Name="ProductsWithCategoryName">
  <DefiningQuery>
      SELECT        dbo.Products.ProductID, dbo.Products.ProductName, dbo.Products.UnitsInStock, dbo.Categories.CategoryName
      FROM            dbo.Categories INNER JOIN
      dbo.Products ON dbo.Categories.CategoryID = dbo.Products.CategoryID
  </DefiningQuery>
</EntitySet>

And that’s it!  If you look down in the edmx, you’ll see that all the other scary things that the MSDN article tells you to create by hand are already there!  This happened for free because your SQL View (which the designer does support) has the exact same structure as your ‘Defining Query’.

Step 4: delete the SQL View

The SQL view we created in step 1 has served its purpose, so you can delete it if you want.  Even though it has done all the hard work for you, and asked for nothing in return.  Go ahead, delete it! :)

Using the defining query in your code

Now you can just use your Defining Query in your code as you would if it were a regular View.  e.g.

static void Main(string[] args) {
    var context  = new NorthwindEntities();
    foreach (var p in context.ProductsWithCategoryNames) {
        Console.WriteLine(String.Format("{0} / {1} / {2}", p.ProductName, p.CategoryName, p.UnitsInStock));
    }
}

One caveat you need to be aware of is that since the designer doesn’t support defining queries, it won’t preserve your change if you re-save the edmx through the designer.  Apparently, they’re planning to fix that.

Anyway, that was my little contribution to the Entity Framework world…

So in what sense did some readers ‘miss the point’?  They read it as:

Microsoft is now recommending a new data API.  That API uses raw SQL rather than an ORM.  Bunch of Microsoft idiots, what are they thinking!? :)

The reality is of course quite different.  As great as ORMs are, there is a measurable number of web developers who favor writing raw SQL over using an ORM.  That is a fact, and if you’re trying to pretend that it is not the case, you’re in denial.  Though they tend to be less vocal, there are a lot of people who prefer the raw SQL approach, for a variety of reasons.  But the point of this post is not about whether one should use an ORM vs raw SQL, as enough blood has been poured over that. :)

Instead, this post is about this new Microsoft.Data API.  Here is a one liner that describes its goal:

Given that someone will use raw SQL, how can we make it easier.

The first part of the sentence is key, and is what makes all the comments along the lines of “they should not use raw SQL because …” completely moot.  Simply put, if you are an ORM user this technology is not for you.

Instead, the only relevant way to look at this API is to discuss whether it is indeed an improvement over the old ADO.NET API.  And in my opinion that is no brainer.  Pretty much everyone who has seen it in this light has agreed.  Among the advantages over ‘classic’ ADO.NET:

• It uses far fewer concepts to achieve the same things.  Having to deal with SqlConnection/SqlCommand/SqlDataReader can be overwhelming.
• It makes it easier to use parameterized queries, hence reducing the risks of SQL injection issues (Andrew’s post has some simple examples).
• It uses ‘dynamic’ to make it more natural to access row values.

Is it revolutionary compared to classic ADO.NET?  Clearly not, and no one claims that!  But it is a long overdue simplification to the messy ADO.NET APIs, and in that sense it is pure goodness.

Now you can get back to your favorite ORM and feel safe that your world is not under assault. :)

Last time I blogged about a T4MVC release was for 2.6.13.  In the mean time, I released 2.6.14 and 2.6.15, but they were minor updates so I just tweeted them.  You can check out the history page to see what they changed.  Now, 2.5.20 brings a more interesting new feature, so I figured I’d blog it.

New feature to easily render Partials

Update (7/20/2010): there was a small issue with this change when multiple ascx have the same name.  I just pushed a new 2.6.21 build which addresses it.

This new feature was written by Evan Nagle (who is also the author of the Chirpy add-in I discussed a few days ago).  You can check out the post he wrote about it.  In a nutshell, it’s about making it easier to render partial pages.  e.g. suppose you have a partial page called MyUC.ascx (say in Shared) and want to render it from another page (and pass some view data).  Normally, you would write something like this:

<% Html.RenderPartial("MyUC", data); %>

Here, “MyUC” is a magic string, and surely it has to go!  T4MVC has always provided a way to do this:

<% Html.RenderPartial(MVC.Shared.Views.MyUC, data); %>

Basically, it uses the T4MVC generated view token to avoid using a literal string.  Functional, but ugly!  But now, with this new feature you can simply write:

<% Html.RenderMyUC(data); %>

Here, T4MVC generated an extension method specifically to render the partial page, making the code not only free of magic strings, but also more concise and readable.

To disable this functionality: you can turn this off by setting ExplicitHtmlHelpersForPartials to false in T4MVC.settings.t4

T4MVC talk at MvcConf this Thursday (7/22)

Update (7/30/2010): I ended up doing a dual talk on the Razor view engine and T4MVC.  It was a last minute change since we didn’t have a speaker for the Razor talk.  It was a bit of a scramble to get that in, but the talk went well, and is available for all to watch here.

The other thing I wanted to discuss is the T4MVC talk that I’ll be giving at the MvcConf virtual conference.  The talk will be this Thursday at 12pm Pacific (2pm Central).  Check out the full schedule here.  Here is the talk abstract:

Name: T4MVC – the magic string killer

Abstract: Magic strings occur frequently in MVC when referring to Controllers, Actions and Views, and lead to code that can be hard to validate and maintain. In this session, I will show you how to use T4MVC (part of MvcContrib) to almost completely obliterate those magic strings.  To make this a bit different from my previous sessions on this topic, I’ll do the demos by starting with a new MVC app from scratch, instead of starting from a complete sample like NerdDinner.  I’ll be running MVC2 on VS 2010, and will include discussion of new MVC features like Areas.  I’ll also present a VS Add-In that can be used to automatically run T4MVC.  Finally, I will discuss how T4MVC can be used with the upcoming Razor view engine.

Hopefully I’ll see you all there, at least virtually :)

Note: even though the MvcConf site says that the conference is Sold Out, Eric is trying to find a way to stream it more globally (e.g. via ustream).  Check the MvcConf site for updates on this.

But note that Chirpy does a lot more than just run T4MVC automatically!  Check out Evan’s post for a complete tutorial.  To give a really quick intro, Chirpy makes it really easy to automatically:

• Minify your JavaScript files, using a selction of popular engines like YUI and Closure
• Minify your CSS files
• Process DotLess files, which make CSS files a lot DRYer.  And then of course minify the resulting CSS per previous point
• Mash multiple files together
• Validate Javascript and DotLess files
• And last but not least (from my selfish point of view!) automatically run T4MVC when you save your files

But I’m really just paraphrasing Evan’s post, so just check out the details there.  I just played around with most of the functionality, and it all seems to work flawlessly.

It works for both VS 2008 and VS 2010.  Give it a try and see how you like it!

In this post, I’d like to discuss how various pieces fit together, as I’ve seen some amount of confusion in the early user comments that I have read.  Note that I’m not going to describe the pieces in much details (again, see ScottGu’s blog for this).  Instead, my focus is on clarifying the relationship between some of the pieces.

WebMatrix: a stack and a tool

Let’s start with WebMatrix.  The term is actually used is two ways:

1. The WebMatrix stack contains a number of things that you get when you install it via WebPI:
   • The new ASP.NET Web Pages framework
   • The Razor templating engine
   • The WebMatrix tool (see #2)
   • IIS Express
   • SQL CE 4
2. The WebMatrix tool, which lets you perform various tasks:
   • Create web apps that use the Web Pages framework and the Razor templating engine
   • Install existing sites from the Web Gallery.  Note that those sites don’t have to use the Web Pages framework, and in fact most don’t (e.g. ScrewTurn wiki, Subtext)
   • Manage IIS express
   • Manage SQL CE 4 databases

Key point: the WebMatrix tool is not by any mean the only way to create Web Pages apps.  In fact, the Web Pages framework was designed to be very notepad friendly.  On the other end of the tooling spectrum, it will later be fully supported by Visual Studio.

Razor: a templating engine

At its root, Razor is just a templating engine, which is best compared to something like T4.  It is also comparable to the aspx and Spark engines.  The best way to describe it in its most general sense is:

• It takes as input:
  • a template file (with a .cshtml or .vbhtml extension)
  • some input data: in web scenario, this includes things like an HTTP request, but this is not a requirement
• It produces some output string: in web scenario, this is typically a piece of HTML that then gets sent as an HTTP response, but it could be anything.

So as an example, you could envision a very simple command line tool that would read an input file and some parameters, and write out the result of running the template on that input.  Note that everything I wrote here applies both to Razor and to something like T4.

Key point: Razor in itself is not tied to MVC nor to the Web Pages framework, and is not even really tied to web applications.

Note: check out Andrew Nurse’s blog for lots of technical details about Razor.

ASP.NET Web Pages: a simple framework to write ASP.NET web apps

WebMatrix introduces ASP.NET Web Pages, which gives users a simple and powerful new way of writing ASP.NET apps.  It is different from WebForms as it doesn’t use server controls.  It is also different from MVC as it doesn’t follow the MVC pattern.  Instead, it follows a much simpler ‘inline page’ model, where a page is basically an HTML page with some code added where needed.  In that sense, it is reminiscent of Classic ASP, but it is also very different in the sense that it has the full power of the .NET framework available behind it.  It also supports concepts like layout pages which make it much more flexible than the Classic ASP.

Where the discussion gets interesting is that the Web Pages framework uses Razor as its default templating engine.  However, it is not tied to Razor.  Potentially, you could use the aspx or Spark templating engines with the Web Pages framework.  At this point, we have mostly focused on using Razor with it, but it’s entirely conceivable that other templating engines would be supported later.

Key point: ASP.NET Web Pages uses Razor by default, but is not technically tied to it.

ASP.NET MVC

ASP.NET MVC is not part of the WebMatrix release, as it is a completely different framework with different goals (and this post is not about the pros and cons of the two, so I won’t go into that here!).  However, it ties into the story because the Razor templating engine will (soon) be made available as an MVC view engine.  As it should now be clear, this does not imply that you would be using ASP.NET Web Pages if you choose to use Razor as your MVC view engine.  All it means is that you’d be using the Razor syntax for your views instead of aspx (or Spark, …).  This has no bearing on how you write your controllers or other parts of your app.

Key point: Razor syntax will soon be available as an MVC view engine alternative.

Conclusion

Hopefully, I have been able to clarify how some of the pieces that come with WebMatrix fit together.  Please leave a comment if you have any questions and I’ll try to clarify further!