I don’t get the Copy Web dialog in Visual Studio 2005. This feature sounds like it’d be useful if you could get it pointed at your deployment directory, but no – it points at your project directory. Here’s what the Copy Web Site container looks like inside of VS.NET 2005.

 

 

So this feature basically lets you display the project directory and another directory – file system, FTP, FrontPage Extensions – remotely. I use FTP so it looks like a remote FTP client.

 

If you look at the image, I’m displaying the BIN directory of my Web application. Notice that the the BIN directory does not include the pre-compiled assemblies of the application. On the right is the actual deployed application which includes the APP_*.DLL files which are created when the application is precompiled and deployed.

 

So unless I’m missing something here, I can’t actually use the Copy To Web Site feature to copy a complete Web Site to the server. I can use it for everything but the pre-compiled assemblies. But then what's the point - the thing that I'll be copying to a Web Site the most are updated assemblies especially if I completely pre-compile my Web without the Updateable option.

 

So for that, this feature is basically useless. The right way this dialog should work (or at least optionally) you should be able to point it at your local deployment/precompile directory and then provide this sort of interface.

 

I keep saying it over and over again –  the ASP.NET team is doing us all a huge disfavor by creating all these ALMOST COOL features and leaving out the last missing piece to make it actually useful. Nowhere is this more evident than with the pre-compilation and page model issues.

 

Why oh why can't you compile a site with -FixedNames and still get a the compound assemblies (one per directory) instead of one assembly per ASPX page/codebehind? How hard could it be to provide that feature, which a lot of people are asking for? Or better yet compiling the whole App into a single Assembly?

 

The whole precompilation mess is enough to drive one crazy and it suffers from the same shortsightedness – one step short of getting it right.

 

Or Cache replacements that don’t support Session State – DUH! Or the Localization editors that can only keep the current local resources upated when you make a change. Or Script Callbacks tied to a single interface method… I could go on <g>… It's frustrating as hell to see many of these issues get written off too either as by design - or we'll leave it for the next version.

 

It’s like the ASP.NET team turned off the lights and went home early a half a year ago… (this was going on prior to lockdown after beta 2 was released)