The WiX docs on the topic (Integrating WiX Projects Into Daily Builds) give a good starting point, but are incomplete, at least for the recent builds. Two additional things they forget to mention: WixToolPath needs to be an absolute path for the Wix.targets project to function properly, and WixExtDir needs to be set to WixToolPath.

To build WiX from the binaries with MSBuild, do the following (requires MSBuild 4):

  1. Snag the binaries from the latest weekly build: WiX Weekly Releases
  2. Extract them into a folder you can access with a relative path inside your source control root
  3. Edit all of your .wixproj files and do the following snippet before the <Import Project="$(WixTargetsPath)" > tag:
      <WixToolPath>$([System.IO.Path]::GetFullPath('RELATIVEPATHTOWIX\wix\'))</WixToolPath>
      <WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
      <WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
      <WixExtDir>$(WixToolPath)</WixExtDir>
    </PropertyGroup>
    
  4. Update the RELATIVEPATHTOWIX to be a relative path that points to the WiX binaries you extracted in step 2.

Sometimes my application has a section with normal ASP.NET requests that doesn't go through the ASP.NET MVC pipeline. I still want to integrate it with the ASP.NET MVC section of my app, using the same master page for example. The ViewMasterPage validates to make sure that the page being rendered is a ViewPage with the same type, so you can't use a normal page with a ViewMasterPage. If you run a ViewPage without an ASP.NET MVC context, all of the html helper methods will throw NullReferenceExceptions.

The solution to this issue is to make your page inherit from ViewPage, and then spoof the ASP.NET MVC context before the page renders. This will allow the page to work with a normal ASP.NET request (no ASP.NET MVC pipeline), but also use the same ViewMasterPage used for the rest of your site.

Here's what to do:

  • Make your page class inherit from ViewPage instead of Page.
  • Add the following method to your page:
    void SpoofMvc()
    {
    ControllerContext ctx = new ControllerContext();

    ctx.RouteData = new RouteData();

    ctx.HttpContext = new HttpContextWrapper(Context);
    ctx.RouteData.Values.Add("controller", "TightContent");
    ctx.RouteData.Values.Add("action", "View");

    this.Html = new HtmlHelper(new ViewContext(ctx, new WebFormView(this.Request.FilePath), ViewData, new TempDataDictionary(), Response.Output), this);
    }
  • Call the method before the page is rendered. Page_Load or Page_PreRender should work.

With every new SQL version, it seems there are more and more headaches getting it installed, unless you're installing it on a clean OS install. I ran into error after error trying to install on a Vista box that had been upgraded to Windows 7 and had SQL 2005 already installed.

I finally dug up a blog entry that helped me out on Mark Michaelis's blog. It took a bit of digging, so I figured I'd give him a bit of google juice: SQL 2008 install registry issues and uninstall rollback techniques.

Many shared hosting providers (in this case Mosso) run your ASP.NET applications in a medium trust or modified medium trust environment to reduce security risks. This causes issues with certain techniques and components that require permissions removed by medium trust.

One of the biggest issues other than the actual restriction of permissions is the restriction of partially trusted assemblies calling fully trusted code. By default, if an assembly is strong named, partially trusted assemblies (i.e. the application assemblies in your app running under medium/partial trust) can't call it. This hits many open source components such as iBatis and NHibernate. The workaround to this is to add the AllowPartiallyTrustedCallers assembly level attribute. This will mark the assembly as safe for calling by partially trusted assemblies.

Here is an example of how to modify iBatis to support this:

  1. Download the iBatis source from the iBatis website: http://ibatis.apache.org/dotnet.cgi
  2. Extract the source .zip to a folder
  3. Open the IBatisNet.2005.sln solution in VS.NET
  4. For each project in the solution, open it's AssemblyInfo.cs file
    1. Add this using statement at the top of the file: "using System.Security;"
    2. Add this attribute at the bottom of the file: "[assembly: AllowPartiallyTrustedCallers]"
  5. Right click on the solution and select "Configuration Manager..."
  6. In the "Active solution configuration" dropdown, select Release
  7. Uncheck all of the Test projects
  8. Click OK
  9. Build the solution

Or you can download the compiled assemblies: iBatis-PartialTrust.zip

Enabling NHibernate for medium/partial trust is a similar procedure. If there is enough demand I will present steps and compiled assemblies for it as well.

As for the permission restrictions, most shared hosting providers don't actually run in medium trust as this restricts many useful things such as Reflection etc. One example I've run into recently is Mosso's modified medium trust. They take medium trust, which consists of the following denied permission restrictions:

  • Call unmanaged code.
  • Call serviced components.
  • Write to the event log.
  • Access Microsoft Message Queuing queues.
  • Access ODBC, OleDb, or Oracle data sources.
  • Access files outside the application directory.
  • Access the registry.
  • Make network or Web service calls (using the System.Net.HttpWebRequest class, for example).

And then Mosso adds back in the following allowed permission to come up with "modified medium trust":

  • WebPermission Unrestricted="true"
  • OleDbPermission Unrestricted="true"
  • OdbcPermission Unrestricted="true"
  • SocketPermission Unrestricted="true"
  • ConfigurationPermission Unrestricted="true"
  • ReflectionPermission Unrestricted="true"

This is still rather limiting, but at least you can get most things done as long as you can call into the necessary assemblies without getting exceptions as discussed in the workaround section above.