can you add tests for the following (feel free to mark them as skipped if they aren't working yet):

• A user control in another
• A page that uses control A and B, where A depends on B

So thinking a bit more about this, reminds me of getting masterpage to work. It initially required a type as well - I then changed it to a "TypeReference":

with an update here:

compare to referencesource: https://referencesource.microsoft.com/#System.Web/UI/PageParser.cs,534

It's unfortunate that WebForms "requires" the type to be available when just parsing - this change allowed that to be defered. Please see if you can do similarly.

So thinking a bit more about this, reminds me of getting masterpage to work. It initially required a type as well - I then changed it to a "TypeReference":

CoreWebForms/src/WebForms/UI/PageParser.cs

Line 98 in bb71e85

internal TypeReference MasterPage { get; private set; }

with an update here:

CoreWebForms/src/WebForms/UI/PageParser.cs

Lines 634 to 640 in bb71e85

	if (!typeof(MasterPage).IsAssignableFrom(type))
	{
	var path = VirtualPathProvider.CombineVirtualPathsInternal(this.CurrentVirtualPath, value);
	MasterPage = new(Util.MakeFullTypeName("ASP", Util.MakeValidTypeNameFromString(path)), path);
	//ProcessError(SR.GetString(SR.Invalid_master_base, value));
	}

compare to referencesource: https://referencesource.microsoft.com/#System.Web/UI/PageParser.cs,534

It's unfortunate that WebForms "requires" the type to be available when just parsing - this change allowed that to be defered. Please see if you can do similarly.

I actually had looked at the code for Master page.. let me see if I can fit that model here..

So thinking a bit more about this, reminds me of getting masterpage to work. It initially required a type as well - I then changed it to a "TypeReference":

CoreWebForms/src/WebForms/UI/PageParser.cs

Line 98 in bb71e85

internal TypeReference MasterPage { get; private set; }

with an update here:

CoreWebForms/src/WebForms/UI/PageParser.cs

Lines 634 to 640 in bb71e85

	if (!typeof(MasterPage).IsAssignableFrom(type))
	{
	var path = VirtualPathProvider.CombineVirtualPathsInternal(this.CurrentVirtualPath, value);
	MasterPage = new(Util.MakeFullTypeName("ASP", Util.MakeValidTypeNameFromString(path)), path);
	//ProcessError(SR.GetString(SR.Invalid_master_base, value));
	}

compare to referencesource: https://referencesource.microsoft.com/#System.Web/UI/PageParser.cs,534
It's unfortunate that WebForms "requires" the type to be available when just parsing - this change allowed that to be defered. Please see if you can do similarly.

I actually had looked at the code for Master page.. let me see if I can fit that model here..

Ok you could get by Master page because MasterPage are kept under asp:Content and asp:ContentPlaceHolder both are recognizable (Content and ContentPlaceHolder) asp controls, so there is an already pre-defined types. While usercontrol are dynamic control, so there is no defined types. You can look at https://referencesource.microsoft.com/#System.Web/UI/TagNameToTypeMapper.cs,501 why master page are fine.

Saying that, I think we need to build the dependency chain via sorting to build user control first, master page and web page.
Let me know if you think otherwise.

Let's work incrementally here so we can make sure we're doing it right. I think the following is a progression we can work through to get things finished up:

• PR to just add the tests (skipped for now)
• Update TemplateParser to provide the virtual paths of dependent user controls and enable ascx in the PageCompilationOptions (maybe included with above as it's fairly trivial)
• Enable sorting for the build (not convinced we need this, but have it as a separate thing)
• Try to either (1) remove the compilation requirement or (2) enable a way to share the compilation result to the parser

Thoughts?

Created this PR to handle first 3, will create another PR to resolve the last one

I think (3) should be its own pr. I'm not convinced yet it's the way to do it - we can get (1) and (2) in first and then work through (3) and (4).

For example, it looks like we need to just use the DependencyParser class instead of the TemplateParser class to do the dependency identifcation. Can you get a TemplateParser from a DependencyParser? Should we have the compiler

(1) Create the dependency parser and identify order (2) Create a TemplateParser (directly or via the DependencyParser) to do the parsing (3) Get the generator and generate code

(2) and (3) of these steps are currently being done, but it looks like we may want to insert (1) before them.

sorry for the confusion.. Should we have the compiler bit confusing.. what I assumed is, you probably want as much isolation as possible for compilation module to hold all logic related to compilation... check the newer revision, see how it looks and feel free to provide in-line comments, which will be helpful.

Should we have the compiler bit confusing

Yeah, not sure what I meant there 😕

LGTM. There's a few issues we've created as follow up, but let's get this in so we have user controls

Thank you.. lots of learning..