How to Ensure Latest Javascript & CSS in Browser Cache in ASP.NET MVC - asp.net

I would like to ensure that latest version of js & css are in client browser cache. I have followed this link (http://blog.robvolk.com/2009/04/ensure-latest-javascript-css-in-browser.html?showComment=1354714427404#c5850523542624593865)
The problem I am not getting new hash-code on every build. I even try to clean and rebuild it does have the same hash-code.
I would appreciate if someone could advise how can I handle the browser cache.
Thanks

I would suggest using bundling and minification of scripts and stylesheets. It is a new feature introduced together with MVC 4, but it seems, that someone was able to make it work with even MVC3 - ASP.NET MVC4 bundling in ASP.NET MVC3
ASP.NET Optimization uses similar approach as your solution - it appends a hash to the URL of script/style, but this hash is based on the content of the js/css file, not on an instance of the application assembly.
note: the blogpost by Jef Claes uses Microsoft.Web.Optimization package, that was replaced by Microsoft.AspNet.Web.Optimization, but I believe, it will work even with the Microsoft.AspNet.Web.Optimization package.

UPDATE: The previous version did not work on Azure, I have simplified and corrected below. (Note, for this to work in development mode with IIS Express, you will need to install URL Rewrite 2.0 from Microsoft http://www.iis.net/downloads/microsoft/url-rewrite - it uses the WebPi installer, make sure to close Visual Studio first)
I fought with it for a couple of days and ended up rolling my own. (see link below for full explanation) You basically Auto-increment the assembly version every time the project is built, and use that number for a routed static file on the specific resources you would like to keep refreshed. (so something.js is included as something.v1234.js with 1234 automatically changing every time the project is built) - I also added some additional functionality to ensure that .min.js files are used in production and regular.js files are used when debugging (I am using WebGrease to automate the minify process) One nice thing about this solution is that it works in local / dev mode as well as production. (I am using Visual Studio 2015 / Net 4.6, but I believe this will work in earlier versions as well.
To implement, you can follow the following steps: (I know this is an old post, but I ran across it while developing a solution):
How to do it: Auto-increment the assembly version every time the project is built, and use that number for a routed static file on the specific resources you would like to keep refreshed. (so something.js is included as something.v1234.js with 1234 automatically changing every time the project is built) - I also added some additional functionality to ensure that .min.js files are used in production and regular.js files are used when debugging (I am using WebGrease to automate the minify process) One nice thing about this solution is that it works in local / dev mode as well as production. (I am using Visual Studio 2015 / Net 4.6, but I believe this will work in earlier versions as well.
Step 1: Enable auto-increment on the assembly when built
In the AssemblyInfo.cs file (found under the "properties" section of your project change the following lines:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
to
[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
Step 2: Set up url rewrite in web.config for files with embedded version slugs (see step 3)
In web.config (the main one for the project) add the following rules in the <system.webServer> section I put it directly after the </httpProtocol> end tag.
<rewrite>
<rules>
<rule name="static-autoversion">
<match url="^(.*)([.]v[0-9]+)([.](js|css))$" />
<action type="Rewrite" url="{R:1}{R:3}" />
</rule>
<rule name="static-autoversion-min">
<match url="^(.*)([.]v[0-9]+)([.]min[.](js|css))$" />
<action type="Rewrite" url="{R:1}{R:3}" />
</rule>
</rules>
</rewrite>
Step 3: Setup Application Variables to read your current assembly version and create version slugs in your js and css files.
in Global.asax.cs (found in the root of the project) add the following code to protected void Application_Start() (after the Register lines)
// setup application variables to write versions in razor (including .min extension when not debugging)
string addMin = ".min";
if (System.Diagnostics.Debugger.IsAttached) { addMin = ""; } // don't use minified files when executing locally
Application["JSVer"] = "v" + System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString().Replace('.','0') + addMin + ".js";
Application["CSSVer"] = "v" + System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString().Replace('.', '0') + addMin + ".css";
Step 4: Change src links in Razor views using the application variables we set up in Global.asax.cs
#HttpContext.Current.Application["CSSVer"]
#HttpContext.Current.Application["JSVer"]
For example, in my _Layout.cshtml, in my head section, I have the following block of code for stylesheets:
<!-- Load all stylesheets -->
<link rel='stylesheet' href='https://fontastic.s3.amazonaws.com/8NNKTYdfdJLQS3D4kHqhLT/icons.css' />
<link rel='stylesheet' href='/Content/css/main-small.#HttpContext.Current.Application["CSSVer"]' />
<link rel='stylesheet' media='(min-width: 700px)' href='/Content/css/medium.#HttpContext.Current.Application["CSSVer"]' />
<link rel='stylesheet' media='(min-width: 700px)' href='/Content/css/large.#HttpContext.Current.Application["CSSVer"]' />
#RenderSection("PageCSS", required: false)
A couple things to notice here: 1) there is no extension on the file. 2) there is no .min either. Both of these are handled by the code in Global.asax.cs
Likewise, (also in _Layout.cs) in my javascript section: I have the following code:
<script src="~/Scripts/all3bnd100.min.js" type="text/javascript"></script>
<script src="~/Scripts/ui.#HttpContext.Current.Application["JSVer"]" type="text/javascript"></script>
#RenderSection("scripts", required: false)
The first file is a bundle of all my 3rd party libraries I've created manually with WebGrease. If I add or change any of the files in the bundle (which is rare) then I manually rename the file to all3bnd101.min.js, all3bnd102.min.js, etc... This file does not match the rewrite handler, so will remain cached on the client browser until you manually re-bundle / change the name.
The second file is ui.js (which will be written as ui.v12345123.js or ui.v12345123.min.js depending on if you are running in debug mode or not) This will be handled / rewritten. (you can set a breakpoint in Application_OnBeginRequest of Global.asax.cs to watch it work)
Full discussion on this at: Simplified Auto-Versioning of Javascript / CSS in ASP.NET MVC 5 to stop caching issues (works in Azure and Locally) With or Without URL Rewrite (including a way do it WITHOUT URL Rewrite)

Related

Blazor: How to run my command before JS files compression / load blazor app from different domain

TL;DR: is there a Target during build/publish (in asp.net core Blazor app) for JS files compression which I can use in csproj to run my script before this Target?
Background:
I have Blazor frontend application which is loaded to different web application (different domains). So: main application loads many other applications and one of these applications is Blazor app (hosted at different URL).
What I did: I load manually _framework/blazor.webassembly.js with autostart property set to false and start Blazor manually:
Blazor.start({
loadBootResource: (
type: string,
name: string,
defaultUri: string,
integrity: string
) => {
const newUrl = ...;// here I can make some URL replacements for defaultUri
// so my `newUrl` points to place where Blazor app is hosted
return newUrl;
},
})
similar as described here: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-3.1#custom-boot-resource-loading
It works correctly but one file is NOT loaded through loadBootResource. It is blazor.boot.json. Code which loads this file is located in blazor.webassembly.js (fetch("_framework/blazor.boot.json"...): https://github.com/dotnet/aspnetcore/blob/master/src/Components/Web.JS/src/Platform/BootConfig.ts#L6
Problem is described also in this issue https://github.com/dotnet/aspnetcore/issues/22220
There is also possible solutions suggested by me: https://github.com/dotnet/aspnetcore/issues/22220#issuecomment-683783971
I decided to replace content of blazor.webassembly.js (replace fetch("_framework/blazor.boot.json" with fetch(${someGlobalVariableForSpecificDomainURL}/_framework/blazor.boot.json) but there are also compressed files (GZ and BR). How to run my script for replacement before compression is started but after JS file is generated? Is it possible? Is there any Target which I can use in csproj?
I do not want to disable dotnet files compression and I do not want to overwrite compressed files (compress by my own).
My current csproj contains something like this (script is started after compression so too late):
<Target Name="ReplacementDuringBuild" BeforeTargets="Build">
<Exec WorkingDirectory="$(MyDirWithScripts)" Command="node replace.js --output=$(MSBuildThisFileDirectory)$(OutDir)" />
</Target>
<Target Name="ReplacementDuringPublish" AfterTargets="AfterPublish">
<Exec WorkingDirectory="$(MyDirWithScripts)" Command="node replace.js --output=$(MSBuildThisFileDirectory)$(PublishDir)" />
</Target>
Thanks for a help or any suggestion! If there is also another workaround to solve main issue, then I will be glad to see it (base tag does not work; replacement of fetch also is not so good).
I didn't find any fitting Target for my purpose. Code from question worked correctly but only with my own compression. So I reverted this and finished with overriding window.fetch to resolve main issue. If URL contains blazor.boot.json then I modify URL and pass it to original fetch. After all files are loaded, I restore original fetch. Similar to code suggested here: https://github.com/dotnet/aspnetcore/discussions/25447
const originalFetch = window.fetch;
window.fetch = function(requestInfo, options) {
if (requestInfo === '_framework/blazor.boot.json') {
return originalFetch('https://example.com/myCustomUrl/blazor.boot.json', options);
} else {
// Use default logic
return originalFetch.apply(this, arguments);
}
};

Sass SCSS by BundleTranslator

I have set up the BundleTranslator in my MVC 5 project via NuGet (BundleTransformer.SassAndScss v1.9.96 with the Core and LibSassHost components). Next I have added the bundle reference to my View.cshtml
#Styles.Render("~/Content/sass")
and redefined the BundleConfig.cs:
var nullOrderer = new NullOrderer();
var commonStylesBundle = new CustomStyleBundle("~/Content/sass");
commonStylesBundle.Include("~/Content/Custom/the-style.scss");
commonStylesBundle.Orderer = nullOrderer;
bundles.Add(commonStylesBundle);
After build, the website has a .scss reference:
<link href="/Content/Custom/the-style.scss" rel="stylesheet">
and everything is working locally probably only because I have installed SassAndCoffee package with SassyStudio. The problem emerges when I deploy on external IIS server. The file exists in the Content/Custom directory, but the website is broken. The HTML code also has the file reference (it links to .scss file, not compiled .css) but if I try to navigate to it, I get error 500.
I have changed the Sass file Build Action to Content (from None) and left Copy to Output Directory as Do not copy. I have also added httpHandlers to Web.config (but I actually don't know whatfor) but still nothing helps.
<httpHandlers>
<add path="*.sass" verb="GET" type="BundleTransformer.SassAndScss.HttpHandlers.SassAndScssAssetHandler, BundleTransformer.SassAndScss" />
<add path="*.scss" verb="GET" type="BundleTransformer.SassAndScss.HttpHandlers.SassAndScssAssetHandler, BundleTransformer.SassAndScss" />
</httpHandlers>
I didn't check all of the settings in Web.config because of the NuGet installation which (as I see) provides this kind of data for the BundleTransformer.
How do I configure the BundleTransformer to work correctly on IIS? Do I have to override the BundleResolver as in example code?
BundleResolver.Current = new CustomBundleResolver();
There are a few things to try to diagnose the problem. Firstly it works locally! :)
1.
It is worth testing that your bundling works correctly. You can do this by temporarily setting the following (take this out once you have finished).
public class BundleConfig
{
public static void RegisterBundles(BundleCollection bundles)
{
BundleTable.EnableOptimizations = true;
// Bundles and stuff...
}
}
Run the site and then in your browser dev tools you should get something like this:
/bundles/commonStyles?v=BzJZwKfP1XV8a6CotGRsHhbxraPDst9zDL2X4r36Y301
If this works then we can be happy bundling will work in production.
2.
Permissions. If your getting a 500 internal server error, check the permissions on the folder that contains the scss files. Also check they are there :)
3.
Mime type. There may be a slight chance that IIS needs a mime type added for .scss, but I'm not convinced it will.

Web.config transform is running twice on publish

I have a solution that includes three web projects (as well as a lot of class library projects). The web projects all use Web.config transforms to specify per-environment configuration.
I have Web.config transforms for multiple build profiles, named Web.UAT.config, Web.Staging.config and Web.Release.config
I am building and deploying the project from my CI server using MSBuild with the following arguments:
/t:Clean,Build /p:Configuration=UAT;DeployOnBuild=True;PublishProfile=UAT
For exactly one of the three projects, the web.config transforms appear to get applied twice, with elements marked xdt:Transform="Insert" appearing twice. Looking in the build output, it seems that all three projects run the following targets:
PreTransformWebConfig
TransformWebConfigCore
PostTransformWebConfig
PreProfileTransformWebConfig
But the problematic project also runs these targets (immediately after those listed above):
ProfileTransformWebConfigCore
PostProfileTransformWebConfig
The .csproj files for web projects include the following by default:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
This file in turn imports \Web\Microsoft.Web.Publishing.targets, also under the VSToolsPath (on my dev machine, this corresponds to C:\Program Files (x86)\MSBuild\VisualStudio\v12.0).
The interesting segment of this file looks like the following:
<ProjectProfileTransformFileName Condition="'$(ProjectProfileTransformFileName)'=='' And '$(PublishProfileName)' != '' ">$(_ProjectConfigFilePrefix).$(PublishProfileName)$(_ProjectConfigFileExtension)</ProjectProfileTransformFileName>
<!--if $(TransformWebConfigEnabled) is also enabled and the ConfigTransform and ProfileTransform happen to have same filename, we default $(ProfilefileTransformWebCofnigEnabled) to false so it doesn't do double transform-->
<ProfileTransformWebConfigEnabled Condition="'$(ProfileTransformWebConfigEnabled)'=='' And '$(TransformWebConfigEnabled)' == 'true' And ('$(ProjectProfileTransformFileName)' == '$(ProjectConfigTransformFileName)')">False</ProfileTransformWebConfigEnabled>
The double transform was happening as a result of ProfileTransformWebConfigCore running, which is conditional on ProfileTransformWebConfigEnabled, which only defaults to false if the ProjectProfileTransformFileName and ProjectConfigTransformFileName are equal.
I added the following target to all three of my projects:
<Target Name="DebugWebConfigTransform" AfterTargets="PreProfileTransformWebConfig">
<Message Text="ProjectProfileTransformFileName: $(ProjectProfileTransformFileName)"/>
<Message Text="ProjectConfigTransformFileName: $(ProjectConfigTransformFileName)"/>
</Target>
For the problematic project, this target output the following:
DebugWebConfigTransform:
ProjectProfileTransformFileName: Web.UAT.config
ProjectConfigTransformFileName: Web.Release.config
Since these two values were different, the double transform was occuring for the reasons described above.
The reason the ProjectConfigTransformFilename was set to Web.Release.config was that the ProjectConfigurationPlatforms in my .sln file was incorrect. The .sln file's Configuration|Platform pair of UAT|Any CPU was being mapped to Release|Any CPU for this project.
I think it was actually applying the UAT and Release transforms as a result (due to the exact nature of my transforms and the order in which they were applied, this was indistinguishable from applying the UAT transform twice).
Updating the ProjectConfigurationPlatforms mapping in the solution file resolved the issue for me.
This issue was occurring for me because I had multiple projects in my solution configuration using different configurations.
It was running more than one web.config transforms because of this configuration:
After switching the projects to use the same configuration I no longer received the issues in my web.config.
It seems this can also happen if you leave off the Configuration msbuild parameter. The PublishProfile isn't good enough.
I had a different issue than all the answers. In my case, I had a profile named staging.pubxml which was using the configuration prod. On publish both the staging and the prod transformation would occur.
Turns out, the name of the .pubxml file also triggers a transform if the same configuration can be found. I simply changed the name of the file and it solved my issue.

My Plone product doesn't show up in the quickinstaller

I have a Plone site with a traditional product BaseProduct (versioned directly in the Products filesystem directory of the Zope installation); the rest of the setup is buildout-based.
For a fork of the project, I need another product AdditionalProduct, which I made the same way (I know it's not the current state-of-the art method; but that's how it worked before for me ...).
Now I was able to install AdditionalProduct using the quickinstaller (for now it contains a single skin directory with a single template only, but this will change, of course).
Sadly, this ceased to work; the product is not shown in the quickinstaller anymore. There is no visible error; I was able to pdb.set_trace() it during instance startup, and there is no error in the error.log either.
The profiles.zcml file looks like this:
<configure
xmlns="http://namespaces.zope.org/zope"
xmlns:genericsetup="http://namespaces.zope.org/genericsetup"
i18n_domain="BaseProduct">
<include package="Products.GenericSetup" file="meta.zcml" />
<genericsetup:registerProfile
name="default"
title="AdditionalProduct"
directory="profiles/default"
description="Extension profile for AdditionalProduct."
provides="Products.GenericSetup.interfaces.EXTENSION"
/>
</configure>
(Copied and changed from an earlier AdditionalProduct of another fork; I don't really understand that "meta.zcml" part.)
How can I debug this?
I'd be willing to "eggify" my product (AdditionalProduct first, since it has the problem; perhaps BaseProduct later as well), but I'm not sure about the amount of work, and a How-To would be useful ...
Your product should have a configure.zcml file that includes your profiles.zcml with the following directive:
<include file="profiles.zcml" />
Is it the case ?
You can debug this by ruling out the following:
The ZCML is not loaded (introduce a syntax error in profiles.zcml and
restart Plone to ensure profiles.zcml is loaded.)
You don't have the 'z3c.autoinclude.plugin': 'target = plone' entry point (not applicable as you are not using a Python package)
Your product is not loaded by Zope2 because it's not in the products folder, or has some related issue e.g. missing __init__.py.
Also you may not need the following, as it should already be included by Plone before your products is loaded:
<include package="Products.GenericSetup" file="meta.zcml" />
(And file='meta.zcml' means "load meta.zcml instead of the default file name i.e. configure.zcml")
Lastly, I'd recommend creating a Python package (AKA "eggify"). See the following for an overview:
http://blog.aclark.net/2015/06/01/plone-add-on-development-for-command-line-savvy-developers/

Can't deploy precompiled, merged webapp to Azure

I'm trying to deploy an ASP.NET web application to Azure. It's hybrid Web Forms, MVC, and WebAPI, and there are a TON of aspx/ascx files, such that they really need to be precompiled or every deploy will render the site sluggish for awhile.
I am trying to deploy via SCM integration with GitHub via kudu, with precompiled views, all merged to a single assembly.
Note that:
Deploy works fine with precompilation disabled.
Deploy works fine from Visual Studio
Build works fine if I copy the msbuild command from the Azure log, replace the relevant paths, and run it locally on my Windows 8.1 machine.
I've set up the Advanced Precompile settings as:
Don't allow precompiled site to be udpatable
Don't emit debug information
Merge all pages and control outputs to a single assembly = AppViews.dll
Here's the .deployment file for Azure
[config]
project = WebSite/WebSite.csproj
SCM_BUILD_ARGS=/p:Configuration=Release;PublishProfile=azure-prod /v:n
You notice I'm sending the verbosity /v to "normal" for extra diagnostic information.
Here is info I get toward the tail of the deployment log:
AspNetPreCompile:
D:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v \ -p D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\Source -c D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir
GenerateAssemblyInfoFromExistingAssembleInfo:
Creating directory "obj\Release\AssemblyInfo".
D:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /out:obj\Release\AssemblyInfo\AssemblyInfo.dll /target:library Properties\AssemblyInfo.cs
AspNetMerge:
Running aspnet_merge.exe.
D:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\aspnet_merge.exe D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir -w AppViews.dll -copyattrs obj\Release\AssemblyInfo\AssemblyInfo.dll -a
aspnet_merge : error 1003: The directory 'D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir' does not exist. [D:\home\site\repository\WebSite\WebSite.csproj]
Done Building Project "D:\home\site\repository\WebSite\WebSite.csproj" (Build;pipelinePreDeployCopyAllFilesToOneFolder target(s)) -- FAILED.
Build FAILED.
It looks like aspnet_compiler.exe runs, but doesn't do what it's supposed to, which is why the TempBuildDir directory (supposed to be the output of the compiler) does not exist in time for the AspNetMerge target. Contrast that with my system, where that directory DOES in fact exist, containing the marker aspx/ascx/etc. files, static content, a PrecompiledApp.config file, and a whole mess of stuff in the bin directory.
aspnet_compiler.exe has an -errorstack flag but it's not clear to me how I could get MSBuild to add this just via the .deployment file, or even if that app is really even throwing an error.
I could just deploy via Visual Studio, but I would really like to take advantage of the SCM integration so I can just push to my prod branch and let it go. Any suggestions?
I replied on https://github.com/projectkudu/kudu/issues/1341, but copying my answer here in case someone lands here...
Way back, we had found that aspnet_compiler.exe was not working within Azure Websites due to how it dealt with the profile folder. We made a change at the time that's a bit of a hack but got us going: we turned it into a no-op, by pointing HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\aspnet_compiler.exe to our own dummy exe (D:\Program Files (x86)\aspnet_compiler\KuduAspNetCompiler.exe).
But trying it now, it appears to work correctly today, likely thanks to improvements in the Azure Websites hosting environment. So we will try getting rid of this hack and doing a full test pass to make sure it doesn't cause any major regressions. If all goes well, we can get that into production, which should enable those scenarios.
In the short term, you may be able to work around this by having your build script:
copy aspnet_compiler.exe from D:\Windows\Microsoft.NET\Framework\v4.0.30319 into your own site files, but under a different name (e.g. aspnet_compiler2.exe)
convince msbuild to use that one
Note: This GitHub issue on projectkudu will eventually make this solution obsolete, but for the meantime, that issue is filed as Backlog, and this works right now.
Thank you thank you David Ebbo. With this information, I was able to bootstrap my build to work for the short term.
First, I downloaded the aspnet_compiler.exe from the Azure instance using the Diagnostic Console available at https://{WEBSITE_NAME}.scm.azurewebsites.net/DebugConsole and added that to my own repository. This way there's no question about any difference between 32/64-bit, etc. I renamed it to azure_aspnet_compiler.exe in my repository.
Second, the AspNetCompiler task doesn't give you the option to change the tool name. It's hardcoded, but as a virtual property so it's overrideable. So I had to create my own task class, and package it in its own assembly, which I built in Release mode and also included in my repository.
public class AzureAspNetCompiler : Microsoft.Build.Tasks.AspNetCompiler
{
private string _toolName = "aspnet_compiler.exe";
protected override string ToolName
{
get { return _toolName; }
}
public string CustomToolName // Because ToolName cannot have a setter
{
get { return _toolName; }
set { _toolName = value; }
}
}
Next I needed to replace the AspNetPreCompile task in MSBuild, but I couldn't figure out how to do that directly. But that task wasn't doing anything anyway, so why not just run right after it?
I added this to the top of my Website.csproj file to import the DLL containing the AzureAspNetCompiler class. Note that the path is relative to the Website.csproj file I'm editing.
<UsingTask TaskName="AzureBuildTargets.AzureAspNetCompiler"
AssemblyFile="..\DeploymentTools\AzureBuildTargets.dll" />
Then I added this right below it, which is basically stealing the MSBuild target definition of AspNetPreCompile from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets, with some of the property setting stuff near the top of it left out (because the original task will do that for us anyway.) Just take note of the ToolPath and CustomToolName values at the bottom of the (renamed) AzureAspNetCompiler element.
<PropertyGroup>
<!--Relative to solution root apparently-->
<LocalRepoDeploymentTools>.\DeploymentTools</LocalRepoDeploymentTools>
<AzureAspnetCompilerPath>$([System.IO.Path]::GetFullPath($(LocalRepoDeploymentTools)))</AzureAspnetCompilerPath>
</PropertyGroup>
<Target Name="NoReallyAspNetPreCompile" AfterTargets="AspNetPreCompile">
<AzureAspNetCompiler
PhysicalPath="$(_PreAspnetCompileMergeSingleTargetFolderFullPath)"
TargetPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)"
VirtualPath="$(_AspNetCompilerVirtualPath)"
Force="$(_AspNetCompilerForce)"
Debug="$(DebugSymbols)"
Updateable="$(EnableUpdateable)"
KeyFile="$(_AspNetCompileMergeKeyFile)"
KeyContainer="$(_AspNetCompileMergeKeyContainer)"
DelaySign="$(DelaySign)"
AllowPartiallyTrustedCallers="$(AllowPartiallyTrustedCallers)"
FixedNames="$(_AspNetCompilerFixedNames)"
Clean="$(Clean)"
MetabasePath="$(_AspNetCompilerMetabasePath)"
ToolPath="$(AzureAspnetCompilerPath)"
CustomToolName="azure_aspnet_compiler.exe"
/>
<!--
Removing APP_DATA is done here so that the output groups reflect the fact that App_data is
not present
-->
<RemoveDir Condition="'$(DeleteAppDataFolder)' == 'true' And Exists('$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data')"
Directories="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data" />
<CollectFilesinFolder Condition="'$(UseMerge)' != 'true'"
RootPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)" >
<Output TaskParameter="Result" ItemName="_AspnetCompileMergePrecompiledOutputNoMetadata" />
</CollectFilesinFolder>
<ItemGroup Condition="'$(UseMerge)' != 'true'">
<FileWrites Include="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\**"/>
</ItemGroup>
With this in place, everything works as I would expect it to.

Resources