Reputation: 3763
Not sure if what I am after here is even achievable with the aspnet_compiler.exe tool, but here goes:
We have a site that we allow users to skin by allowing them to modify master pages - or rather, we don't allow them to modify them directly, we give them a cut down "markup" style language that they can use to modify the html of those pages, so they can essentially "skin" the site to look like their own front end.
I'm keen to try to optimise the site by precompiling the views and the aspx pages. But I want the layout and master pages that those views and pages USE to remain updatable. However, I can't get that to work...
Say we have the following aspx page:
<%@ Page Title="Hello World" MasterPageFile="~/Skinable/Skin.Master" Language="C#" AutoEventWireup="true" CodeBehind="HelloWorld.aspx.cs" Inherits="Project.HelloWorld" %>
<asp:Content ID="Content1" ContentPlaceHolderID="Content" Runat="server">
Hello World!
</asp:Content>
Which references the master page file Skin.Master
in the Skinable
folder. Skin.Master
needs to be updatable. Here is what I have tried:
If I simply compile the site using this aspnet_compiler.exe command, the master page gets compiled too, and is not updatable:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_compiler.exe -v / -p d:\SourceFolder d:\CompiledSite
If I EXCLUDE the skinable folder (adding -x Skinable
to the
command) in the aspnet_compiler.exe then the folder does not get
copied to the output folder, but the master page is still compiled to
the bin folder (ie, a skin.master.compiled
file gets generated into
the build folder). And when we copy the master page in to the
deployment folder, changes to that file get ignored (it just used the
master page as it was at compile time).
If I hide the Skinable folder before running aspnet_compiler (attrib
+h d:\SourceFolder\Skinable
) then I get the same result as above (ie when excluding via the -x flag)
If I specify the -u flag (Updatable) when running aspnet_compiler.exe, well, I'm not sure what the advantage of that is to be honest, as nothing seems to get compiled in that instance, so compilation takes place on the fly when you request a page, so what's the point...
Finally, if I allow compilation of everything, and then go into the bin folder and DELETE skin.master.compiled, then when you request a page that uses that master page, you get the error "The file 'Skin.master' has not been pre-compiled, and cannot be requested"
I suspect that the reference to the master page is the problem here - ie, if a page references a master page, then that master page MUST be compiled too if you want to compile the page, but I'm not sure. Am I on a hiding to nothing here?
Upvotes: 19
Views: 619
Reputation: 836
What if you went about it a different way? What if you 'captured' their html and css changes and then made a new css folder or file for that company? (file is the original(s) plus their changes. Then when the master page is loaded, it pulls from a database what file or folder the company uses and writes that into the css from the master page's c#?
Process would be like:
In essence, this makes the css changes loaded at runtime based on your client and you don't have to worry about the compilation.
We used this process successfully for skinning different colors. Our folder system was like:
Upvotes: 1