2
votes

I want to use the ASP.NET MVC 4 Bundling and Minification feature, please assume that we run the debug mode so nothing is bundled, but each reference is simply rendered to single tags. Locally everything works fine:

Example

 public static void RegisterBundles(BundleCollection bundles)
 {
      bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
                  "~/Scripts/jquery-{version}.js"));
 }

When calling @Scripts.Render("~/bundles/jquery") from the view now, a tag similar to this is generated:

 <script src="/Scripts/jquery-1.8.2.js"></script>

The result is the same if I would just write:

 <script src="@Url.Content("~/Scripts/jquery-1.8.2.js")"></script>

But when I deploy everything to a test server in the internet (still using the debug mode), there is some Url rewriting enabled, where I route specific domains or subdomains to specific folders.

For example, if the domain is sub1.example.com then forward to example.com/__sub1__ and in case of sub2.example.com forward to example.com/__sub2__ and so on. When I open sub1.example.com in the browser, there is usually no clue that this forward happens, the Url doesn't change, all Urls remain working and so do references generated using the Url.Content(...) method.

But for some strange reason, the call to @Scripts.Render("~/bundles/jquery") now renders something like this:

 <script src="/__sub1__/Scripts/jquery-1.8.2.js"></script>

Please note the "/sub1" part which is the part which shouldn't be generated and never appear somewhere in the rendered html code and leads to a 404 because the url rewrite forward fails.

While...

<script src="@Url.Content("~/Scripts/jquery-1.8.2.js")"></script>

...still renders the correct relative Path to "/Scripts/jquery-1.8.2.js". And i never had other problems with rewriting the Urls like this. And I don't want to get rid of this rewriting.

Obviously, the same applies to style sheets.

Any ideas what I could try?

1

1 Answers

1
votes

This is a bug with the current implementation of the script/style helpers, this should be fixed with the 1.1-alpha1 release that should be available shortly(early Oct) as the support for using the VirtualPathProvider registered with ASP.NET has fixed this general class of issue (resolving resource paths correctly).