Hi,

I'm a new ASP.net programmer, currently taking a course 70-528(w/C#), I know the best answer to this question is "it depends", but can you experienced ASPers give me a rough approximation of how much time you spend doing markup vs. code-behind programming?  When I started this class, I had hoped (or at least it seemed) that most of the Markup would be automatically generated when I dropped controls onto the website's design page.  But, as I continue with the course, I'm finding more and more instances where I have to spend a considerable amount of time doing markup.  Being a solid vb.net programmer from before, I had hoped to spend more time programming in C#, but it seems like I need to increase my xml skills as well...

Also, closely related to this line of questioning, I noticed a couple times (for instance, when creating a wizard control), that I'd click the wizard step page, drop some controls in the wizard, only to find that when I got into the markup, the controls were put underneath the wizard, as opposed to in the correct step page(of the wizard).  Is this a common occurrance, where you drop controls on the page, but need to always look at the markup and fix their locations?

If these issues have been fixed in 3.5, feel free to say that as well...as I'm stuck in a class in 2.0, but fully plan to upgrade to 3.5 when I finish these courses.

Thanks,

Sitko.

 It depends. 

It will depend mostly on how complex of an interface you have versus how complex of an application you are working on.  My applications tend to be reasonably complex on both sides, so I average pretty close to half of my time on either one, maybe 55-60% of my time on code-behind. 

What I typically do is start from a web application template that I have built.  There are no bells or whistles.  It is a very basic interface.  From there, I spend a good deal of time working on my server logic and code architecture for the application itself, so most of my time in the beginning is spent almost exclusively on code behind.

Once the application begins to take shape, however, I share my time pretty evenly on code-behind and markup when I start working on administrative controls for my content management pieces. 

Toward the end, I'll work more on markup to clean up the interface a little and do tweaks on interactive pieces.

XML...  Well, yeah, XML is an important thing to learn as it is a vital component for AJAX-driven architectures (I prefer JSON, but XML is still good for clients that don't speak javascript).  The future of computing will see more and more complex web applications with rich interfaces and XML is one of the types of glue that hold it all together.  XML is actually very simple in and of itself.  Your "XML Skills" will be more in how you use XML.  Some people overuse XML because it sounds cool (any three letter acronym sounds cooler if it has an X), but have no real idea what it is really intended for.  I've seen some people use obscenely large XML files instead of databases, not for portability or offline capabilities, but because they thought XML was cool.  What a mess that was.