Hello, I am using the Web application project model (completely described in this thread) for a modification to the Web Warehouse store module, a subtle enhancement and extreme upgrade to ASP.NET 2.0 of the original core store module. I am trying to convert all of the web user controls (one test control right now though) into the new codebeside model, but have run into a pretty major roadblock. First, what I have got working: I can compile and debug the module as it sits using the legacy codebehind page attribute (which, in VS2005, simply links a page with it's code file but doesn't do anything more compilation wise). I can step through the entire module with no problems.

When I change the CodeBehind attribute ot CodeBeside, followed by changing the class file to 'partial', I get an error when I reference that class elsewhere in code saying that I cannot reference it because it exists in both the module's compiled dll (DotNetNuke.Modules.WWStore.Catalog.DLL) and its compiled ascx file (App_Web_Catalog.ascx.asfdsdfds.asdfsdfsd.dll). Unfortunately, the error returned gave me the GUID for the dll's that the type was located within, so I ended up hunting these down with the Findstr /C:"GUID" /i /m /s *.* on my Temporary ASP.NET files folder.  (findstr very powerful because windows xp find in files on works on registered file types...).

In any event, the page's source is getting compiled even though I have set the Compilation Batch="True" which according to all of the documentation I have read, prevents the individual compilation of page assemblies. The project itself is a class library, and the compiled page does not get built until the page is accessed on the site. The original model didn't have a problem with ambiguity since the pages file would get compiled into one assembly which INHERITED from the codebehind file, which really did live in it's own assembly, however, once the codebeside attribute was set, it caused the page & the code behind to effectively be a single class, and it gets compiled into both the dynamically compiled page assembly and the module's output assembly, causing the ambiguity.

Any ideas on how to prevent the ascx from getting compiled again, or found another workaround to this problem?