Home - kennedy

6/30/2009

\labs\lab 7 - masterpages\Lab7masterpages.html

This lab gets you to add in a master page to the site managing the Northwind database. It then gets you retrofit an existing page to use the new master page.

\labs\lab 8 - sitenavigation\Lab8sitenavigation.html

This lab gets you to use a treeview control to access a sitemap and add in navigational capabilities to our Northwind site.

\labs\lab 10 - security\Lab10security.html

This lab gets you to add in login capabilites to our Northwind site, including a login page, etc.

Again, lab solutions for all these labs should be in the Solutions folder in the directory with the lab directions.

Posted at 10:39 AM by Stephen Kennedy | Category: Session 7 | Permalink | Email this Post | Comments (0)

6/29/2009

Evaluation Form

Here is the Course Evaluation form. If you could download it, fill it out, and email it to the phs-help@infusion.com alias, that'd be appreciated.

Thanks.

Stephen

Posted at 12:56 PM by Stephen Kennedy | Category: General | Permalink | Email this Post | Comments (0)

6/23/2009

Globalizing Web Sites and You

In one of the labs for this session, you were asked to globalize a page in our DVD website by getting the default.aspx page to support not only english but french. This was achieved by creating an App_LocalResources folder (one of the 'special' pre-defined folders supported by ASP.NET infrastructure), and then generate language resource files.

Obviously, some of this was automated (resource file creation) while some of it was manual (add in the language-specific resources). Also, we fudged things a bit to save you from having to modify the regional settings in your OS by hard-coding the UICulture and Culture attributes in the Page directive in the .aspx page. The point was that the browser will automatically send the preferred culture, based on the OS regional settings, to the server as part of the HTTP request message, so ASP.NET will automatically use that to assist in populating controls with the available language strings/resources.

However, many organizations mandate that the supporting languages available on their sites should be selectable rather than based on OS regional settings (implying that we can't expect every internet user to have changed their regional settings in the OS prior to visiting the site). To accomplish this, we find we have to do a lot more manual work.

First, for explicit globalization, we can add a drop-down to the page offering supported languages for that site. Then we need to generate the appropriate resource files. Herein lies the big difference with explicit globablization -- resource files have to be created and placed in the App_GlobalResources folder. Resource file naming conforms to similar naming for that of page-specific resource files in the App_LocalResources folder (Resource.resx for default resources, Resource.<culture code>.resx for supported cultures).

Next we need to add code to the Page_PreInit event handler.

        if (Request.Form["DropDownList1"] != null)
        {
            string culture = Request.Form["DropDownList1"].ToString();
            Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(culture);
            Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo(culture);

            Label2.Text = Resources.Resource.Label2Resource1;
            btnSearch.Text = Resources.Resource.btnSearchResource1;
            HyperLink1.Text = Resources.Resource.HyperLink1Resource1;
        }

Here we first check to ensure there is a DropDownList1 control (there won't be on the very first request from the end user). Then we get the selected language code from the existing dropdownlist, and use that to set the CurrentUICulture and CurrentCulture of the current thread (setting the this.UICulture and this.Culture properties would have the same effect). THEN, we must manually populate the desired controls with culture resources (as we do here with the three controls).

So, whereas supporting implicit (based on OS/browser regional settings/culture) globalization was relatively automatic, explicit globalization support in ASP.NET is a bit more work.

Here is the lab solution, but using explicit globalization.

Posted at 9:30 PM by Stephen Kennedy | Category: Session 6 | Permalink | Email this Post | Comments (0)

Session 6 - Labs

We have two labs for this week's session.

Download Localization lab here.

This lab gets you to create a localizable web page -- a page that supports English as well as another language. The lab, and also doing so for a production application is relatively easy. One thing to note is the lab saves you from having to modify your OS regional settings to mimic someone who prefers another language when visiting our site, but hard-coding the culture into the page itself. In reality, the browser would send this information to the server and our page would send back the page with the appropriate languages strings. Also, if we wanted to give the end user a selection of languages from which to choose, we would have to add code to the Pre_Init event handler for the page to determine which language they may have chosen from the language drop-down box (which we would have to add in) and set the culture/language manually in code.

\labs\lab 9 state\lab9state.html

This lab gets you to extend a page you created previously where the end user selected some suppliers, and the list of suppliers appeared on the page. Here you will have a new page display the list of selected suppliers. As always for this lab, note that the file location where they suggest retrieving the starter website (if you need it) is incorrect. It should be \labs\lab 8 sitenavigation\Solution\Northwind

All solutions for these labs should be in the folder with the lab directions in the Solution folder.

Posted at 8:45 PM by Stephen Kennedy | Category: Session 6 | Permalink | Email this Post | Comments (0)

6/22/2009

Session 5 - Code Notes

This is a synopsis of Session 5's lecture and demonstrations. It's probably geared at those who missed the June 15th presentation, but also delivers on my promise to post code.

ADO.NET

ADO.NET is a nice way of saying "Data Access for .NET". It's actually all the classes that can be found in the System.Data.dll assembly. We'd be lying if we said most of those classes allow for access to relational data stores like SQL Server, Oracle, etc. So it doesn't apply to Caché directly. But in most cases, PHC should have already built assemblies for working with Caché. But it's useful to see what ADO.NET offers for, in the very least, the DataSet object.

Above is ADO.NET. The Connection object stores info about where the DB is and who you're accessing as. The Command object stores the SQL statement or Stored Procedure you're looking to call. The DataReader is a forward-only read-only cursor to loop through a set of data. The DataAdapter is the go-between for those objects and the DataSet.

The DataSet can be used, or simply thought of as an in-memory database. It doesn't have to be used as such, however, and is really just a client-side static disconnected cursor. What makes it useful is that it stores data in DataTables, often copies of the relational database equivalent, while supporting relations between the tables. Each table is just a bunch of DataRows and DataColumns. If you never use the DataSet to load data from a relational database, that's fine, but as you can see from the above graphic, it supports loading of XML. This means that there's a built-in algorithm to parse almost any hierarchical XML file and load it into relational tables. This is a powerful feature, as it gives an alternative to working with XML using something like a DOM (XmlDocument in the System.XML.dll).

If I had an XML file, that looked something like this:

<?xml version="1.0" encoding="utf-8" ?>
<Patients>
  <Patient>
    <Name>Stephen Kennedy</Name>
    <PatientID>234224</PatientID>
  </Patient>
  <Patient>
    <Name>Kim Black</Name>
    <PatientID>455364</PatientID>
  </Patient>
</Patients>

I could create a web page to load the patient list into a dropdown box by using the DataSet as so:

	DataSet ds = new DataSet();
        ds.ReadXml(Server.MapPath("Patients.xml"));
        for(int i =0;i<ds.Tables[0].Rows.Count;i++)
        ListBox1.Items.Add(ds.Tables[0].Rows[i]["Name"].ToString() + " " +
            ds.Tables[0].Rows[i]["PatientID"].ToString());

Here, we instantiate a DataSet and call the ReadXml method which can read a file from a FileStream. If we assume the XML is in a file called Patients.xml, we use Server.MapPath to get an absolute path to the file on the HDD of the web server. Then we just use a for loop to go through the DataRows in the first DataTable and put the PatientID column and Name column concatinated into the ListBox.

The only downside to the DataSet is that it is loosely typed (and Microsoft doesn't offer a Generic version of it). However ... we can make a Typed DataSet which is strongly typed to a database table or XSD schema.

To do so, we can get the schema for our Patients.xml file (in Visual Studio, from the XML menu, select Create Schema.

It might look something like this:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Patients">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" name="Patient">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="Name" type="xs:string" />
              <xs:element name="PatientID" type="xs:unsignedInt" />
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

If we save this to disk, we can use the command-line xsd.exe tool to create a class from the xsd. (use xsd.exe /d Patients.xsd).

The resulting file will contain a subclass of DataSet that has one Table and any number of rows, but columns are now strongly typed to not only the datatype but the value name. The equivalent code to load a list of patients into a dropdown box from a Typed DataSet would look like this:

    Patients patients = new Patients();
        patients.ReadXml(Server.MapPath("Patients.xml"));
        for (int i = 0; i < patients.Patient.Count; i++)
            ListBox1.Items.Add(patients.Patient[i].Name + " " + 
                patients.Patient[i].PatientID.ToString());

Notice how patients.Patient[i].Name replaces patients.Tables[0].Rows[i]["Name"].ToString(). It's now much more efficient.

Web Services

By web services, we mean assemblies of code residing on a web server (typically) that we can call like regular assemblies, but remotely across the Internet using open standards.

There's a special Visual Studio template for Web Service projects/websites and services. The service takes the form of .asmx files. You can add a web service to any web site by right-clicking on your website and selecting Add New Item and choosing Web Service from the list. This will generate an .asmx file and a corresponding .cs file which is placed in the App_Code folder. In this file you have a class which subclasses the WebService base class, and a sample web method, HelloWorld. (it's marked by the WebMethod attribute. More on Attributes in my aside.

You can add more Web Methods by adding more functions and marking with with the WebMethod attribute. Your code could resemble the following:

[WebMethod]
    public string HelloWorld()
    {
        return "Hello World";
    }
    [WebMethod]
    public int Add(int x, int y)
    {
        return x + y;
    }
    [WebMethod]
    public DataSet GetPatientDataSet()
    {
        DataSet ds = new DataSet();
        ds.ReadXml(Server.MapPath("Patients.xml"));
        return ds;
    }
    [WebMethod]
    public string GetPatientXML()
    {
        DataSet ds = GetPatientDataSet();
        return ds.GetXml();
    }
    [WebMethod]
    public Patient[] GetPatientObject()
    {
        DataSet ds = GetPatientDataSet();
        Patient[] patients = new Patient[ds.Tables[0].Rows.Count];
        for (int i = 0; i < ds.Tables[0].Rows.Count; i++)
        {
            patients[i] = new Patient(ds.Tables[0].Rows[i]["Name"].ToString(),
                ulong.Parse(ds.Tables[0].Rows[i]["PatientID"].ToString()));
        }
        return patients;
    }

Here we have a number of basic methods, each marked with the WebMethod attribute: HelloWorld; Add, which adds two numbers together; GetPatientDataSet which is a copy of the above code that generates and returns a DataSet of patients; GetPatientXML which starts with a DataSet but returns raw XML; and GetPatientObject, which, although starting with a DataSet, returns an array of custom Patient objects. Those objects would look like the following:

[Serializable]
public class Patient
{
    public Patient()
    {
    }
    public Patient(string name, ulong patientID)
    {
        Name = name;
        PatientID = patientID;
    }
    public string Name { get; set; }
    public ulong PatientID { get; set; }
}

Web Services are supposed to be all about open standards and an easy exchange of data, but even in the Web Service standard, there are ways to interpret how to implement it that could be contradictory to other APIs (.NET and Java sometimes don't talk right when it comes to Web Services). In the above, GetPatientDataSet, GetPatientXML and GetPatientObject all return the same data, but just in different formats: DataSet, XML text, and array of custom objects, respectively. In order of "easiest to consume" or "most open", we have XML, Array of object, and DataSet. The DataSet is fine if the client consuming/calling the Web Service is .NET based, but near impossible to use otherwise. So that's why the other choices are in the code sample.

You can test a web service by right-clicking on the .asmx file and selecting View in Browser. It will result in a page which might allow you to test the methods in a browser by clicking links (don't always count on this however).

To create a client, one simply right-clicks on a project in Visual Studio and selects Add Web Reference or Add Service Reference (the latter is generally exclusive to VS2008, or VS2005 with .NET 3.0 addins). The former isn't always available in VS2008 either.

Simple add in the web address of the .asmx file and select Add Reference or OK (in the case of a Service Reference).

Then in the client code, call the classes as you normally would.

ServiceReference1.PatientInfoSoapClient c =
               new ConsoleApplication2.ServiceReference1.
                    PatientInfoSoapClient();
            ServiceReference2.Patient[] ds = sc.GetPatients();
            for (int i = 0; i < ds.Length; i++)
                Console.WriteLine(ds[i].Name);

You can also call available remote web services that people have exposed across the Internet. xmethods.net lists a few. http://www.ebob42.com/cgi-bin/Romulan.exe/soap/IRoman is a web service (based in the Netherlands, I believe) written in Delphi that you can call from .NET. You add a reference to it as you would expect with the Add Reference/Add Service Reference.

Data Binding

Data Binding offers a way to automatically populate controls with data from a data source of some sort. In .NET a data source can take the form of a relational database table, a web service, or a data object.

To manually bind to a DataSet, you could use the following code:

	MyGrid.DataSource = ds;
         MyGrid.DataBind ();

The GridView is just one bindable control. The Repeater is also bindable and allows more customizable display of information (see the slides).

.NET also supports DataSource objects. These are Web Server Controls which wrap up an object, DB connection, Web Service, or XML file to allow for easy binding. ASP.NET has the SqlDataSource, XmlDataSource and ObjectDataSource. Of these, the last is of the most useful.

By dragging and dropping an ObjectDataSource onto a Web Form, you can configure it to expose methods of a class that might return a DataSet, for example, and then bind a GridView control to the ObjectDataSource control.

The HTML might look like the following:

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" 
            DataSourceID="ObjectDataSource1">
            <Columns>
                <asp:BoundField DataField="Name" HeaderText="Name" SortExpression="Name" />
                <asp:BoundField DataField="PatientID" HeaderText="PatientID" 
                    SortExpression="PatientID" />
            </Columns>
        </asp:GridView>
    
    <asp:ObjectDataSource ID="ObjectDataSource1" runat="server" 
        SelectMethod="GetPatientObject" TypeName="PatientInfo">
    </asp:ObjectDataSource>

Here, the method GetPatientObject is called from an instance of PatientInfo, returning an array of custom PatientInfo classes. This is bound to by the GridView, which displays the Name and PatientID properties of the PatientInfo class.

The Session 3 lab, DataBinding, also utilizes the SqlDataSource and a GridView to create an updatable grid to change data from a database.

WCF

For the materials on WCF, I've resurrected the blog post I put together for the previous PHC training. It's available off the main page, Session 5 or here:

http://home.infusionblogs.com/skennedy/Lists/Categories/Category.aspx?Name=Session%205

It's titled WCF and You.

Posted at 8:23 PM by Stephen Kennedy | Category: Session 5 | Permalink | Email this Post | Comments (0)

WCF and You

When we completed Session 5, I noted that there was some additional materials on Windows Communication Foundation (.NET 3.0) that we weren't able to get to (it's a "nice to have" situation). So I figured I'd blab on about that.

We'll take the very narrow approach that WCF is an alternative, and debatably a replacement for .NET 2.0 .asmx XML Web Services. I say "narrow approach" because WCF does so much more than just HTTP/XML/SOAP web services. But we'll address that later.

Again, a quick synopsis: .NET 2.0 web services offer an interoperable approach to remote calls to code across the intranet/internet, and does so quite well. Your average web service might look something like this (yes, yes, you would probably use a code-behind page, but I'm trying to keep my code pithy):

class MyService:System.Web.Services.WebService
{
    [System.Web.Services.WebMethod]
    public System.String HelloWorld() {
        return "Hello World";
    }
}

And the client code to consume the remote web service might look something like this (after having set a Web Reference or run the wsdl.exe utility):

localhost.MyService service = new localhost.MyService();
Label1.Text = service.HelloWorld();

And this has worked for years. I mentioned that out-of-the-box, MS gave security capabilites for web services, but a few would be available to .NET only client/service calls. In terms of industry standard security features, we could download the Web Service Enhancements 3.0 to augment our .NET 2.0 service. And this works quite well.

MS decided to take the capabilities of .NET 2.0 web services and WSE 3.0 and combine them, along with distributed transactions (COM+), asynchronous messaging (MSMQ), TCP and other transport calls (.NET Remoting) to create a more unified API and service building strategy. Thus WCF was born.

One of the beauties of WCF is that you create your code, your service, independent of how it might be called by a client, or how you will be exposing it to a client. The infrastructure of protocol, security, etc., can be slapped onto the service later (so you can build the service, then decide if it's going to be an interoperable web service or a .NET only remoting service). In addition, you can choose to expose a service (your code) through more than one binding protocol (so I can build a service, and expose it through HTTP for non .NET clients at the same time as exposing it through TCP for .NET clients).

Let's break down the details (code and otherwise).

First is this is all based on .NET 3.0 which needs to be installed on the client calling a service, but also on the server box hosting the service. You should be able to use WCF on the client to call a .NET 2.0 web service if you wish.

The WCF Service:

First, to assist in promoting the idea that the production service and interface through which it can be called should be a contract, WCF gets us to create an interface which is annotated with the ServiceContract attribute.

[ServiceContract()]
public interface IMyService
{
    [OperationContract]
    string MyOperation1(string myValue1);
    [OperationContract]
    string MyOperation2(DataContract1 dataContractValue);
}

Individual interface members are marked with the OperationContract attribute, indicating they are the exposed function signatures to potential clients. By implementing this as an interface type, it means we can switch off the actual implementation code quite easily so long as it supports this interface.

The actual implementation code might look something like the following:

public class MyService : IMyService
{
    public string MyOperation1(string myValue1) 
    {
        return "Hello: " + myValue1;
    }
    public string MyOperation2(DataContract1 dataContractValue)
    {
        return "Hello: " + dataContractValue.FirstName;
    }
}

It's just a regular class, that just so happens to implement/inherit from our contract interface.

That's almost everything we need. "Almost," because if we examing MyOperation2, we see it returns an instance of the class DataContract1. This is merely a custom class that we want to be able to serialize and send in to this method (or possibly send back as a return value). This would be implemented as follows:

[DataContract]
public class DataContract1
{
    string firstName;
    string lastName;

    [DataMember]
    public string FirstName
    {
        get { return firstName;}
        set { firstName = value;}
    }
    [DataMember]
    public string LastName
    {
        get { return lastName;}
        set { lastName = value;}
    }
}

Note the class is marked with DataContract whereas the members are marked with DataMember. This would be akin to marking a class as Serializable in .NET 2.0 .asmx web services.

So these pieces -- a required Service contract implemented as an interface, the implementation code created as a class inheriting from the service contract interface, and the optional Data Contract class representing a custom type we can use to send to and from the client code -- make up our service. Note not mention is made of how someone can call this code. We leave that to a config file.

For WCF, this code would reside in a class, exposed/linked to by a .svc file (with a <%@ ServiceHost directive instead of the .asmx <%@WebService directive).

As mentioned, the only real other piece for the service is the config file that specifies the binding information (how the client can call the service, and the service location). It might look something like this:

<system.serviceModel>
    <services>
      <service name="MyService" behaviorConfiguration="MEXGET">
        <endpoint contract="IMyService" binding="wsHttpBinding" address="http://localhost:1038/WCFService1/Service.svc"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>       
        <behavior name="returnFaults" >
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
        <behavior name="MEXGET">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceCredentials />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

The Service element specifies the name of the class the client will call (and that implements/inherits from our ServiceContract interface). Endpointcontract specifies the interface ServiceContract. binding is a key one; it specifies the 'how' - the protocol the client will have to use to communicate with the service. Here is a master list of the binding options. The address is the URI where the service can be called.

Below the list of services, are the list of supported behaviors. Here there are two: one, returnFaults, is great for development as it will give you detailed errors; two, MEXGET, aka, Metadata Exchange, which allows clients to get information on the service to they can call it. Notice that the MEXGET behaviour is configured for our service via the behaviorConfiguration attribute.

The WCF Client:

Our client, which will probably be the only way most of you will interact with WCF (if at all) in the short term, is created similarly to that in .NET 2.0 web services. We can right-click on the project and select Add Service Reference (instead of Add Web Reference) and put in the URI for the .svc file. OR, we can use svcutil.exe (instead of wsdl.exe) to create a proxy class that the client can call.

I won't include auto-generated proxy code, but the client code might look something like the following:

      MyServiceClient mc = new MyServiceClient();
      Label1.Text = mc.MyOperation1(TextBox1.Text);
      mc.Close();

We instantiate the proxy class (here MyServiceClient, as created by the svcutil.exe utility) and call the code (MyOperation1 wants a string and returns a string).

Note that the client too is oblivious to how the service is being called (at least the code doesn't specify). When the proxy class is generated, we do have to specify the address, and our Service Reference or svcutil.exe will create a .config which will contain all the required binding info, etc. (including security requirements, etc.).

Here is some sample working code for WCF.

At a high-level, MS describes WCF using the mantra ABC:
A - Address: where is the service

B - Binding: how do you talk to the service

C - Contract: what does the service do

The ABCs are specified in the web.config for the service, and implemented (at least for the C in Contract) as ServiceContract interfaces, implementing classes and DataContract input/output classes.

Again, you may not work with WCF (.NET 3.0) but this post gives you some idea of how MS has matured web services and the direction they're taking them in .NET.

Posted at 11:27 AM by Stephen Kennedy | Category: Session 5 | Permalink | Email this Post | Comments (0)

6/15/2009

Session 5 - Labs

From the labs zip file from previous Session:

\Labs\set 2\labs\lab 5 - adonet\Lab5adonet.html (ADO.NET)

This lab gets you to add a new class to a DAL component to assist in showing the list of Products. It utilizes the Class Diagram tool to help graphically add in the class and perform inheritance. The page to display the products is supplied for you. This lab builds on last week's labs, although there is a starter website for you (note, this starter site is in the \set 2\labs\lab 4 - collections\Solution\Northwind folder. Also, the starter files can be found in \Labs\set 2\labs\lab 5 - adonet\files

\Labs\set 2\labs\lab 6 - databinding\Lab6databinding.html (Data Binding)

Here you will add in a page to allow editing of Employees data from the Northwind database. It uses the SqlDataSource control.

Optional WCF Lab

Here is an optional WCF lab. It gets you to create a service, create a custom host, and eventually also host your service in IIS. The lab is courtesy of MS. Instructions are in 1 - Getting Started with the Windows Communication Foundation.xps, so you may need an xps reader to view them. In addition, if you are a VS2005 user, you'll have to download and install .NET 3.0, if you don't already have it installed (any guesses how you can tell what .NET Framework versions you have installed?). .NET 3.0 can be located for download here. It should work in either VS2005 or VS2008.

Posted at 9:33 PM by Stephen Kennedy | Category: Session 5 | Permalink | Email this Post | Comments (0)

6/2/2009

Lab Database Issues

Thanks to Louise, there are a couple of errors that have been brought to my attention.

In the first ASP.NET lab, you are to import some file into your newly created website. One such file is web.config, which lists configuration settings for your site, specifically in this case, a connection string to the database you've just setup. There's an error in the connection string:

<add connectionString="server=infusionxpsp2\sqlexpress;database=Northwind;Integrated Security=True" name="northwinddb" />

should be

<add connectionString="server=.\sqlexpress;database=Northwind;Integrated Security=True" name="northwinddb" />

I believe this is the only occurance of this error in thje labs.

The other error is potentially more complicated to fix.

If (after fixing the above error) when you try to "View in Browser" Customers.aspx, you get a

Cannot open database "Northwind" requested by the login. The login failed.
Login failed for user 'PARTNERS\xxx'

then this error applies to you.

When installed, SQLExpress (and SQL Server) is configured for Windows Integrated Security, meaning if your Partners network login is not an admin on your machine, you will not be able to access any database in SQL Server.

The fix is to enable Mixed (Windows + SQL Server) Security to allow you to register custom user IDs and passwords with SQL Server. There are a few steps:

From a command prompt, run regedit.exe (we have to edit the registry to enable Mixed Security)
Expand the folders/settings for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSMQL.4
Locate the LoginMode setting, double-click on it and change the value from 1 to 2 and click OK
You have to restart SQL Express to have the setting take effect. From the Start button, (All) Programs, Administrative Tools, Services, locate SQL Server (SQLEXPRESS) in the list of services, right-click on it and select Restart
We now need to add a new account into SQL Express. Open a Visual Studio Command Prompt (Start --> (All) Programs --> Microsoft Visual Studio 2005(8) --> Visual Studio Tools --> Visual Studio 2005(8) Command Prompt)
Type in the following to start the SQL Express command-line interface:
```
osql -E -S .\sqlexpress
```
Enter in the following five lines, replacing username with whatever username you prefer, and password with whatever password you prefer. Don't forget these.
```
1>exec sp_addlogin 'username', 'password'
2>go
1>exec sp_addsrvrolemember 'username', 'sysadmin'
2>go
1>quit
```
Once again edit the web.config, and remove the Integrated Security=true setting from the connection string, replacing it with your user id and password, as such:

<add connectionString="server=.\sqlexpress;database=Northwind;user id=hank;password=mypass" name="northwinddb" />

If you view the page in the browser again it should now display a list of customers.

Posted at 4:03 PM by Stephen Kennedy | Category: Labs | Permalink | Email this Post | Comments (0)

6/1/2009

Class Postponement and Schedule

This is just a reminder about the schedule for the coming weeks:

Monday, June 1st -- Session 4

Monday, June 8th -- class cancelled/postponed

Monday, June 15th -- Session 5

Monday, June 22nd -- Session 6

Monday, June 29nd -- Session 7

Thanks.

Stephen

Posted at 11:03 AM by Stephen Kennedy | Category: General | Permalink | Email this Post | Comments (0)

Session 4 - Labs

As the first lab for Session 4, we can finish off our OOP lab that was begun in Session 2. (xlab_cs_oop_2 0.doc)

Specifically with this lab, we can complete the last bit needed in Milestone 1 ("Finally, the class should implement the IEnumerable interface so that users can traverse through its elements by means of a foreach statement. ") We know how to do this based on slide 158 (.NET 2.0: Iterators) in the slide deck. (There are other ways, but this is now the quickest and the most preferred way.) Note that with the generic IEnumerable and IEnumerator interfaces, in our case we are using int and not string.

The remainder of Milestone 3 can also be completed. It deals with things we've already done for MyList, but also includes adding three iterators (Forward, Backwards and SubSet). The absolute easiest way to accomplish this is NOT have your class implement IEnumerable, and merely add three methods with those names, that return IEnumerable<T> (since we're creating these iterators for a generic type, T). Then in the code for the three methods add functionality similar to that on slide 159 (.NET 2.0: Same Class, Multiple Iterators). (Note that is implies that you can create an iterator for a class following Microsoft's design pattern without implementing IEnumerable). Code to test your new generic list is

 MyGenericList ml = new MyGenericList(new int[] { 1, 2, 3, 4, 5 });

            Console.WriteLine("ToString: {0}", ml.ToString());
            if (ml)
                Console.WriteLine("List can accept additional elements");

            foreach (int i in ml.Forward())
            {
                Console.WriteLine("Yield Return Forward: {0}", i.ToString());
            }
            Console.WriteLine();

            foreach( int i in ml.Backward() )
            {
                Console.WriteLine("Yield Return Backward: {0}", i.ToString());
            
            }
            Console.WriteLine();

            Console.ReadLine();

ASP.NET labs

ASP.NET labs can be downloaded here

Extract the files to a convenient folder. Starter and solution files should be in the local folder with the lab.

Setting up the database:

Locate the \set2\labs\Database folder. Run SQL2000SampleDb.msi. Preferably extract the files to this folder. Run AddNorthwindDB.bat. This should attach the DB files in SQL Server. Note: as this suggests, you will need SQL Server Express installed in order to do these labs. This *should* have been installed with Visual Studio (2005/8). If you do not have it installed, it can be downloaded and subsequently installed from here.

\set 2\labs\lab 1- VS2005\Lab1VS2005.html

This lab gets you to create a new website as well as import in an existing set of files. You'll also create a new page for the site. NOTE: the files you'll be asked to import into the site are in the \Labs\set 2\labs\lab 1 - VS2005\files NOT the "c:\labs\lab 1 - vs2005\files" folder ("Add Existing Content" step 2). You'll use this site as the basis for future labs.

Lab 2: \Labs\set 2\labs\lab 2 - csharp\Lab2CSharp.html

In this lab, you will add functionality to a search page to search a data store. You'll add in the page, then add code to the page. Again, when adding in the existing page, it is found in the \Labs\set 2\labs\lab 2 - csharp\files folder, not the one they specify.

Lab 3: \Labs\set 2\labs\lab 3 - classes\Lab3Classes.html

In this lab, you will subclass an existing Data Access Layer class (DAL) to allow access to an alternative part of the data store (you might subclass a more generalized class that has access to Cache data, for example, in the real world). Here you'll be doing it to a class that works with data in SQL Server. Again, when adding existing content, retrieve it from \Labs\set 2\labs\lab 3 - classes\files not the folder they specify.

Lab 4: \Labs\set 2\labs\lab 4 - collections\Lab4Collections.html

In this lab, you will be working with the ArrayList to create a master-detail web page. This lab also touches on topics we will be covering in future lectures, such as Session objects and data binding. As a challenge, after getting the lab to work, see if you can use the generic List class instead of the ArrayList class to implement a storage container for the suppliers. As always, the location to find the content that they wish you to add into your site can be found in \Labs\set 2\labs\lab 4 - collections\files.

Posted at 10:47 AM by Stephen Kennedy | Category: Session 4 | Permalink | Email this Post | Comments (0)

RSS Feed

1 - 10

kennedy