This is a very strange problem that burned quite a bit of my time last week.  Hopefully this will be found by someone else with a similar dilemma.

Basically I’ve got a central web application project that I use to house user controls to be shared by many applications.  To accomplish this, I’ve followed this post by K. Scott Allen (of OdeToCode fame).

Since precompiling an ASP.NET project produces (at least) one funkily-named dll, I decided to ILMerge it with the code-behind assembly.  So the process looks like this:

After-build:

• Precompile the website, updatable=false, into a temporary directory
• Merge App_Web*.dll & my project assembly together into one
• Reference this in another project & use the controls

If you look at this dll in reflector, you get something like this:

As a side-note, If you haven’t ever tried doing this before then you should know that you have to reference the compiled user control classes from the ASP namespace in your pages… so in this example <cc1:keywordgrid_ascx /> rather than <cc1:KeywordGrid />.

This first control worked just fine.  It was basically a custom GridView control.  Then I added that next control, SelectKeywords.  Adding it caused the assembly to crash upon loading, i.e. even when we weren't using SelectKeywords it was crashing pages that used KeywordGrid.  The error:

This happened in the constructor of any control in the assembly.  Digging a little deeper into the error, I found that this happens when your user control has literal content in it that gets embedded as a Win32 resource file during precompilation.

In reflector, this is what it looked like:

When building the control tree, the compiler was embedding literal content as a resource.  To try and fix the issue, I started removing literal content.  Bit-by-bit I removed some HTML until the error went away.  This is what reflector looked like when it was working:

But where is this resource file?  Clearly the assembly is referencing some resource file somewhere, right?  I peeked into Temporary ASP.NET Files to find the answer.

If you open this up in Notepad, you’ll find your missing literals!

For some reason, this file wasn’t making it into the final assembly. 

So if you have more than 256 characters of contiguous literal content, the compiler will put this into a resource file (likely for perf reasons).  Sadly there is no way to turn this off. 

I’m not sure if ILMerging the assembly was the reason why this was getting lost, but luckily David Ebbo from Microsoft was able to provide me with a couple of options.

1. You can break up the literal content by injecting empty code blocks like <% %> but who would really want to do that?
2. You can fake out the compiler & supply a code provider that claims to not support Win32 Resource files.  This is what I chose.

I created a class (of course in another assembly, otherwise you have a chicken-and-egg problem):

public class CustomCodeDomProviderWithoutWin32ResSupport : CSharpCodeProvider
{
    public override bool Supports(GeneratorSupport generatorSupport)
    {
        if ((generatorSupport & GeneratorSupport.Win32Resources) == generatorSupport)
           return false; 

        return base.Supports(generatorSupport);
    }
}

To get the precompiler to use this new class, add this to your web.config:

<system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="MyAssembly.CustomCodeDomProviderWithoutWin32ResSupport, MyAssembly" warningLevel="1" />
    </compilers>
</system.codedom>

Now my user controls can have as much literal content as they need and resources will not get added.  I’d like to thank David Ebbo for his assistance in helping me figure this out.  Thanks David!