There is a lot of problems with precompilation because we dynamically load a lot of user controls. Once you precompile them you remove all the contents of the files and then you don't have anything to dynamically load.

I think Microsoft are screwing something up. It makes no sense that it should behave differently because it was compiled by a different tool.

I actually just looked it up, and apparently, if you do use the updateable option, then the user controls should still be able to load. We will take a look at the list of repeated class names and try to get them fixed.

My concern is that you have to still use the updateable option, which most people have no idea about, and which some would argue voids the point of precompilation since as soon as you make a change you are now back to dynamic compilation. Not to mention the fact that the dynamically loading user controls are still dynamically compiled.

Yes, but we won't be moving over to a web project with this version of BV. BV6 will likely be a web project.

I've spent another day on this and I've got to the bottom of it.

The aspnet_compiler tool will not leave .ascx and .master files in place even as markers unless you use the -u option. A few classes in BV5 need to find those files physically present in order to operate properly. The primary reasons are safe loading of master pages if the the template doesn't provide on and control loading in ModuleController. I'll mention more about this later in this post.

BV5 will not build with aspnet_compiler -u however because the user control references are referencing the sub classes instead of the actual classes that BV wrote. Basically it shouldn't be referencing ASP.something_ascv but rather Something. Here are two examples, one for a user control and one for a master page.

User Control Reference

Bad:

Dim singleProductDisplay As ASP.bvmodules_controls_singleproductdisplay_ascx = DirectCast(row.FindControl("SingleProductDisplay"), ASP.bvmodules_controls_singleproductdisplay_ascx)

Good:

Dim singleProductDisplay As [red]BVModules_Controls_SingleProductDisplay[/red] = DirectCast(row.FindControl("SingleProductDisplay"), [red]BVModules_Controls_SingleProductDisplay[/red])

Master Page Reference

Bad:

If TypeOf Me.Master Is ASP.bvadmin_bvadminproduct_master Then
DirectCast(Me.Master, ASP.bvadmin_bvadminproduct_master).ShowProductDisplayPanel = False

Good:

If TypeOf Me.Master Is [red]BVAdmin_BVAdminProduct[/red] Then
DirectCast(Me.Master, [red]BVAdmin_BVAdminProduct[/red]).ShowProductDisplayPanel = False

These are the only types of references I've found in BV. I've fixed all of them up (there were only about 10). They were easy to find. I just searched for _ascx and _master. Now I've got it precompiling and working.

In trying to avoid using the -u so everyone could be precompiled I've tried a few things. First I thought perhaps BV could just attempt to load the controls and get a null return but ASP.Net doesn't support that. It will throw an exception which is rather too ugly for my liking. I disassembler the ASP.Net framework and started digging. I thought there must be somewhere that knows which .ascx files were there at build and all I had to do was find out how to get at it. After hours and hours of digging I found the VirtualPathProvider stuff. That didn't work however because the runtime virtual path provider which only looks at physical files. The BuildManager has access to a special virtual path provider that understands the pre-build files. It is totally hidden away. So there is know way that I can see you can determine if a particular .ascx file was present at build. This means either we keep using File.Exists and keep using the -u option of aspnet_compile or we live with an exception being thrown each time and caught. I'm not sure of the performance impact of that so it would probably need to be cached.

As for aspnet_merge. That would only be achievable after the class names become unique. I'm not too worried about that. At least most of the web site is precompiled.

This is what I understand. There are 4 levels you could deploy with.

Level 1 - No precompilation of anyway

When you first hit the site it will compile the App Code, the page, master page, and every control it needs. The templated controls take a bit longer as it will spit the out them into many segment. A complex page could result in 50 .vb files and are compiled into a separate DLL. As new hits are encountered it will continue compiling anything it has not compiled already.

Level 2 - Precompilation with updatability

This is a little better than level one as all of the App Code is precompiled but all the aspx, ascx and master pages remain under compiled until first used. So there is still a fair bit of compilation that occurs on the fly.

Level 3 - Precompilation without updatability

This will precompile the App Code just like level 2 but will also precompile the template controls such as aspx, ascx and master pages. It will do the work of splitting out each into a bunch of .vb files and then prebuilds each into its own DLL. There are lots of DLLs. The DLLs are loaded on demand by the IIS worker process. The loading of a DLL is pretty quick so this level of precompilation will give snappy response times to users for the first request of any page.

Level 4 - Precompilation without updatability in a single DLL

This level does everything from level 3 but it merges all the little DLLs for each template control and the App Code into one big DLL.

My personal opinion is that level 3 or 4 is the right amount of precompilation for an important site. With the changes I've mentioned we can get BV from level 1 to level 2.