Pretty descriptive error code, eh? Well, I was going to put together
an example of what aspnet_merge.exe can do, so the
first thing I wanted to do was grab an example application,
particularly one that makes use app_code files. I decided to use the
code from BlogEngine.NET.
Yes...I
know, I know...the BlogEngine.NET code was never designed to live under
a WAP-type model,
but surely it can live under that model, right? Well, uh, not without
difficulty.
Step 1: Run aspnet_merge and see what happens
So,
I used the Visual Studio 2005 Web Deployment Projects to construct a
WDPROJ--an MSBuild project with sweet tasks to run the aspnet_merge
utility. (Note: as far as I can tell, BlogEngine.NET is still a Visual
Studio 2005 solution)
At the command line, I typed: msbuild BlogEngine.web_deploy.wdproj
The build started and 54 seconds later...blam! error MSB6006: "aspnet_merge.exe" exited with code 1.
So,
what happened? Sounds like this error happens when class names collide. Like so many
things, the Web Site project tends to
let you get away with bad coding practices like using the same class
name for a page's code behind in multiple places--so long as the pages
are in separate folders. Aspnet_compiler will compile
separate DLLs so there's never the chance that a single assembly will
contain two classes of the same name; however, when aspnet_merge tries
to merge all the assemblies into one, the class names will clashes and
cryptic errors like "error code 1" will get thrown.
Step 2: Figure out where my problems are and fix them
Unfortunately,
the default console logging behavior of MSBuild does not tell me where
my errors are, so, after consulting with my handy-dandy MSBuild command
line reference, I
figure I can do something like this to get more detail on where my
errors are occuring:
msbuild /nologo /v:diag BlogEngine.web_deploy.wdproj > msbuild.log
Scrolling up from the bottom of my log, I see this error:
An
error occurred when merging assemblies: ILMerge.Merge: ERROR!!:
Duplicate type 'widgets_LinkList_edit' found in assembly
'App_Web_nbdnprem'.
Ah-ha! Multiple classes each named
widgets_LinkList_edit. A quick search for that name reveals that, yes,
that class name is used for both the edit.ascx code behind of the
LinkList and TextBox widgets. To fix, I'll go to the TextBox's
edit.ascx.cs file and change that class name to widgets_TextBox_edit
and to the page declaration in the associated ASCX page and update
that, as well.
1...2...3...4 error code 1 issues later and it looks like I have a build! But do I have a good build?
Step 3: Fire up my BE build to see if it works
Seems like the easiest thing to do is to fire up an instance of the
ASP.NET Development Server to host
my BE build, so I execute this at the command line:
WebDev.WebServer.EXE /port:8080 /path:"D:\MyTests\BE_Test1\BlogEngine.Web_deploy\Debug_test1" /vpath:"/BE_Test1"
And I get...a Parse Error:
It looks like the page is barfing when it tries to load the
PostCalendar user control. Interestingly, the PostList user control
loads fine. I wonder why?
Looking at the default.aspx markup code, I see that the PostList user
control is registered at the top of the page, but the Calendar user
control is not. What gives?
Well, it looks like, as Phil Haack once explained,
the controls with the "blog" prefix are registered in the web.config.
Didn't know you could do that. Pretty cool.
<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
<controls>
<add namespace="Controls" tagPrefix="blog"/>
</controls>
</pages>
This doesn't fix my problem, though. ASP.NET Parse Errors are usually
an indication that the CLR can't find the referenced class in the
assembly. Well, I know the PostCalendar class is in my single assembly
(
.NET Reflector told me
that), so maybe the CLR is not able to find the assembly itself. Maybe
I can help. Let's modify the control registration in the web.config
with the assembly attribute:
<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
<controls>
<add namespace="Controls" tagPrefix="blog" assembly="BlogEngine.Web_deploy"/>
</controls>
</pages>
Hey, what do you know? It worked! Now, the page loads up just fine.
Note that this last change I made in the web.config in my build folder;
if you try to change the original web.config and then run BE from the
IDE, you'll get a compiler error. It seems to me that these kinds of
issues can introduce a lot of challenges to development, as you try to
account for the fact that the web.config you deploy to a Production
server will need to look slightly different than the web.config that
you run in your IDE. I wonder if there are any
MSBuild tasks designed to modify the web.config
spit out by the build engine?
Scott Guthrie has talked about
other
important changes that
should occur in your web.config before deploying it to Production. I
wonder if anyone has written a MSBuild task to accommodate those
changes?
Clicking around in my pre-compiled BE instance, everything seems to
work fine; however, I did encounter one
show-stopping error
that prevents me from doing important administration tasks--like adding
a new entry. At least I know that issue's related to the BE
distribution I downloaded, not my build experiment with aspnet_merge.
So, what have I learned? Doing pre-compilation on complicated Web Site
projects can be tricky business--particularly when using aspnet_merge.
I wonder if I should just demo
how to migrate a
Web Site project to a Web Application project?