Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some


Now that ASP.NET 2.0 and Visual Studio 2005 have been out for a few months and many of us have had some time to use the product in a day to day environment, it's interesting to take stock of the changes and how they affect the development environment and flow. To me personally ASP.NET 2.0 and Visual Studio 2005 have been a bit of a love/hate relationship.

 

There are many new features in ASP.NET 2.0 that just make life a lot easier and make it hard go back to 1.1 for coding. In my own work I've decided to move up most of my internal applications to 2.0 and not look back. So far it has worked out great. There are many improvements that have reduced code, improved performance and reduced memory footprint, even with almost no changes at all. Moving to embrace more of the 2.0 feature set in existing applications is not something that will happen overnight, but I am finding myself rapidly including many 2.0 features into my applications. In the end, going back to ASP.NET 1.1 and VS 2003 would seem like a huge step backwards.

 

Some of the key features that I find most useful and hard to do without are:

 

File based Projects in Visual Studio 2005 for development

In VS2005 you can now open a directory as a Web Project which is very nice. On my development machine I probably have 50 different Web projects hanging around and configuring and maintaining all of these as virtual directories in IIS and keeping the project references right as you had to in VS2003 is a pain. Don't think so? Have you ever tried to move projects to a new machine? So in VS2005 you point at a directory and the project opens. You can use he built in local Web Server to run the application which eliminates the need to configure a Web Server in any way. This feature is also great for developers who share examples – anybody who wants to check out a sample Web application doesn't have to go through the pain of configuring virtuals on IIS. Instead you now have – at least for development scenarios the true promise of xCopy projects. This is a great feature – but not one that comes without pain (more on this later).

 

Master Pages

The ability to define a master page template and reuse this master template easily throughout your application is a huge timesaver. There were ASP.NET 1.x based implementations of this concept floating around before 2.0 shipped, but to me the key feature that makes this viable is the visual support for it in Visual Studio, so that you can see the master layout along with the ContentPlaceholders used in each page to provide the page level content. In addition to the important visual aspect of the designer, Master Pages are also great to hook related and reusable code to the master template. Because Master Pages tend to wrap a fair amount of functionality that often required several user controls (for example, Header, Footer, Sidebar) Master Pages can isolate logic more completely than you could before.

Visual Representation of User Controls

Call me vain, but I really prefer to see what the whole page looks like while I'm designing it. Like Master Pages Visual Studio 2005 can now display a rendered User Control in place in the Web Form Editor. No longer do you have a non-descript grey box with a control name, but you now have a fully rendered layout right there in the designer. Double-click and VS takes you to the User Control designer. Although I don't use a lot of user controls, I find that this makes design mode a lot more useful especially for my existing 1.1 applications which generally used User Controls for headers, sidebars and footers. I foresee many of my existing user controls to be replaced by Master Pages.

 

Generics

Ok, this isn't an ASP.NET specific feature, but Generics in .NET 2.0 has had a profound effect on the code that I write. In the past, I'd been very wary of creating custom collections because frankly it was a pain in the butt having to subclass from CollectionBase and reimplement the same code over and over again. In ASP.NET especially I find that generic collections work really well for custom control development when you need collection properties. Use List or one of the specialized generic collections as a property of the control and you're done. Visual Studio sees the collection and provides the collection editor for you in most cases. Using Generic Lists also let me easily remove many ArrayList based lists as strongly typed lists which makes code cleaner in many places. Finally using dynamic type replacement in business objects removes a fair amount of funky initialization code that had to be specified in each object to define which type to work with for entity objects. All that configuration code could be replaced simply by making the type generic and assigning a single generic parameter to the class. All class level code can now generically use that generic class description to automatically generate the correct types at runtime. This has removed a huge chunk of traditionally cut and past code from all of my business objects and replaced it with one type parameter and a couple of class level methods. There are many more places where Generics have had a similar effect on my code and I find it hard to go back to not use Generic types and especially collections.

 

Support for embedded Resources

I tend to build a lot of custom controls for my own applications and occasionally for tools and demos I put out. If you build controls that require dependent resources such as images, CSS files, XML Resources maybe, it's a pain to have consumers of the control remember to distribute the appropriate files with their applications. Web Resources in ASP.NET allow you to easily embed and then access resources from within a project as a dynamic URL that ASP.NET generates. You simply add [WebResource] attribute to your control's AssemblyInfo file and then use Page.ClientScript.GetWebResourceUrl to retrieve the URL that contains the resource content.

 

The Visual Studio ASP.NET Code Editor

The code editor in Visual Studio is a huge step up from the 2003 version. Most importantly is that the new editor doesn't wreck your code formatting unless you reformat the document. In VS2003 this was a huge issue for me where I tried to keep my content organized and VS would gleefully step on it and reformat the HTML for me when new controls were added. Now in VS2005, the editor keeps the code intact for most things and also does a much better job with the default insertions of control markup into the code. Another big feature that enhances my productivity is Intellisense in the HTML editor – it's everywhere! I tend to embed <%= %>expressions into the page frequently and having Intellisense in place is very handy to avoid typos. ASP.NET also compiles the page and checks the embedded script code generated now, so that errors in the HTML markup can be caught at design time rather than runtime. Intellisense also works for all controls including your own. No longer do you have to provide an undocumented schema file. Visual Studio will simply find your control and internally manage the Intellisense. The Intellisense support is good enough that it almost makes sense to skip the visual designer altogether and work in code. You'll see why this is actually more important then you might think in a minute.

 

Truth is I could go on and on about features in ASP.NET 2.0 and VS 2005 that I use frequently now. Suffice it to say there are many useful and productivity enhancing features in VS2005 that make it a very hard call to have to go back to ASP.NET 1.1 and VS2003. Add to that a 10-20% performance gain without any changes from 1.1 at all, smaller memory footprint which are also real important to larger applications.

 

But there are also a number of issues with ASP.NET 2.0 and more specifically Visual Studio 2005 that don't sit well with me. It seems that while the ASP.NET 2.0 engine is very stable, tuned and performing well, Visual Studio doesn't fare nearly as well.

 

Visual Studio 2005 is Slow, slow, slow – especially for ASP.NET applications

I used to think that Visual Studio 2003 wasn't exactly a speed demon when it came to bringing up projects and switching views between documents, especially on Web Forms switching between code, HTML and Design views. In VS 2005, the performance of the editing environment especially for context switches between code and the designer is considerably slower. So much so that when I go back to VS2003 I'm amazed at just how fast it is. The main issue seems to be the Web Form editor which is dreadfully slow rendering controls onto the form. I have several large forms with about 50-70 controls on them and these forms take upwards of 15 seconds to load – for every context switch. I recently bought a new dual core laptop and while everything on my machine runs blazing fast, Visual Studio 2005 is the one application I can say is still not even close to as responsive as I would like. If you are upgrading, make sure you have a fast machine and LOTS OF memory. Running Visual Studio commonly results in nearly 500 megs of memory usage on my machine for Devenv.exe alone. Add to that either IIS's worker process or the VS Web Server plus browsers and you can easily chew through 2 gigs of memory.

 

Visual Studio 2005 Web Designer Bugs

The biggest time sink in VS2005 are a variety of editor bugs I and many others have found. Most of these are non-critical but they are highly annoying and waste lots of time. Here are a few of the more annoying examples:


The most frequent bug I run into is where the visual designer refuses to switch focus to another control. You click on a new control, but the property sheet stays locked on the first control. You have switch into HTML view, then back to get it to work.

 

In some instances when you try to rename the name of a control VS won't let you. It says there are already references in the mark up and do you want to continue. If you continue or not, the rename doesn't take and you have to switch to HTML view to change the name. Even when renames from the Web designer do work, they are very, very slow in a large project as VS is doing a full refactoring on the new name – it can take 10-20 seconds plus a dialog click for the rename to complete. Now keep in mind we're changing the name of a PROTECTED control attached to a Web Page here. Why is VS searching through whole project/solution??? I think it's safe to assume that a name change to a designer Page control isn't going to have much effect outside of the current page scope. Talk about the 99% scenario getting the shaft so that the 1% scenario (subclassed page used elsewhere) can work reliably. Besides if you change the control name in HTML view there are no checks at all – I would expect the Web designer to behave the same.

 

Another annoying one is using stock collections and the default Collection Editor. If you rename the default item names to a custom name, VS2005 simply doesn't save the changes. Simple blows away the properties and items you've entered. You have to use the default names or change the names in HTML view, then you can edit with the Collection Editor.

 

If you have style sheet references in the page VS.NET doubles up the style references randomly. I recently opened a page that had 10 of the same CSS references in the file and only one of them that I added.

 

Another issue that's not a bug but an odd implementation of a feature: VS.NET 2005 flags HTML validation errors as Errors. Validation errors are grouped in the same error list as a break-the-build errors. Not only is the HTML validation overly anal with what it flags (example: it doesn't understand named colors), but it gets in the way of seeing 'real' application errors. It's not uncommon for me to have 20-30 HTML 'errors' and 1 code error. The code error will be at the bottom where it's the least useful and there's no visual separation. Validation is useful, but it needs to be separate and easily toggled on and off, ideally with a separate error tab. Instead you can turn it on and off buried in the slow Options dialog – it's all or nothing.

 

The list could go on and on with these small but time sapping little bugs. The end result is that I spend a lot more time in HTML view than I should. Luckily HTML view is a lot more useful in VS 2005 with Intellisense making it much easier to enter property settings in code. I tend to use the designer to drop my controls on the form and move them into place, then use HTML view for most of my property assignments – at this point it's simply more efficient to work this way. But it shouldn't have to be this way.

 

Page Compilation Changes

I mentioned earlier that the new Web Project model is nice for development. In order for that model to work ASP.NET has introduced some fairly radical changes in how Web applications are compiled and deployed. Specifically ASP.NET pages by default compile into a single assembly for each page in the project. This makes it possible to unload each page individually so you can re-run it after making a change, but it also means that each of these assemblies is dynamically generated and cannot be easily referenced from within your applications. In other words, it's very difficult to get a strongly typed reference to another Page or User Control in your application, because there's no known class name you can cast to.

 

This proves to be problematic if you have subclassed Page classes where one Page inherits from stock behavior of another based on an ASPX file. In ASP.NET 1.x this was easy – you simply referenced the first class with its namespace and classname. In 2.0 there's no namespace, the name of the class is dynamically generated and  doesn't exist in the same assembly. The biggest problem of this behavior manifests for applications that rely on dynamically loaded user controls. It's nearly impossible to get a reference to a user control that is not explicitly referenced using <%@ Register %>. The Register tag forces the Page assembly to reference the related assembly for the control, but if you're dynamically loading a user control at runtime no Register directive may be in place. So while you can load the control with Control. LoadControl() there's no way to cast it to the control type.

 

There are a few workarounds, from creating base classes and interfaces that provide the published interface, but none of them do much good for existing applications. A highly visible example of this is DotNetNuke which heavily relies on user controls as well as .Text (which I use for my WebLog) both of which don't run in ASP.NET 2.0 out of the box.

 

Web Projects aren't real Projects

ASP.NET projects aren't real VS.NET projects – they're a custom project type that is based on the operating system file system by default. If you open an ASP.NET Web project it pulls in any and all files below that project folder. This means you really have no control over what gets pulled into your 'project'. One particularily disastrous example is my root Web site which sits ontop of a large number of virtuals. There are probably 50,000 files below the Web root. When I opened the root in VS.NET it pulled in all of that – images, XML files, doc files, utilities; everything. It took about 20 minutes to open that project…

 

File projects have no way of excluding anything. Any file in the tree becomes part of your project. Images, support files, Configuration utilities, documentation files – all of which have little to do with my project. The reason for this is that there really is no project. A few things like the path mapping etc are stored with the solution, but overall there's none of the typical project configuration available that you see in class projects.

 

ASP.NET 2.0 compiles projects using a new ASPNET_COMPILER utility which copies everything to a 'deployment' directory. So not only is your project huge, compiling it copies the entire project including images and support files to a new location. As you can imagine this process is very slow. Compiling a medium sized Web of about 50 ASPX pages takes a good 30-40 seconds on my dual core machine. Compare with a couple of seconds for the same project under VS2003. Granted the compilation is more complete and results in a deployment directory, but while developing 30-40 seconds is too long – so much so that I rarely compile my Web project. Most of the time I work on a page, test run it and move on, but rarely do I do a full compile. The compile cycle is too slow.

 

Any code outside of CodeBehind pages stored in the same path as the ASPX files need to reside in the APP_CODE folder. Everything in APP_CODE  is compiled and can contain plain classes, controls. Be careful if you create backup files – for example, I often do things like copying Control1.cs to Controlbak.cs. Because both controls now exist in the same project with the same code and this causes a compilation error as you end up with duplicate classes.

 

All the project dialogs look different than the 'stock' projects in VS.NET. There's no stock AssemblyInfo file, no support Xml Comments or direct MSBUILD support for a Web project. There is no project. All the information about the application is stored based on the filesystem layout and a few Solution file settings.

 

One workaround for the massive file importing of file projects is to use IIS Web projects instead which requires explicitly adding files. This is a little closer to the old model and at least respects virtual directory boundaries.

 

To Microsoft's credit, they are aware of the project and compilation issues and have started to provide a new Web Application Projects add-in that is still in Beta. It provides VS 2003 style Web projects (with some enhancements for the 2.0 functionality including file base project access). This tool addresses most of the concerns I've raised here, but it's not quite ready for release yet.

 

Deployment of Web Applications

Deploying of ASP.NET applications got a whole lot more complicated with ASP.NET 2.0. You now have many, many options for deploying your applications many of which overlap, none of which are simple and none of which produce a repeatable install. The new ASPNET_COMPILER utility is used to compile projects into a deployment folder. Options exist to compile every page in a single assembly, group all pages into a single assembly per directory, but none of the options produce a single assembly to deploy. In fact, there are lots of files to deploy including stub files and assemblies for APP_CODE and Master Pages.

 

Microsoft apparently intended people to completely re-deploy applications every time an update is made. The compilation creates a deployment folder with a copy of the Web site. VS 2005 includes tools that let you upload the deployment folder to your Web site. But that's pretty unrealistic. Typically you need to adjust web.config and possible other configuration files and you certainly wouldn't want to redeploy all of the incidental files like images for every update. But you can't update a site by simply copying one file with this new model.

 

The simplest install is a source install which deploys exactly as you are developing, installing both ASPX and codebehind source code on the server. Both are compiled on the fly. This is easy to deploy and you don't actually need to run ASPNET_COMPILER, but it's not exactly secure and you have to track changes to all source files.

 

You can deploy compiled assemblies for each page, which create one assembly per page and are stored in the BIN directory. That would be OK, except every time ASPNET_COMPILER is run, the timestamp and file name changes, so the next time you upload you have to clean up the old compiled files. Options allow you to compile both ASPX and CS file or leave the ASPX file intact and let ASP.NET compile the ASPX page content at runtime.

 

You can also group directories together into a single assembly of all ASPX files in that directory. This produces fewer assemblies, but unfortunately there are marker files for every page which – you guessed it – change name on every compile. So the number of files is no less with this installation. In both cases additional assemblies are created for the APP_CODE directory, Master Pages and a few other separated files all of which are dynamically named.

 

The worst thing about this deployment is that there's no quick and dirty way to deploy with the stock options. You basically have to remove files on the server before you copy them back up. And while you're copying files to the server you application is a very unstable state as there are many files which can become  out of sync while uploading. In short, live updates are not really possible on a busy site.

 

Microsoft has heard the message from developers a little late and has made an add-in tool available called Web Deployment Projects which is in Beta. This tool builds on top of the ASPNET_COMPILER functionality and can combine all the assemblies into a single assembly. Further it can create stub files that have a consistent name, so you can create a repeatable deployment image. The tool also allows custom build actions to modify Web.Config files easily for deployment on the fly. This add-in provides a new VS.NET project type and you can use MSBUILD to customize the process. I've been using the command line version of the  tool for my deployment needs and it works much better than the stock behaviors. It makes the process much more manageable.

 

With all these choices available, I created a GUI front end to ASPNET_COMPILER and the Web Deployment Projects with a West Wind ASP.NET 2.0 Compiler Utility. The tool lets you experiment with the various different compilation modes, save the configuration, create batch files and more.

 

 

Will Microsoft do the right thing?

There are a number of things that bug me about ASP.NET 2.0 and Visual Studio 2005, but there are also many things that make life a lot easier for development. The productivity and feature gains and the slowness and bugs roughly offset each other in net productivity in my estimation. But with a little effort on Microsoft's part it could be so much better.

 

But it's not there yet. One look at the faces of developers I stand in front at presentations when you see some of the issues described above says it all – "this stuff looks like Beta software". It happens all the time. I can't tell you how many people have asked me whether they should upgrade to VS2005 and whether it's 'good enough'. I'd say yes it is, but don't expect a bug free environment in Visual Studio.

 

Microsoft is aware of the issues and I've seen many Microsoft developers get involved in Blogs and message boards to address these issues, so if and when a Service Release for VS.NET 2005 becomes available most of these issues should be resolved. I sincerely hope that Microsoft is making a strong commitment to fixing these and other issues and fixing them sooner rather than later. Microsoft has a tendency to move on to the next big thing and already we're hearing talk about the next version of Visual Studio.NET (Orcas). Let's hope that this release can still be made all that it was meant to be for so many years.

 


The Voices of Reason


 

Tyrone
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Rick,

Man you are right on point. Right now I am just shaking my head it totally agreement. All of the Pro's and Con's you've listed I've experienced; but I just can't go back to VS.NET 2003. I'll deal with VS 2005 for now, hopefully they can get these bugs worked out like you said. Good post, keep them coming.

scottgu@microsoft.com
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

We've definitely heard feedback on the project system in VS 2005 and on deployment. Some people really prefer the project-less option, some really dislike it.

That is why we've been working to release the new VS 2005 Web Application Project option (details and a preview are available at: http://webproject.scottgu.com). That addresses the specific feedback you listed above on your "Web Projects aren't real Projects" and "Deployment of Web Applications" points.

Our goal is to have a V1 version of the VS 2005 Web Application Project available in late March (even before VS 2005 SP1).

Hope this helps,

Scott

scottgu
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

BTW -- I should have mentioned that the Web Application Project option also addresses your concerning "Page Compilation Changes". With that option everything is compiled into a single assembly -- so direct references across pages/user-controls are allowed.

Hope this helps,

Scott

Rick Strahl
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hi Scott,

Yes I know <g>. I had played with the previous version a bit to check those things out. Haven't used the new version although I'm starting a new internal project tonight that I might try this out. I suppose by now you have support for adding new files and keeping them synched in place?

scottgu
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Yep -- the latest build on http://webproject.scottgu.com automatically generates the .designer.cs/.vb file for field generation. So when you add controls to a page you can then flip to the code-behind file and program against them (with the first preview you needed to manually update the declarations which was a pain).

Here is a list of the feature not yet implemented: http://webproject.scottgu.com/KnownIssues.aspx
Note that the refresh next month will have these implemented and done.

You can also check out the tutorials on the site to see the features in action (I also have tutorials for step-by-step instructions on how to upgrade from VS 2003, as well as how to migrate a VS 2005 Web Site project). The VS 2005 web site migration tutorial is still a bit rough (we'll make the process smoother with the next refresh), but shows you how it is done.

Hope this helps,

Scott

Bertrand Le Roy
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Rick, you can use the @reference directive for your user control dynamic loading problem. You'll then be able to cast the user control as if you were in the same statically compiled assembly:
http://msdn2.microsoft.com/en-us/library/w70c655a.aspx

Rick Strahl
February 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Bertrand,

Yes, that but that only works if you know what you're loading in the first place and you *can* get the Register directive onto the page. If you're dynamically loading ASCX files that doesn't work.


Wilco Bauwer
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

> "So while you can load the control with Control. LoadControl() there's no way to cast it to the control type."

I don't think this is true, although VS makes it look like it is. If you try to write some code like:

[code]
MyUserControl_ascx x = (MyUserControl_ascx)LoadControl("~/UserControls/MyUserControl.ascx");
x.MyProperty = "hello, world";
Controls.Add(x);
[/code]

It should both compile and run as expected. It's just that VS' intellisense does not seem to apply the same rules. If you don't have the <%@Register (or Reference) directive, VS will not include the type of the usercontrol/page in intellisense.

Rick Strahl
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Wilco,

It depends on how the app is compiled. If you compile single page then it won't work. If you compile per directory and the control is in the same directory it works. I think this is what VS.NET does during development because it works with the control in the same directory.

Move it into a different directory and it no longer works. You'll get an invalid cast on the the control:

CS0246: The type or namespace name 'TestControl' could not be found (are you missing a using directive or an assembly reference?)

TestControl Ctl = this.LoadControl("~/Controls/testcontrol.ascx") as TestControl;
Line 16: Ctl.Bunk = "New Value";
Line 17: this.Form.Controls.Add(Ctl);


Hagay
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

"The most frequent bug I run into is where the visual designer refuses to switch focus to another control. You click on a new control, but the property sheet stays locked on the first control. You have switch into HTML view, then back to get it to work.
"
Happens alot, i found a "faster trick" to work around this problem, when you want to move the foucs to the new control, just use right click on the new control and select properties, the focus is then changes and you can edit the correct control properties.

lloydm
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Rick,

I hate to bite the hand that feeds, but I have to say that unless we can put the R back in RAD, the future of ASP.Net looks bleak. I have found Asp.Net in its VS 2003 incarnation to be cumbersome enough, but VS 2005 is an even tougher sell if I have to factor in a slower ide and additional deployment complexity into my time estimates.

I work with developers using scripting based tools who seemingly gloat about being able to update their sites by merely changing a few files. They become the heroes, as they are able to get some critical update into a production environment in a likety split fashion.

Let's face it, perception is reality and if management perceives that the simpler approach, while inferior in many respects, gets the job done in a timely fashion, then is what they will opt for. You can espouse the virtues of a compiled, OO and scalable platform all day long, but it doesn't count for much if you can't make a deadline! Don't get me wrong, I know that classic asp, for example, has a lack of scalability and a propensity for spaghetti code, making it inferior to asp.net in many ways, but it does have a shorter development cycle.

I would really like to adopt the latest and greatest, but not when it makes it even harder to complete the task at hand!

Bertrand Le Roy
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Rick, I'm sorry but I don't see your point: if you're going to cast, surely you also have to know in advance what you're going to cast to. So how's having to know the type in the cast different from having to know the type in the reference directive?

Rick Strahl
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Bertrand,

I think the scenario is where you're loading up a slew of controls dynamically. If you knew everything that was going onto a page before hand then you could drop the controls onto a page in the first place.

But you're right. In most scenarios using the <%@ Register %> directive does the trick as long as you know exactly where you're loading the control from - you have to specify that in the @Register command.

The typical scenario where this becomes a problems is in typical 1.1 theming scenearios where controls can load from different directories based on the theme in use - the @Register directive is of no use in that case.

It's not the most common scenarios, but I have several third party applications here that do exactly that and they don't run under 2.0. There's no easy way to fix it either. .Text (.94) and DotNetNuke are two of them.

Rick Strahl
February 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Lloyd,

ASP.NET *does* support single file authoring and deployment just as PHP, Python, classic ASP and other scripting technologies. That is still possible and now also supported well by Visual Studio 2005 (it wasn't in VS2003). And obviously deployment of that scenario works very much in a similar way as it does for other scripting technologies - you upload your script file and that's that - no code behind assemblies whatsoever unless you link other assemblies and you can swap files in real time without stopping anything - ASP.NET just recompiles the page. I didn't mention this above but that functionality has always been there even if it's not a very common way that ASP.NET pages are developed.

I don't think for a minute that ASP classic is more productive. The things you had to do with classic ASP to write business logic were horrendous. <g> It's no more difficult to create single file ASP.NET pages and you have so much richer functionality available to build logic. The big difference is that ASP.NET has a bigger learning curve due to the sheer size of what's available for you to use. Many people confuse complexity with volume though - just because there's so much available doesn't mean you have to use it all.


Peter Bromberg
February 18, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Rick,
This is the first really "comprehensive look" I've seen that clearly reduces, into black and white, a lot of the subliminal stuff we all have been experiencing.
This is doubly on-target because just yesterday I was IM-ing with my site partner who has been totally Windows Forms 2.0 and class library programming with 2005, until yesterday when he starteed his first ASP.NET 2.0 web project. One of his comments what "What the *&%#$ did they do to this thing?".

Peter

Bertrand Le Roy
February 18, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

I must be missing something here. You can still dynamically load user controls even without the reference directive, can't you?
What you can't do is cast, and in this case you would need to know the type in advance anyway, right?
What exactly is the scenario that used to work and is now broken?
(we can take that offline if you want)

Warren Connors
February 19, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Ditto on the kudos to Rick for this summary. Encouraging to find out about Microsoft's upcoming wap and wdp implementations.

Reine
February 20, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Thanks for mentioning the Web Deployment Projects beta! I had missed that one.

kiran konathala
February 28, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

ooops,so many bugs in da final release?Im using the express editions for a change and so far,its been a breeze!!I will lay my hands on VS 2005 after I experience the express editions full!!
Hope,they release a patch for their bugs soon.All in all,ASP.NET 2.0 rocks!!

Crider
March 03, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

"Don't get me wrong, I know that classic asp, for example, has a lack of scalability and a propensity for spaghetti code, making it inferior to asp.net in many ways, but it does have a shorter development cycle."

Wow I must have really bad at classic Asp!...or else I'm really good at .NET!

We were talking whether to migrate (1.x to 2.0) just the other day, I'll forward this link to my collegues. Any significant pitfalls in your migrations?

Thanks Rick for a no-nonsense eval!


Rick Strahl
March 03, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Crider,

<g>. I don't think any sane person can really argue that ASP classic is easier. Everything that ASP classic does ASP.NET can also do including single file deployment which is in fact still easy (but not common for most projects).

As to pitfalls in migration - all of my migrated projects went really well with the exception of the inheritance issues and control inclusion issues.

Inheritance I guess I didn't mention - if you have classes that don't have code behind classes, ASP.NET creates stub classes in APP_Code that then inherit from the original class. I've had issues where the inheritance hierarchy would hide controls at hte intermediate class level and that broke through those stub files. Easy to fix but annoying nevertheless.

Other than that it's been good for me. Most upgrades even for fairly complex sites took about an hour of fixing up to get to run.

The biggest time sink was removing 'legacy functionality though'. Things the .NET framework deems outdated and wants you to replace with other things. It takes some time to get apps to compile cleanly...

Brian
March 06, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

The way this new functionality works is going to force my web/UI designers to use VS2005 (some of which are using macs). Previously I could do a release of .aspx files and the one .dll to the staging server, and they could go in after the fact and clean up all the html in the .aspx pages.
Then they would check in all their changes to source control. Now that the .aspx page has a dynamic Inherits="Default.aspx, aasd63hddv" after compile, they will have to merge any changes they made to the deployed version into the source control version - what a headache!! If they accidentally check in the version with the unique Inherits="Default.aspx, aasd63hddv", then it will break VS2005 IDE the next time someone does a 'get' from vss. =\

The new 'nightmare' deployment, in addition to the sluggish interface of the IDE, inability to exlude files/directories, among other things has been a deal breaker at my company. We just decided to roll back to vs2003.

Reiterating the comments from above:
"What the *&%#$ did they do to this thing?".

Rick Strahl
March 06, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Brian,

Before you roll back you really should check out Web Application Projects. It will let you do the things you need to (separate ASPX files that can be deployed as is, single DLL) with VS 2005.

It's an add-on in Beta right now (but quite usable at this point!) and it will be rolled into the next update of VS2005 natively.

Brian
March 07, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

If the Web App Projects truly let you deploy an unaltered ASPX and a single DLL there may be hope yet :)

Thanks

Torna
March 19, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

size of masterpage content place holder(content)?
Themes and css not show in design mode?
use a space to focus in markup !?!
Themes Intellisense ?
the list go on and on ..........

Paul
March 30, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Definitely a love/hate thing for VS2005 here. Things I am getting to *really* hate:

The tabs - I've stopped using them. New ones get added to the wrong side of the window (compared to every other tabbed product I use); they seem to move around; the file name is truncated from the right-hand end, so if the file is in a deep directory, then it is usually the filename that is truncated, making it impossible to work out what the file is called.
Basically, I hate them.

"Go to Definition" in a web application. We have a web app that has a load of separate assemblies. In VS2003, you could select "Go to..." in a file in the web app, and it would take you to class in the assembly that you wanted. In VS2005, however, it takes you to a metafile that only contains the signatures of all the methods of the class, which is next to useless. I imagine that there must be a way to get the functionality that VS2003 had, however I don't know how, and I don't understand why the default behaviour has been changed to this metafile one. Is this something else that will be available in the Web Application Projects option?

Michael Freidgeim
April 01, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Paul,
I also hate truncating filenames in tabs. Please vote for my suggestion to VS team http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=f060b527-15d3-449e-9927-8a302e8f5240

James Wilson
April 02, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Speed, speed and yet again speed.

On developer machines with dual 3GHz processors and 2GB of ram, a moderately sized web application takes between 1-2 minutes to compile.

It literally is a case of start the compile, go make some coffee, come back again. The slowdown always happens on web projects though, our class library projects are whizzed through, and then our web projects take about 1 minute to "think", and then they start compiling.

Yay, progress :)


Hans
April 03, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Some weeks ago, I take a quick look Visual Basic Express Edition. It was so extreeeeeemely slow, I thought there was something very wrong with my machine or the installation itself.

After reading this topic, I realise that what I was experiencing, actually must be normal behaviour. Is anyone actually getting any serious work done using VS2005? Unbelievable.


Michael
April 03, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Is any one know that the built-in web server in VS2005 supports classic ASP?

Martin
April 10, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Kind of new to asp.net and the whole visual studio experience. Love some of it but have found the lack of css display in design mode very annoying - why give a drag and drop design utility if you are not going to show my design?

Shaun Walker
April 28, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

I am a little confused by the user control loading comment in regards to DotNetNuke as we did a lot of work to release DotNetNuke 4.0 for ASP.NET 2.0 on Nov 7, 2005 ( the official launch day of VS2005 ). I have never heard of any problems from our community regarding the user control issue you raise in this blog. DotNetNuke 4.0 works fine in Visual Web Developer Express, SQL Express, and Cassini - and still uses an architecture which completely based on dynamic loading of user controls. It allows you to create new modules ( user controls ) using the new web project model and package/deploy them as per the standard DNN distribution model which has been employed since ASP.NET 1.0. And modules developed for DNN 3.0 on ASP.NET 1.1 can be deployed directly into a DNN 4.0 site running ASP.NET 2.0 without any compatibility issues. These were all huge accomplishments for the DotNetNuke community.

Matt Colin
April 28, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hey in response to the built in server and classic ASP. From my experience it does not. However if you run the pages on IIS it works fine.

Does anyone know though why I would get this error?

The server name or address could not be resolved

this only occurs for asp pages that I have loaded to the server and have checked all of the settings and it is supposed to support asp. Not sure why it can't find the server name

Rick Strahl
April 28, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hi Shaun,

My apologies if this sounds like it's misrepresenting DNN. I based my comments on the discussions you and I had as well as a few comments I traded with Joe Brinkman as well as a few issues I heard from users of DNN. In those cases especially the issue was migrating from 1.x to 2.x.

I have no doubts that these issues have been addressed, otherwise there'd be a lot of noise about it since DNN is one of the most popular .NET applications out there for sure.

As you might recall though in our discussion we were talking about what a pain it is in 2.0 making a dynamic architecture work, which is the point I was trying to make in this post (and the articles that it spawned).

Again my apologies if you think this casts DNN in a bad light (which I don't think it does)...


Shaun Walker
May 01, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

No problem Rick... I was just reacting to the comment "A highly visible example of this is DotNetNuke ... as well as .Text ... both of which don't run in ASP.NET 2.0 out of the box.". Based on this semmeingly factual information, your audience would conclude that DotNetNuke does not run on ASP.NET 2.0 - which is not the case at all. A comment like this could certainly dissuade people from downloading or adopting DotNetNuke as part of their future web strategy. And the fact that a false statement like this is picked up by print magazines, newsletters, and blog aggregators demonstrates how quickly a myth can be spread through mass media.

David Young
May 09, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

I love to program but having to also dump layout into the equation drives me crazy. Most of the clients I deal with think that there is some kind of magic template that can create their idea of a website without any input. If I could have one thing it would be a CSS dockable window in design view that opens the CSS file I am using that lets me change values and SEE in real time what happens as I change the CSS. It should also allow switching the design view to whatever browser envior(FireFox,IE,Opera,NET) I wish to see.

Shaun I have been using DNN 4.X to shortcut some design issues and its a nice platform. However it has its drawbacks as all platforms, esp opensource do.

DNN as an option for full time programmers prob wouldn't be my first recommendation. There's alot of code that simply would be too exhausting to manually parse to make sure its correctly returning values you want.

However for some applications this is perfect platform. If you are a non-profit for example that has changing data(annouce,events,etc) this is a great option. Most could never afford to pay a prog to change this data all the time. The ability for DNN to let the average Joe change his data himself is certainly a great money saver.

There's more but I do agree that before anyone condemns or remarks about DNN I'd suggest they actually use it first and not rely soley on the non-verfied ideas of others.

Rick Strahl
May 09, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Uhm, I'm really not sure how this got turned into a 'bash DNN' topic. As I mentioned to Shaun, the comment above was talking about the difficulty related to development of data driven and dynamically loaded content that he and I and several others discussed at one. I didn't mean to single out DNN, nor imply that it wasn't working merely that it was very much affected by the changes that ASP.NET 2.0 brings. I'm glad to hear that the DNN crew has been able to work through all of this and continue to provide a powerful and popular platform. Personally I think DNN is a great asset to the .NET community as it's a common entry point for many developers new to ASP.NET in general.

jackob
May 24, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

With regards to compilation of ASP code. I just had to put in my bit

I think you are missing the point a little. Microsoft is not encouraging you to compile your whole site frequently, they are trying to encourage you not to compile at all.

We started in classic asp treating web sites as Web sites, then moved to reconceptualising sites as "Web applications". Now we are moving in the other direction again through dynamic compilation.

This should never have changed in the first place. There are so many things wrong with treating a site as an application I do not know where to begin. My only gripe is that they have not moved far enough in the other direction and we are still able to treate sites as applications. It was always a stupid idea.

Rick Strahl
May 25, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Jackob... it's a matter of opinion. ASP.NET IS and application platform, not a scripting engine, and for those of us that use it that way the new project model presents many pitfalls.

If you're creating simple pages that contain self-contained spaghetti code logic, then you have your ASP classic model - it's still supported, nothing different. That's fully supported and doesn't even require a project at all.

The problem is that all the little things related to the new project model that got broken - class relationships, class references to other pages and controls are all either broken or require hacks to accomplish. All Microsoft has done has made a really simple model that was provided in 1.1, very complex - complex enough that most people don't even understand how pages are put together. While that is not so bad - you unfortunately need to understand it if you go past the boundary conditions. Maybe you're not hitting this and if you don't - good for you! I and many others unfortunately have bit my teeth on these issues and have wasted gobs of time on 'improvements' that should have been simple to deal with...



Jackob
June 04, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hi Rick.

Yes ASP .Net was, at the outset, presented as an application development platform. My point is that this was, and is, idiotic. WEB SITES ARE NOT APPLICATIONS and when you treat the as such you run in to all sorts of problems. This has been a frustration to me from the very beginning of .Net.

Having said this I worked for many years in windows development before becoming a web developer so I am perfectly comfortable working in a apps development environment. I am definately not advocating a return to spagettie style coding. The organisation of code in visual studio is one of its major strengths - even if behind the scenes things are less revolutionary that they look.

I might add that I think that on the whole VS 2005 is an improvement. Not having to compile a web site is one of those improvements.

Scott Fletcher
June 16, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Ditto on speed. I have a Pentium Extreme 975 - 3.7 GHz, 1GHz front side bus, 4GB RAM, 10,000 RPM drives... and Visual Studio runs like it's on an old 486. Holy crap. I work with large solutions with over 150 project files, and the VS 2005 IDE 'thinks' for one or two seconds each time I click on a file in the solution explorer. My productivity is in the toilet. click, wait - *sigh*

opy
September 17, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some


Sriman Bapatla
September 19, 2006

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

You are exactly correct. VS2005 really helps the development efforts but packaging means creating(msi) the setup,websetup or Web Service project, Microsoft removed some of the features that used to be available in vs2003. For example in VS2005 Websetup or Web Service we can not set the port number. This is so dissapointing because many pepole have used the setup projects to create the msi's so that they can deploy them. All the knowledge that we gained in the previous version went to drain. People have to look for other means like installsheild or something to create the packages.


thanks
Sriman

Rick Strahl's Web Log
October 15, 2006

# A few really annoying VS.NET 2005 ASP.NET bugs - Rick Strahl's Web Log

Here are a couple of annoying bugs that cause me to loose some time during development. First control renaming in the ASP.NET WebForm editor often doesn't allow renaming. And multiple CSS references applied to a page being injected by VS.NET for who knows what reason.

Visual Studio 2005
December 06, 2006

# ASP.NET Forums - Excluding folder or files from compilation in VS 2005


Getting Started
December 06, 2006

# ASP.NET Forums - IntelliTXT Advertsement & deployment query


Alex Feldstein
May 25, 2007

# Alex Feldstein - Powered By Bloglines


ASP.NET Forums
June 15, 2007

# Excluding folder or files from compilation in VS 2005 - ASP.NET Forums


ASP.NET Forums
July 03, 2007

# IntelliTXT Advertsement & deployment query - ASP.NET Forums


Michael Freidgeim's Blog
July 04, 2007

# "Visual Studio 2005 is very slow" -some tips for ASP.NET projects


sreelatha
October 01, 2007

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hi,

this is good.When I m trying create a reusable user control, I opened a new poject in vs2005. But i m not finding the ASP.net web application template.it is missed. What should I do for this.How to get that template to my projects.

Regards
Sree

Josh
January 18, 2008

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hey Rick, great writeup, concur on many levels.

I was wondering now that VS2008 is becoming the next best thing, are you going to make a similar writeup of VS2008 You win some, you lose some?

I'd like to know if said bugs and irritations have been dealth with for you, would love to read about it! Thank you!

stuartdenley
September 03, 2008

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

I already learn ASP3.0 version and which is helpful too but after visiting west wind I'm able to learn more about asp as well as other related web programming tutorials.

Stuartdenley

The Fastest, Easiest way to learn DotNetNuke! Free Trial Lessons!!
<a href="http://www.applydnn.com">http://www.applydnn.com</a>

synjones
September 03, 2008

# re: ASP.NET 2.0 and Visual Studio 2005: You win some, you lose some

Hi to every body,Its great to have such blogs were we can get lots of information on the ASP.NET.I feel that the DotNetNuke 4.0 works fine in Visual Web Developer Express, SQL Express, and Cassini and still uses an architecture which completely based on dynamic loading of user controls.

synjones
The Fastest, Easiest way to learn DotNetNuke! Free Trial Lessons!!
<a href="http://www.applydnn.com">http://www.applydnn.com </a>
 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017