Scott Hanselman

If someone says "just bin Deploy it" they mean "deploy the application with the dependencies copied into the application's /bin folder, rather than running an MSI that installs the dependencies into the Global Assembly Cache (GAC)."

You may not have administrative control over your Web Server and your host may not want you running installers when new stuff like ASP.NET MVC 3 and Razor comes out. You'll want to "bin deploy" these new technologies.

Here's two ways. The simple way and The Awesome Way.

The Manual Way to BIN Deploy ASP.NET MVC 3 with Razor

On your development machine that has ASP.NET MVC 3 installed you have a C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 3 folder and a C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages folder. In those folders are "Assemblies" folders.

ASP.NET MVC itself references these additional assemblies.

• System.Web.Mvc (well, we ARE this assembly, actually)
• Microsoft.Web.Infrastructure
• System.Web.Razor
• System.Web.WebPages
• System.Web.WebPages.Razor

And the default Web.config for projects also expects:

• System.Web.Helpers

After you deploy your ASP.NET MVC 3 Razor application, you'll need to manually copy these five assemblies to the \bin folder of your deployed application.

NOTE: It's possible to just reference these assemblies directly from your application, then click properties on each one and set copyLocal=true. Then they'd get automatically copied to the bin folder. However, I have a problem with that philosophically. Your app doesn't need a reference to these assemblies. It's assemblies your app depends on. A depends on B that depends on C. Why should A manually set a dependency on C just to get better deployment? More on this, well, now.

Now, you likely remember that "If you're using XCOPY for deployment, you're doing it wrong" so you're likely wondering how to make this deployment process less manual and more awesome.

The Alpha-Geek Show-Off Fancy-Pants Future-Proofed Way to BIN Deploy ASP.NET MVC 3 with Razor

I created a custom Windows 7 Virtual Machine that had only IIS7 and .NET 4 installed, plus Web Deploy, and nothing else in order to test this scenario. This machine has never seen ASP.NET MVC 3 or Razor and we're not installing anything on it. It's our pretend "shared host."

In my ASP.NET MVC Application, I'm going to create a folder called "_bin_deployableAssemblies." Yes, that's a underscore in the front. IIS will not serve from folders whose first character is an underscore. You can thanks FrontPage for that feature. In fact, this guarantees that even if you accidentally copy this folder up (don't) it won't be served. Apparently I got bad info on this from the IIS team. I'm looking into this statement as it's incorrect.

• Create a _bin_deployableAssemblies folder.
• Copy the assemblies we want bin deployed into this _bin_deployableAssemblies folder.
• Select them all, right click and hit properties. Set their Build Action to "None."
• You are expected to check these into source control as well.

Here's my Solution so far:

Here comes the secret awesome sauce.

NOTE: You're reading this on some random dude's blog, so lower your expectation of support now. No, lower. Bit lower. There. Yes, that's zero support. If this accidentally formats your harddrive or deletes your source code, kick yourself hard so you'll wake up to the previous level of Inception, specifically the one where the skinny kid from Third Rock From The Sun is walking on the ceiling. Be careful. Make backups.

Get ready, because we are going into the belly of the beast. This is for VS2010, to be clear. Also, your Program Files folder will vary depending on your x86/x64 version of Windows.

• Go into C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications and make a copy of this folder. Put it somewhere safe.
• Go  into C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web and make a copy of this folder. Put it somewhere safe.
• Download this file and unzip it somewhere: FancyAndTotallyUnsupportedMSBuildFilesForBinDeployableAssemblies.zip
• Inside is:
  • "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
  • "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.OnlyFilesToRunTheApp.targets"
• Copy these new files OVER your existing ones (remember, the ones you backed up?)

Now when you build your Web Application, all the files that are in _bin_deployableAssemblies will automatically get copied into your /bin folder.

This is better than a simple Post Build Step Batch File because it works specifically with publishing. Now, you can right click on your Web Project and "Publish..." an the bin folder contain your project's build output PLUS the _bin_deployableAssemblies folder.

I could publish directly to my Shared Host, or I can Build Deployment Package and get a ZIP file with all the things my app needs.

For me, as I have a VM (remember that I put Web Deploy on it?) and from IIS Manager just "Import Application." Some hosters have a control panel for this, but you'll likely use Web Deploy or Publish via FTP.

This is a nice, clean, self-contained way to bin deploy an ASP.NET MVC 3 application with Razor views to a host that doesn't have any of these bits installed.

INTERESTING NOTE: In a "future update to Visual Studio 2010" (that's marketing code for SP1, which I'm not allowed to say) this feature will be built in. Because with this hack we've only messed with our built-in build targets, those files we've modified will be torched (replaced) with the new Visual Studio updated files, effectively undoing what we've done here. It's a "future-proofed hack."

Enjoy!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By