# MVC4 StyleBundle not resolving images – Dev

The best answers to the question “MVC4 StyleBundle not resolving images” in the category Dev.

QUESTION:

My question is similar to this:

ASP.NET MVC 4 Minification & Background Images

Except that I want to stick with MVC’s own bundling if I can. I’m having a brain crash trying to figure out what the correct pattern is for specifying style bundles such that standalone css and image sets such as jQuery UI work.

I have a typical MVC site structure with /Content/css/ which contains my base CSS such as styles.css. Within that css folder I also have subfolders such as /jquery-ui which contains its CSS file plus an /images folder. Image paths in the jQuery UI CSS are relative to that folder and I don’t want to mess with them.

As I understand it, when I specify a StyleBundle I need to specify a virtual path which does not also match a real content path, because (assuming I’m ignoring routes to Content) IIS would then try to resolve that path as a physical file. So I’m specifying:

bundles.Add(new StyleBundle("~/Content/styles/jquery-ui")
.Include("~/Content/css/jquery-ui/*.css"));


rendered using:

@Styles.Render("~/Content/styles/jquery-ui")


I can see the request going out to:

http://localhost/MySite/Content/styles/jquery-ui?v=nL_6HPFtzoqrts9nwrtjq0VQFYnhMjY5EopXsK8cxmg1


This is returning the correct, minified CSS response.
But then the browser sends a request for a relatively linked image as:

http://localhost/MySite/Content/styles/images/ui-bg_highlight-soft_100_eeeeee_1x100.png


Which is a 404.

I understand that the last part of my URL jquery-ui is an extensionless URL, a handler for my bundle, so I can see why the relative request for the image is simply /styles/images/.

So my question is what is the correct way of handling this situation?

Grinn / ThePirat solution works well.

I did not like that it new’d the Include method on bundle, and that it created temporary files in the content directory. (they ended up getting checked in, deployed, then the service wouldn’t start!)

So to follow the design of Bundling, I elected to perform essentially the same code, but in an IBundleTransform implementation::

class StyleRelativePathTransform
: IBundleTransform
{
public StyleRelativePathTransform()
{
}

public void Process(BundleContext context, BundleResponse response)
{
response.Content = String.Empty;

Regex pattern = new Regex(@"url\s*$$\s*([""']?)([^:)]+)\1\s*$$", RegexOptions.IgnoreCase);
// open each of the files
foreach (FileInfo cssFileInfo in response.Files)
{
if (cssFileInfo.Exists)
{
// apply the RegEx to the file (to change relative paths)
MatchCollection matches = pattern.Matches(contents);
// Ignore the file if no match
if (matches.Count > 0)
{
string cssFilePath = cssFileInfo.DirectoryName;
string cssVirtualPath = context.HttpContext.RelativeFromAbsolutePath(cssFilePath);
foreach (Match match in matches)
{
// this is a path that is relative to the CSS file
string relativeToCSS = match.Groups[2].Value;
// combine the relative path to the cssAbsolute
string absoluteToUrl = Path.GetFullPath(Path.Combine(cssFilePath, relativeToCSS));

// make this server relative
string serverRelativeUrl = context.HttpContext.RelativeFromAbsolutePath(absoluteToUrl);

string quote = match.Groups[1].Value;
string replace = String.Format("url({0}{1}{0})", quote, serverRelativeUrl);
contents = contents.Replace(match.Groups[0].Value, replace);
}
}
// copy the result into the response.
response.Content = String.Format("{0}\r\n{1}", response.Content, contents);
}
}
}
}


And then wrapped this up in a Bundle Implemetation:

public class StyleImagePathBundle
: Bundle
{
public StyleImagePathBundle(string virtualPath)
: base(virtualPath)
{
}

public StyleImagePathBundle(string virtualPath, string cdnPath)
: base(virtualPath, cdnPath)
{
}
}


Sample Usage:

static void RegisterBundles(BundleCollection bundles)
{
...
.Include(
"~/Content/css/bootstrap.css",
"~/Content/css/bootstrap-responsive.css",
"~/Content/css/jquery.fancybox.css",
"~/Content/css/style.css",
"~/Content/css/error.css",
"~/Content/validation.css"
));


Here is my extension method for RelativeFromAbsolutePath:

   public static string RelativeFromAbsolutePath(this HttpContextBase context, string path)
{
var request = context.Request;
var applicationPath = request.PhysicalApplicationPath;
var virtualDir = request.ApplicationPath;
virtualDir = virtualDir == "https://stackoverflow.com/" ? virtualDir : (virtualDir + "https://stackoverflow.com/");
return path.Replace(applicationPath, virtualDir).Replace(@"\", "https://stackoverflow.com/");
}


According to this thread on MVC4 css bundling and image references, if you define your bundle as:

bundles.Add(new StyleBundle("~/Content/css/jquery-ui/bundle")
.Include("~/Content/css/jquery-ui/*.css"));


Where you define the bundle on the same path as the source files that made up the bundle, the relative image paths will still work. The last part of the bundle path is really the file name for that specific bundle (i.e., /bundle can be any name you like).

This will only work if you are bundling together CSS from the same folder (which I think makes sense from a bundling perspective).

Update

As per the comment below by @Hao Kung, alternatively this may now be achieved by applying a CssRewriteUrlTransformation (Change relative URL references to CSS files when bundled).

NOTE: I have not confirmed comments regarding issues with rewriting to absolute paths within a virtual directory, so this may not work for everyone (?).

bundles.Add(new StyleBundle("~/Content/css/jquery-ui/bundle")
.Include("~/Content/css/jquery-ui/*.css",
new CssRewriteUrlTransform()));


It is not necessary to specify a transform or have crazy subdirectory paths. After much troubleshooting I isolated it to this “simple” rule (is it a bug?)…

If your bundle path does not start with relative root of the items being included, then the web application root will not be taken into account.

Sounds like more of a bug to me, but anyway that’s how you fix it with the current .NET 4.51 version. Perhaps the other answers were necessary on older ASP.NET builds, can’t say don’t have time to retrospectively test all that.

To clarify, here is an example:

I have these files…

~/Content/Images/Backgrounds/Some_Background_Tile.gif
~/Content/Site.css  - references the background image relatively, i.e. background: url('Images/...')


Then setup the bundle like…

BundleTable.Add(new StyleBundle("~/Bundles/Styles").Include("~/Content/Site.css"));


And render it like…

@Styles.Render("~/Bundles/Styles")


And get the “behaviour” (bug), the CSS files themselves have the application root (e.g. “http://localhost:1234/MySite/Content/Site.css”) but the CSS image within all start “/Content/Images/…” or “/Images/…” depending on whether I add the transform or not.

Even tried creating the “Bundles” folder to see if it was to do with the path existing or not, but that didn’t change anything. The solution to the problem is really the requirement that the name of the bundle must start with the path root.

Meaning this example is fixed by registering and rendering the bundle path like..

BundleTable.Add(new StyleBundle("~/Content/StylesBundle").Include("~/Content/Site.css"));
...
@Styles.Render("~/Content/StylesBundle")


So of course you could say this is RTFM, but I am quite sure me and others picked-up this “~/Bundles/…” path from the default template or somewhere in documentation at MSDN or ASP.NET web site, or just stumbled upon it because actually it’s a quite logical name for a virtual path and makes sense to choose such virtual paths which do not conflict with real directories.

Anyway, that’s the way it is. Microsoft see no bug. I don’t agree with this, either it should work as expected or some exception should be thrown, or an additional override to adding the bundle path which opts to include the application root or not. I can’t imagine why anyone would not want the application root included when there was one (normally unless you installed your web site with a DNS alias/default web site root). So actually that should be the default anyway.

Better yet (IMHO) implement a custom Bundle that fixes the image paths. I wrote one for my app.

using System;
using System.Collections.Generic;
using IO = System.IO;
using System.Linq;
using System.Text.RegularExpressions;
using System.Web;
using System.Web.Optimization;


public class StyleImagePathBundle : Bundle
{
public StyleImagePathBundle(string virtualPath)
: base(virtualPath, new IBundleTransform[1]
{
(IBundleTransform) new CssMinify()
})
{
}

public StyleImagePathBundle(string virtualPath, string cdnPath)
: base(virtualPath, cdnPath, new IBundleTransform[1]
{
(IBundleTransform) new CssMinify()
})
{
}

public new Bundle Include(params string[] virtualPaths)
{
if (HttpContext.Current.IsDebuggingEnabled)
{
// Debugging. Bundling will not occur so act normal and no one gets hurt.
base.Include(virtualPaths.ToArray());
return this;
}

// In production mode so CSS will be bundled. Correct image paths.
var bundlePaths = new List<string>();
var svr = HttpContext.Current.Server;
foreach (var path in virtualPaths)
{
var pattern = new Regex(@"url\s*$$\s*([""']?)([^:)]+)\1\s*$$", RegexOptions.IgnoreCase);
if(!pattern.IsMatch(contents))
{
continue;
}

var bundlePath = (IO.Path.GetDirectoryName(path) ?? string.Empty).Replace(@"\", "https://stackoverflow.com/") + "https://stackoverflow.com/";
var bundleUrlPath = VirtualPathUtility.ToAbsolute(bundlePath);
var bundleFilePath = String.Format("{0}{1}.bundle{2}",
bundlePath,
IO.Path.GetFileNameWithoutExtension(path),
IO.Path.GetExtension(path));
contents = pattern.Replace(contents, "url($1" + bundleUrlPath + "$2\$1)");
IO.File.WriteAllText(svr.MapPath(bundleFilePath), contents);
}
base.Include(bundlePaths.ToArray());
return this;
}

}


To use it, do:

bundles.Add(new StyleImagePathBundle("~/bundles/css").Include(
"~/This/Is/Some/Folder/Path/layout.css"));


bundles.Add(new StyleBundle("~/bundles/css").Include(

What it does is (when not in debug mode) looks for url(<something>) and replaces it with url(<absolute\path\to\something>). I wrote the thing about 10 seconds ago so it might need a little tweaking. I’ve taken into account fully-qualified URLs and base64 DataURIs by making sure there’s no colons (:) in the URL path. In our environment, images normally reside in the same folder as their css files, but I’ve tested it with both parent folders (url(../someFile.png)) and child folders (url(someFolder/someFile.png).