What the hell was Microsoft thinking?

[saunderl]

Hello Everyone,

I'm a lead developer of a ASP.Net site. We have over 150
"applications" running at our site. Each application is a "Solution"
in VS. When we roll to test and production, the main dlls are rolled
to the sites single bin directory and the aspx, asmx etc files are
rolled to various folders on the server.

Now with ASP.Net 2.0 they changed everything. No longer is a web
project a project, its a SITE. The dll names are mangled and renamed
every time its published. What used to be just references are now part
of the soruce control, as if I want compiled dlls in sourcesafe!

All told, after two weeks of looking to move to ASP.net 2.0, I'll have
to say that "It will not happen!" They have made managing a large,
diverse site like ours impossible. Sure, Microsoft gave us lots of
"Wiz Bang" stuff for the kiddies, but really screwed the large scale
site developers, or so it at least seems to my team.

All told, I think that Microsoft REALLY screwed the pooch on this one.

L. Lee Saunders

 

[Juan T. Llibre]

Whoa! Hold your horses.

Download and install the Web Deployment Projects add-in :

http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

"This add-in includes a new tool that enables you to merge
the assemblies created during ASP.NET 2.0 precompilation"

 

[Bruce Barker]

the VS group decided to stop battling the asp.net compiler. VS2005 now uses
the asp.net compiler to build all asp.net sites. this is why VS has a
Publish web site command that builds a clean dir tith what needs to be
deployed.

in 1.1 VS build 1 dll for the code behind, and asp.net build a dll per page
but hide it a temp. in v2, VS uses the asp.net compiler to precompile the
site, so you see all the page dlls.

see the aspnet_compiler documentation to see what your automated build
options are. look at fixednames option.

-- bruce (sqlwork.com)

 

[Erik Funkenbusch]

All told, after two weeks of looking to move to ASP.net 2.0, I'll have
to say that "It will not happen!" They have made managing a large,
diverse site like ours impossible. Sure, Microsoft gave us lots of
"Wiz Bang" stuff for the kiddies, but really screwed the large scale
site developers, or so it at least seems to my team.

All told, I think that Microsoft REALLY screwed the pooch on this one.

Not to blame the victim here, but Microsoft has been making this stuff
available for about TWO YEARS, and *NOW*, after it ships, you say "Hey,
wait a minute, this doesn't work for me". Maybe you should have
investigated the changes needed earlier, and then you could have given your
feedback to Microsoft BEFORE they finalized the product.

Ok, now that I have that off my chest (Sorry, It just bugs me when people
are given access to the information for years ahead of time, and then they
complain after its too late).

You might want to read this article (coincidentally, it also shows how
being involved in the process makes you proactive in getting what you
need). It also explains WHAT they were thinking.

http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/195/Default.aspx

 

[Chris Botha]

Hear, hear, I can't agree with you more. Hopefully they will add this soon.

 

[Chris Botha]

Darn, if only I knew this two years ago and gave my feedback! Think it would
have helped?

 

[PL]

Try learning it instead.

PL

Hear, hear, I can't agree with you more. Hopefully they will add this soon.

 

[Chris Botha]

Instead of what?

Try learning it instead.

PL

 

[Juan T. Llibre]

This whole thing is a non-issue and Microsoft has been working
on a solution for this for quite a long time, as blogged on by
Scott Guthrie for several months now.

The tool which solves this problem, the "Visual Studio 2005 Web
Deployment Projects" Add-in for VS 2005, is available *now* at :

http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

"This add-in includes a new tool that enables you to merge the assemblies
created during ASP.NET 2.0 precompilation, and it provides a comprehensive
UI within Visual Studio 2005 for managing build configurations, merging,
and pre-build and post-build task using MSBuild."

"A Web Deployment Project creates and maintains an MSBuild project file,
and is associated in a solution with a Web site project.

A Web Deployment Project enables you to manage not only build configuration
and merge options, but other tasks such as specifying changes for the application's
Web.config file during compilation, changing connection strings, creating virtual
directories, and performing other tasks at specific points in the deployment process.

The new assembly merge tool (Aspnet_merge.exe) combines assemblies created
during ASP.NET 2.0 precompilation for deployment. The tool supports many merge
options, from combining assemblies for each Web site folder to creating a single
assembly for the entire Web site."

Don't forget to download these very helpful documents :

"Using Web Deployment Projects with Visual Studio 2005"
http://go.microsoft.com/fwlink/?LinkId=55638

and
"Managing ASP.NET Pre-compiled Outputs with Aspnet_merge.exe Command"
http://go.microsoft.com/fwlink/?LinkId=55639

 

[Jon Paal]

I appreciate your frustration. Moving to ASP.net 2.0 is another huge shift. I have many clients on ASP.net 1.x and they will
likely never upgrade to 2.0

This leaves developers with the ever growing problem of maintaining 3 independent versions of ASP websites. The classic ASP, the
ASP.net 1.x and now the ASP.net 2.0

Not a very attractive prospect.

 

[Kevin Spencer]

This leaves developers with the ever growing problem of maintaining 3

independent versions of ASP websites. The classic ASP, the ASP.net 1.x
and now the ASP.net 2.0

Not a very attractive prospect.

This sort of dilemma is something we all (including Microsoft) struggle
with.

The question of when to apply a band-aid, and when to perform major surgery
and break the existing model, is one which every good developer agonizes
over. Every good programmer is a perfectionist, and that is a good thing.
However, every programmer, good and bad, must deal with the reality that
perfection is only something that can be approached, and never achieved. The
points where the compromise is finally made, are the points of the horns of
this dilemma.

The good news is, as we all do struggle with it, we are relatively no worse
off nor better off than anyone else. The playing field remains level and
intact.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

 

[Mark Rae]

I appreciate your frustration. Moving to ASP.net 2.0 is another huge
shift. I have many clients on ASP.net 1.x and they will likely never
upgrade to 2.0

This leaves developers with the ever growing problem of maintaining 3
independent versions of ASP websites. The classic ASP, the ASP.net 1.x
and now the ASP.net 2.0

I find Microsoft Virtual PC absolutely invaluable for this sort of
situation, and also for testing and support.

Currently, I only have one ASP classic site still in production and under
support - you may laugh, but it runs on NT4, MTS2 & SQL Server 6.5!!! Still,
the client pays an annual five-figure sum for support and, by now, the
system is so stable that I haven't received a single support call in over
two years... Every so often, we exchange emails about upgrading, but it
still hasn't happened. Therefore, I have a VPC built with exactly this
configuration, totally isolated from the rest of my system.

I have 13 v1.1 sites in production, five of which have been fully upgraded
to v2.0 and are ready to roll out. However, although my ISP supports v2.0
(and has done all through the Go-Live beta), they will not be upgrading to
SQL Server 2005 for a month or so, so I'm waiting until then before rolling
these five sites out to the public internet. My ISP is also about to start
supporting SQL Server Reporting Services, which means I can *finally* ditch
Crystal Reports - hurrah!

I've just ordered a new development box which will only have v2.0 of the
Framework on it. It will have a large VPC with VS.NET 2003 & SQL Server 2000
on it for as long as it needs to.

VPC is also fantastic for testing and support. E.g. if I get a support call
in response to a web error, I can tell from the contents of the error email
precisely the version of Windows and make, model and version of the browser
so I can simulate the user's environment very closely. E.g. if the error
email says the user was using Windows XP Home and FireFox, I can have a test
system in VPC using exactly that configuration in less than 30 minutes.

I'm currently evaluating the pros and cons of buying a Mac Mini for testing
and support purposes. I've always resisted this but, since the Mac Mini
supports both Mac & PC periperhals (keyboard, video & mouse) it will fit
straight into my KVM, so I think the time has come...

 

[Jon Paal]

It appears that some are not enduring the same level of difficulty.
PHP has been evolving for 10 years and at version 5 still appears to be far more backward compatible.

 

[Mark Rae]

It appears that some are not enduring the same level of difficulty.
PHP has been evolving for 10 years and at version 5 still appears to be
far more backward compatible.

So why not stick with that...?

 

[Chris Botha]

I am still agreeing with the "What the hell was Microsoft thinking?"
I am not a Web developer exclusively but have pushed out a number of fair to
biggish sized Web apps since VS2003 and I am very (sort of extremely)
comfortable with how everything works.
There are some valuable new controls in the new release, and this is
expected, but someone still has to point out the value of the new improved
structure and some other constraints I bumped into when converting a
smallish 2003 project to 2005 (23 forms and 21 user controls took me more
than a day, relative I guess, maybe I am slow).
I would have said have them both then, the old structure/concept and the new
improved one for people with more time on their hands.