Hello all,

I have a medium-sized (75 aspx pages or so) ASP.NET 2.0 application which I am trying to deploy.  The application's aspx pages are structured into directories under the web root.  The master pages are in their own directory, all the aspx pages that use those master pages are on other directories.

In case it matters, this project is a file-based project on VS2005.

Now I am trying to deploy the web site and I am running into several problems:

1) If I try to precompile via the command line with aspnet_compiler.exe, then the master pages do not get compiled and are completely missing from the pre-compiled web site.  Also, none of the referenced assemblies are included in the /bin directory.

2) If I try to precompile with the Web Deployment Project tool with the "Merge all outputs to a single assembly" options (my preferred option), then the compilation fails on the merge step. (error MSB6006: "aspnet_merge.exe" exited with code 1.).  No further information is available.

3) If I try to precompile with the Web Deployment Project tool with the "Create a separate assembly..." option turned on, all appears to work well, except the master pages are not compiled or otherwise included at all (same as #1 above).

4) If I try to precompile via the Publish Web Site tool, then everything gets compiled correctly, even the master pages.  Any referenced assemblies (even those references to same-solution projects properly defined/detected) are NOT copied over to the deployment folder and must be copied "by hand".  Any other referenced DLLs/assemblies (ie, 3rd party references listed in the Web.config file, etc...) are not copied either, and must be copied by hand.

So is this a bug, or is there yet another deployment option I am missing that would allow me to create an installable set of files that would not need manual work to get running?  I would love to use the Web Deployment Project tool to create a minimal number of files and then put those files in an installer MSI or EXE file for deployment on the server (ah the good ol' vs2003 days!), but right now I would settle for not having to determine by hand which GAC 3rd party DLLs I have to put into my deployment target machine and hope I don't get anythig wrong!

Hi gmagana,

You can get more detailed output on #2 by going into Tools->Options and selecting the Project and Solutions->Build and Run tab.  Within that change the MSBuild output from "minimal" to Detailed, and then try building again.  This will show you more detailed output on what is failing.

My guess is that you might have a duplicate class name somewhere within the project which is causing the problem.  If you can output the error here we can help figure out what the problem is.

Thanks!

- Scott

Thank you!

That was it, as soon as I saw the actual error it was easy to fix.  I had many, many duplicated class names, I guess every time you create a content page from a master page it names the content class the same.  No one complains about it except aspnet_merge.exe, I suppose!

Now everything works as it should!

PS - I don't really want to mention the obvious, but probably this should be fixed no?  Why does the VS2005 compiler not detect or care about this?  It should not really generate the same class name every time either...  Anyway, thanks, I am very happy to get this site deployed the right way!

Cool stuff!  I'm glad that fixed it!

The new refresh drop of the VS 2005 Web Deployment Project will avoid you having to change the MSBuild verbosity level -- and output the error messages directly.  That should make it much easier to find these errors.

Hope this helps,

Scott

Great to hear about the update, I'm lovin' vs2005/.net2 so far, like a kid in a candy store!

May I ask why is it that no vs2005 component complains about duplicate class names except for aspnet_merge.exe?  Is it because VS generates a separate assembly for each aspx page (at least that's what aspnet_compiler.exe does)?  Why is this not an error that would prevent a web site from even running?

The web-site project model is pretty flexible, and can actually handle cases where there are duplicate class names (one scenario where people find this useful: importing a lot of content from another site).  Because the web-site project model has the option to compile things into separate assemblies, this ends up working.

Where you run into problems is if you try and merge these pages with duplicate names into a single assembly -- which is not supported by the CLR.  That is why an error occurs with the VS 2005 Web Deployment Project.

Hope this helps,

Scott