70-515 – .NET 4 Web applications exam prep resources

The .NET Code Catto has some brilliant pages to help you prepare for the 70-515 .NET web applications exam

http://chriscatto.blogspot.com/search?q=70-515

he doesn’t even have one good blog entry but there are quite a few.  What I found most useful is the layout of the information, it helps keep the exam in mind all the time by focusing on what you are being tested on.

This is an extract of one of the pages but there are some other posts which are probably more useful

Developing Web Forms Pages (19%)

  • 1.1 Configure Web Forms pages.
  • 1.2 Implement master pages & themes.
  • 1.3 Implement globalization.
  • 1.4 Handle page life cycle events.
  • 1.5 Implement caching.
  • 1.6 Manage state.

2 Developing and Using Web Forms Controls (18%)

  • 2.1 Validate user input.
  • 2.2 Create page layout.
  • 2.3 Implement user controls.
  • 2.4 Implement server controls.
  • 2.5 Manipulate user interface controls from code-behind.

3 Implementing Client-Side Scripting and AJAX (16%)

  • 3.1 Add dynamic features to a page by using JavaScript.
  • 3.2 Alter a page dynamically by manipulating the DOM.
  • 3.3 Handle JavaScript events.
  • 3.4 Implement ASP.NET AJAX.
  • 3.5 Implement AJAX by using jQuery.

Configuring and Extending a Web Application (15%)

  • 4.1 Configure authentication & authorization.
  • 4.2 Configure providers.
  • 4.3 Create and configure HttpHandlers and HttpModules.
  • 4.4 Configure initialization and error handling.
  • 4.5 Reference and configure ASMX and WCF services.
  • 4.6 Configure projects and solutions, and reference assemblies.
  • 4.7 Debug a Web application.
  • 4.8 Deploy a Web application.

Displaying and Manipulating Data (19%)

  • 5.1 Implement data-bound controls.
  • 5.2 Implement DataSource controls.
  • 5.3 Query and manipulate data by using LINQ.
  • 5.4 Create and consume a data service.
  • 5.5 Create and configure a Dynamic Data project.

6 Developing a Web Application by Using ASP.NET MVC 2 (13%)

  • 6.1 Create custom routes.
  • 6.2 Create controllers & actions.
  • 6.3 Structure an ASP.NET MVC application.
  • 6.4 Create and customize views.

Here is a list of good flix too along with a summary of them.

Also the WhitePaper & Scott Gu have some good .NET 4 content

 

Advertisements

ASP.NET Web Forms Free Introduction video

A fellow developer was sharing the wealth this week and found that Microsoft have put up a load of new free videos from Pluralsight for ASP.NET Web Forms.  You can go to this

http://www.asp.net/web-forms

Below is a breakdown of the 9 video modules in the ASP.NET Web Forms series:

This is a good resource for people like me who are studying for the 70-515 exam.

Remote Debugging in ASP.NET

For the 70-515 .NET 4 web certification there is a chapter on debugging your web projects.  This is a pretty useful thing to know about.  In fact the last chapter I read was about setting up profiles in web sites/web applications which I also found quite useful.

I have never really done any remote debugging of web applications so it is a useful tool to understand.  Usually I prefer to run a test program on my machine which connects to the data but I appreciate there will be occasions where that isn’t possible.

I also had some problems today when.the visual studio wasn’t ran as administrator.  Although I set up Visual studio to run as an administrator, it didn’t seem to do this if you open it by clicking on a project file.

I have found a couple of good articles about setting up remote debugging

http://www.codeproject.com/KB/aspnet/IISRemoteDebugging.aspx

How to:setting up remote debugging

I have also found a couple of interesting youtube videos on the subject

http://www.youtube.com/watch?v=EEp6VqUg2WE

http://www.youtube.com/watch?v=zVC3vvuauqA&feature=related

 

70-515 – Introduction to MVC 2 Videos

I have been studying the 70-515 .NET 4 Web Certification since the start of the year.  I am using a few different sources of information but the main one is the MCTS Self-Paced Training Kit (Exam 70-515): WEb Applications Development with Microsoft .NET Framework 4 book.  Yes I agree it’s a catchy title which they must have spent  a long time deciding on, well along time saying it that’s for sure.

This book is excellent, it describes things in an easy to understand way, the only complaint I have is it’s massive, I have worked out it’s 880 pages and today I have gone past the half way stage, yes I have read 441 pages.  If you would like to buy the book, get over to Amazon here

I am also watching some videos and today I watched a video on MVC 2, which features loads on the practise exam questions I have been testing myself with.  Before I watched the video I was terrible at the MVC 2 questions but I had to wait until round to learning it because there are loads of things to learn for the 70-515 exam.

I have to say my first impression of MVC 2 is it’s confusing and it seems like you have to put loads of configuration values in classes and within error prone “TEXT” strings.

I don’t think I fully understand it yet but my first look is it reminds me a bit of the Java framework Struts and Spring which used to filter messages to and from the backend to the frontend.  The beauty of Struts and Spring was you put all your mapping into xml files which seems easier to deal with because all the vales were in the same place.  You also had to create folders in correct locations, whilst I was watching the videos I thought it must be very difficult to bug fix an MVC 2 solution if you had done something wrong in the setup.

I can imagine that it would be quite complex if you had loads controllers and views

The first thing I have noticed is that I have started to understand the questions on my practise test.  I also noticed in a few places there is MVC 3, bloody hell I haven’t learnt MVC 2 yet.

So I thought I would give myself some homework to learn more about MVC 2 before I read the chapter on it and here are some links
http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman

http://www.asp.net/mvc/videos/how-to-best-learn-asp-net-mvc

http://www.asp.net/mvc/videos/understanding-models-views-and-controllers

http://bradwilson.typepad.com/blog/2010/04/advanced-aspnet-mvc-2.html

 

Understanding the Web.config file

Whilst I am studying for the 70-515 .NET Web applications exam, you are consitently adding things to the web.config file.  It was only whilst reading the self study book that I learnt each .NET framework will have it’s own machine.config.

Web.config works in a programming way because it uses inheritence in a roundabout way.  You have the machine.config, which is overwritten by application level Web.config, any values in here will overwrite the values in the machine.config but rather than put all the details into the Web.config you just put the values you want to change.

Then each website/web application has it’s own web.config which only overwrites the values it wants to change.  ASP.NET does a pretty good job of updating the Web.config file for you but it is good to know what the web.config file looks like and how to manually edit it because you will certainly need to.

 

Today I found a great article below which is written  by Ruben Heetebrij called The ASP.NET Web.config file Demystified, it really explains the Web.config in detail.


Applications of XML have been integrated into .NET to such an extent that XML is hardly a buzzword anymore. Microsoft, as you probably know, has taken XML into the core of its .NET framework. Not only is XML a generally accepted format for the exchange of data, it’s also used to store configuration settings.

Configuration settings for any of your ASP.NET Web applications can be stored in a simple text file. Presented in an easily understandable XML format, this file, called Web.config, can contain application-wide data such as database connection strings, custom error messages, and culture settings.

Because the Web.config is an XML file, it can consist of any valid XML tags, but the root element should always be <configuration>. Nested within this tag you can include various other tags to describe your settings. Since a Web.config file comes as a standard when you start to build a new Web application, let’s look at the default XML file generated by Visual Studio .NET:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>
<customErrors
mode="RemoteOnly"
/>
<authentication mode="Windows" />
<authorization>
<allow users="*" />
</authorization>
<trace
enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"
/>
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>

</system.web>

</configuration>

Experienced ASP.NET programmers will have noticed that I’ve left out the comment tags that are generated automatically with the file. I’ve done that to provide a clear view of the XML that’s used here. Also, I’ll elaborate on each configuration tag later in this article, and this discussion will make the comment tags rather obsolete.

If you look at the example XML, you’ll notice that the <configuration> tag has only one child tag, which we call section group, the <system.web> tag. A section group typically contains the setting sections, such as:compilationcustomErrorsauthenticationauthorization, etc. The way this works is pretty straightforward: you simply include your settings in the appropriate setting sections. If, for example, you wanted to use a different authentication mode for your Web application, you’d change that setting in the authentication section.

Apart from the standard system.web settings, you can define your own specific application settings, such as a database connection string, using the <appSettings> tag. Consequently, your most common Web.config outline would be:

<configuration>
<system.web>
<!— sections-->
</system.web>
<appSettings>
<!— sections -->
</appSettings >
</configuration>

Let’s discuss the details of both section groups now.

The system.web Section Group

In this section group, you’ll typically include configuration settings that, in the pre-.NET era, you’d have set up somewhere in the IIS administration console. At Microsoft’s MSDN Library, you can find an overview of all the tags that the system.web section group understands, but, depending on the complexity of your site, you may not ever use even half of those options.

Let’s have a look at the most valuable tweaks you can make within the system.web section group, in alphabetical order.

<authentication>

The authentication section controls the type of authentication used within your Web application, as contained in the attribute mode. You’ll enter the value “None” if anyone may access your application. If authentication is required, you’ll use “Windows”, “Forms” or “Passport” to define the type of authentication. For example:

<authentication mode="Windows" />

<authorization>

To allow or deny access to your web application to certain users or roles, use <allow> or <deny> child tags.

<authorization>
<allow roles="Administrators,Users" />
<deny users="*" />
</authorization>

It’s important to understand that ASP.NET’s authorization module iterates through the sections, applying the first rule that corresponds to the current user. In this example, users carrying the role Administrators or Users will be allowed access, while all others (indicated by the * wildcard) will encounter the second rule and will subsequently be denied access.

<compilation>

Here, you can configure the compiler settings for ASP.NET. You can use loads of attributes here, of which the most common are debug and defaultLanguage. Set debug to “true” only if you want the browser to display debugging information. Since turning on this option reduces performance, you’d normally want to set it to “false”. The defaultLanguage attribute tells ASP.NET which language compiler to use, since you could use either Visual Basic .NET or C# for instance. It has value vb by default.

<customErrors>

To provide your end users with custom, user-friendly error messages, you can set the mode attribute of this section toOn. If you set it to RemoteOnly, custom errors will be shown only to remote clients, while local host users will see the ugly but useful ASP.NET errors — clearly, this is helpful when debugging. Setting the mode attribute to Off will show ASP.NET errors to all users.

If you supply a relative (for instance, /error404.html) or absolute address (http://yourdomain.com/error404.html) in thedefaultRedirect attribute, the application will be automatically redirected to this address in case of an error. Note that the relative address is relative to the location of the Web.config file, not the page in which the error takes place. In addition you can use <error> tags to provide a statusCodeand a redirect attribute:

<customErrors mode="RemoteOnly" defaultRedirect="/error.html">
<error statusCode="403" redirect="/accessdenied.html" />
<error statusCode="404" redirect="/pagenotfound.html" />
</customErrors>

<globalization>

The globalization section is useful when you want to change the encoding or the culture of your application. Globalization is such an extensive subject that an entire article could be dedicated to the matter. In short, this section allows you to define which character set the server should use to send data to the client (for instance UTF-8, which is the default), and which settings the server should use to interpret and displaying culturally specific strings, such as numbers and dates.

<globalization requestEncoding="utf-8" responseEncoding="utf-8"
culture="nl-NL" />

Encoding is done through the attributes requestEncoding and responseEncoding. The values should be equal in all one-server environments. In this example, the application culture is set to Dutch. If you don’t supply a culture, the application will use the server’s regional settings.

<httpRuntime>

You can use the httpRuntime section to configure a number of general runtime settings, two of which are particularly convenient.

<httpRuntime appRequestQueueLimit="100" executionTimeout="600" />

The first attribute specifies the number of requests the server may queue in memory at heavy-traffic times. In the example, if there are already 100 requests waiting to be processed, the next request will result in a 503 error (“Server too busy”).

The executionTimeout attribute indicates the number of seconds for which ASP.NET may process a request before it’s timed out.

<sessionState>

In this section of the Web.config file, we tell ASP.NET where to store the session state. The default is in the process self:

<sessionState mode="InProc" />

Session variables are very powerful, but they have a few downsides. Information is lost when the ASP.NET process crashes, and sessions are generally useless in the case of a Web farm (multiple Web servers). In that instance, a shared session server can solve your issues. It’s beyond the scope of this article to expand on this topic, but it’s worth a mention. More information on sessionState can be found in the MSDN Library online.

<trace>

Your application’s trace log is located in the application root folder, under the name trace.axd. You can change the display of tracing information in the trace section.

The attributes you will look for initially are enabled: localOnly, and pageOutput.

<trace enabled="true" localOnly="true" pageOutput="false" />

Set localOnly to “false” to access the trace log from any client. If you set the value of pageOutput to “true”, tracing information will be added to the bottom of each Web page.

The appSettings Section Group

Apart from the Website configuration settings I’ve been talking about in the preceding paragraphs, you’ll know that a programmer frequently likes to use custom application-wide constants to store information over multiple pages. The most appealing example of such a custom constant is a database connection string, but you can probably think of dozens more from your own experience.

The common denominator of these constants is that you want to retrieve their values programmatically from your code. The Web.config file provides the possibility to do so, but as a security measure, these constants have to be included in the <appSettings> section group. Just like <system.web><appSettings> is a direct child tag of the Web.config’s configuration root.

A typical custom section group would look something like this:

<appSettings>
<add key="sqlConn" value="Server=myPc;Database=Northwind" />
<add key="smtpServer" value="smtp.mydomain.com" />
</appSettings>

The example shows that keys and values can be included in the custom application settings via an <add> tag. The way to access such a value in any of your Web pages is illustrated below:

ConfigurationSettings.AppSettings("sqlConn")

Yes, it’s as easy as that! Note that the value of these settings is always a String format.

A Few Other Issues

I won’t go into them here, but the Web.config file can contain several other section groups besides the aforementioned system.web and appSettings, such as the configSettings group.

 

  • A Web application can contain more than one Web.config file. The settings in a file apply to the directory in which it’s located, and all child directories. Web.config files in child directories take precedence over the settings that are specified in parent directories.
  • Web.config files are protected by IIS, so clients cannot get to them. If you try to retrieve an existing http://mydomain.com/Web.config file, you’ll be presented with an “Access denied” error message.
  • IIS monitors the Web.config files for changes and caches the contents for performance reasons. There’s no need to restart the Web server after you modify a Web.config file.

 

Closing Remarks

In this article, I’ve touched upon the possibilities that the Web.config file offers the ASP.NET programmer. You can use the easily accessible XML file to define your application settings, without the hassle of using the IIS management console. With the Web.config file, ASP.NET lets you add, change and delete basic configuration settings like authentication and authorization, custom error displaying, and tracing in a straightforward manner.

Moreover, the Web.config file offers you room to define any custom key you require, such as database connection strings. What we’ve subsequently seen is that, with just one line of code, you can retrieve the information you need from any page in your application.

 

web.Config Error – duplicate scriptResourceHandler section defined

this was the annoying error I was being plagued with today

Config Error There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’ section defined

I was getting this error today and it was very annoying but then when you work out what the problem is quite interesting, especially if like me you are studying for the 70-515 .NET web applications exam.

A bit of background.  I had created a website, it was a demo website and in the website it had a sectionGroup with the name of scripting.

<sectionGroup name=”scripting” type=”System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>

When I tried to run the website it then popped up with the annoying duplicate error.

The way ASP.NET works is you have default settings held in the machine.config.  These are used by all Web sites using that version of .NET, in this case 4.

When you create a website, you can over write the machine.config settings and have local setting specified in your web apps web.config.

 

The reason I was getting duplicate errors was because it was almost the same reference, except one of them was 3.5 and one of them was 4.0.  Depending on what server you have got (in on iis 7) you can find the machine.config somewhere around here

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config

 

local web.config

<sectionGroup name=”system.web.extensions” type=”System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″>

 

machine.config

<sectionGroup name=”scripting” type=”System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>

 

to solve the problem I deleted the sectiongroup from my local web.config and then the problem went away.

for more information I found these web links useful

http://forums.iis.net/t/1149226.aspx

http://www.britishdeveloper.co.uk/2010/03/there-is-duplicate-systemwebextensionss.html