So Microsoft has decided they’re not fixing the screwed up compiler models by giving us even the simple feature enhancements I suggested a week ago or so…

So I’m making one more attempt at least trying to get something workable. One more problem with the Updateable option in the PreCompiler is the fact that Microsoft changes the dates of the ASPX pages pushed into the deployment directory. Which of course means that you can no longer tell whether a file was recently changed.

This sucks and a little fix to keep the original file date intact would make it much easier to properly send the few files that have changed to the server. If you think so to go here:

http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=bcac8dd5-5fde-4b8e-90f7-7d08025d8968

and vote.

I’ve recently switched to using updateable installs on the Web Server, because that appears to be the least amount of files and overhead of what needs to get copied to the server without much fuss. Generally, my ASPX files change rarely while the code behind changes frequently, so I generally copy ASPX files rarely and codebehind assemblies all the time. Without the timestamps this si difficult to do. Especially since you can’t easily copy from a development directory – the development directory holds non of the compiled ASPX code. The only way to get this compiled ASPX code is run the Pre-Compiler (or ‘deploy’ from within VS.NET).

BTW, I checked out the July CTP and the Deploy feature in VS.NET hasn’t changed any, missing many of the compiler features and being generally unclear on what the deploy provides exactly. It seems to suggest you should deploy to an FTP site – I would highly recommend to not go that route, but instead deploy to a directory on disk and then manually deploy. No way do you want to deploy from a development environment directly to a Web Server…

This really pisses me off. These issues have been moaned and groaned about by a lot of folks in messages and feedback and the new deployment features just plain are awful. And the complaints will only get MUCH worse once the product ships and people actually deploy apps. Right now, few people deploy, so the issues are not quite so prominently visible - they will be once release rolls around.

Why the hell can’t these relatively minor changes be made to support a less hands-on deployment mechanism? As it stands the only reliably deployment is an all or nothing deploy. Deploy to disk and then deploy all the files to the server. But you can’t even really do that – some files like web.config likely won’t deploy well from a development directory. You’ll need another intermediary staging deploy before you can do the all or nothing gig. In addition, I have a lot of stuff in my Web directories that I don’t want to ‘just update’ on every upload. Starting with web.config, to a fair amount of large image directories. It is plain non-sense to think that everybody will deploy a complete site for every small little update.

Lame, lame, lame. I’m sure this will piss of a lot more people than just me once they realize what they’ve lost on the deployment front come release. And Microsoft are sitting on their hands on this one and have been since before beta 2.