March 2005 - Posts

ASP.NET 2.0 adds a new control that makes it easier to create a wizard like process (i.e.: a multi-step process with forward and backward buttons).  This control will allow you to put controls inside a series of WizardStep controls.  The Wizard control itself will handle the navigation among steps automatically.  The control also supports templates for sidebar navigation throughout the process.
 
This is what a wizard control would look like.
 
<asp:wizard id="WizardControl" HeaderText="My Wizard" runat="server" />
     <wizardsteps>
            <asp:wizardstep title="Step 1" runat="server" />
                <!-- insert controls here -->
            </asp:wizardstep>
            <asp:wizardstep title="Step 2" runat="server" />
                <!-- insert controls here -->
            </asp:wizardstep>
            <asp:wizardstep title="Step 3" runat="server" />
                <!-- insert controls here -->
            </asp:wizardstep>
     </wizardsteps>
</asp:wizard>
 
This might be a useful control in the future.  It has a lot of options and it can be customized in a lot of ways.
 
This is kind of cool new feature they have added to Visual Studio 2005.  How many times have you created a class and you wanted to test a method inside it to see if it works or not?   Well, the Object Test Bench works a lot like the Immediate Window but it allows you to create instances of an object just by right clicking on them.  This can be done from the Class View or from a Class Designer (also a new feature in VS2005).  A series of dialog boxes will appear and allow you to specify instance names and what parameters you want to pass in to the class or methods.  This will be a great tool in testing stand alone classes after they are created.
The Tips of the Day have been slow lately (mainly because we have been running out of content).  However, Beta 2 is not far off which means I am sure we will start seeing more and more content.  According to a blog of the VS2005 release team, we will most likely get Beta 2 in the first week or two of April.  This is a good time.  More info here.
 
I know we are not developing COM components any more obviously, but Visual Studio 2005 leverages a new feature added in Windows XP called Registration Free COM.  This effectively allows you to isolate a legacy COM components to a single .NET application instead of having to register it in the registry using RegSvr32.exe.  This may prove useful in the IMT, where we still use COM components to talk to TRIPS.   In VS2005, every COM components that you reference in your project has a new property called Isolated.  Setting this property to true will allow the components to work without having to register it first on the server. 
 
You have to have the COM component initially registered on your system for it to show up in Visual Studio.  However, once you set the Isolated property and recompile, an appplication manifest file is created.  This manifest file (the same one used by ClickOnce actually) contains the information the application needs to interop with the COM component.  You can now unregister the COM component on your local machine.  You can also XCOPY deploy the application to the server you want and it will run.
 
Note: They added this feature in Windows XP, so I am not sure if it is supported under Windows Server 2003 at this time.
Microsoft is cranking out the information this month and we're even getting some new files.  The Avalon and Indigo Community Technology Preview for March has been released.  This is the first release of Indigo since the PDC.   Again, Avalon is the new UI system for windows forms applications.  Indigo is the next generation of communication that will replace web services.   It does not include a release of Visual Studio, so I think it requires the use of command line compilers and fun stuff like that.   This release is built upon the February CTP version of the framework, so if you want to mess with it you will probably be best using a virtual machine. 
 
If you want to know a bit more about Indigo, take a look at the FAQ here.
 
 
Assembly signing has always been a pain because you had to specify a relative path or a full path to a key file in AssemblyInfo.cs such as:
 
[assembly: AssemblyKeyFile("/Thrifty.Net/Thrifty.snk")]
 
Well it looks like this is going to get a little better.  Now you can specify it in as a project property (and it actually works right).  Just go to the properties of your project and click on the signing tab.  From there, you can specify the path to the key file.  Hopefully, this works better than it did in the past.
MSDN Universal and MSDN Enterprise are being discontinued in lieu of five new MSDN Premium Subscriptions. 
 
Here is basically how this thing works.  There are five editions of Visual Studio aside from the Express and Standard Editions.
 
These editions are:
  • Team Edition for Software Architects
  • Team Edition for Software Developers
  • Team Edition for Testers
  • Professional Edition
  • Team Suite

As a current MSDN Universal / Enterprise subscriber, you will have to choose between the three Team Editions listed above.  Each edition contains different Visual Studio features (http://msdn.microsoft.com/library/en-us/dnvsent/html/vsts-over.asp scroll down about half the way for the image).  Most of you will probably take the Software Developer Edition.  A few of you will have Software Architect.  Software Architect does not necessarily contain all of the features that the Software Developer or Tester edition comes with.  Now, if you want the features of all three editions, then that is where Team Suite comes in.  That one costs extra.  See the link below for the differences in editions.

http://msdn.microsoft.com/howtobuy/vs2005/compare/

Those of you with MSDN Enterprise (C2) will automatically be transitioned to the Software Developer Edition.  If you have MSDN Universal, you will be given a choice of which version you would like to switch to.  You will be able to make that choice in the future here.

http://msdn.microsoft.com/howtobuy/vs2005/request/

I'm sure we will here more about this in the future as Beta 2 and the final release nears.

As I mentioned before, there have been numerous improvements to caching in ASP.NET 2.0.  Along with the use on DataSource controls, there is a new type of cache invalidation that allows you for the cache to be updated any time a change is made to a particular Sql Table.
 
The way this work varies by which version of SQL Server you are running in SQL Server 2000 / 7, the process works by polling the SQL Server at a set interval to see if anything has changed.  The way this works is by setting up a new table using aspnet_regsql.  This program has a number of wizards and command line parameters to set up all the various new features in ASP.NET 2.0 (i.e.: Profile Database, Page Counting, Cache Invalidation, etc).   Basically, how this works is that it sets up a trigger on the table you are monitoring and copies data to another table to indicate that the cache has been invalidated.
 
Here is what your web.config would look like in this scenario:
 
<configuration>
  <connectionStrings>
    <add name="LocationConnectionString"
      connectionString="Server=tweb24\thrifty;Database=Teamowner" />
  </connectionStrings>
       
  <system.web>
    <caching>
      <sqlCacheDependency enabled="true">
      <databases>
      <add
            name="Location"
            connectionStringName="LocationConnectionString"
            pollTime="60000" />
      </databases>
      </sqlCacheDependency>
    </caching>
    </system.web>
</configuration>

In this case, the database specified in the connection string will be polled every 60000 milliseconds.  To use this on a datasource control, you just need to add the SqlCacheDependency parameter and specify which database and table to invalidate on.
 
     <asp:SqlDataSource
            ID="SqlDataSource1"
            EnableCaching="true"
            SqlCacheDependency="teamowner:tblsearchalias"
            SelectCommand="spGetLocations"
            ConnectionString="<%$ ConnectionStrings:LocationConnectionString %>"
            Runat="server" />

What's cool about this is that you don't necessarily have to use with a datasouce.  You can also use this at the page or control level by specifying a compiler directive.
 
<%@ OutputCache SqlDependency="Teamowner:tblsearchalias"
    Duration="6000" VaryByParam="none" %>

In this case the page's output cache will invalidate itself any time the tblsearchalias table is updated in the teamowner database.
 
In SQL Server 2005, polling is not necessary.  Instead, whenever a table is modified it can notify IIS directly that the cache has been invalidated.  This has been a lot.  I'll cover even more on caching tomorrow.
 
Well I tried to post this yesterday and then after I had typed the whole thing, my session has expired.  I went back and of course SharePoint automatically clears any values in the body textbox.  Therefore, I am going to try again.
 
ASP.NET 2.0 adds many caching improvements that are easy to use.  Some of the controls I have already mentioned have this built right in (i.e.: ObjectDataSource and SqlDataSource).  To cache with either of these simply set EnableCaching equal to true and set the CacheDuration to the length you want to cache (in seconds).   A SqlDataSource with caching looks like this.
 
 <asp:SqlDataSource
   ID="SqlDataSource1"
   EnableCaching="true"
   CacheDuration="600"
   ConnectionString="ReservationsConnectionString"
   SelectCommand="GetLocations"
   Runat="server" />

In this case the SqlDataSource will cache the data for 10 minutes.  If you have parameters that might change (i.e.: it is bound to a textbox or something), it will autoamtically store each use of the parameter in the cache.  Instead of covering everything about caching like I tried to do yesterday, tomorrow I will cover Sql Cache Invalidation.
Many times in the past I have been faced with trying to convert a DataView back to a DataTable.  Well in ADO.NET today, that takes quite a bit of work.  If you are wondering why you would ever want to do this.  It is typically easier to perform sorting and filtering and what not with a DataView over a DataTable (although you can do both with a DataTable).  There is also a bit of a performance improvement when using a DataView.  However, once you do your work with a DataView, you may want to convert that back to a DataTable so that you can make use of typed schemas or send it back to a database, etc.
 
To alleviate that issue ADO.NET 2.0 introudces the ToTable method on the DataView object.  Overloaded versions of the ToTable method allow you to specify which columns get written to the new DataTable as well as the table name.  This new method will make this task much easier in the future.
A new version of the Visual Studio Express products are now available for download.  I was hoping for Beta 2 by now, but this will have to do for now.  You can download it at the following link.
 
As you may have heard, SQL Server 2005 can exposed just about anything now via Web Services.  This will often eliminate the need of creating a middle tier object to perform data access for you.  The way it works is by creating an HTTP EndPoint.  I would like to think that they will have something integrated into the IDE to take care of this for you, but so far everything I have seen has required a few T-SQL statements.
 
Here is an example of how an endpoint is created for a stored procedure GetContent.
 
CREATE ENDPOINT ContentWebService
     STATE = STARTED
AS HTTP
(
     PATH = '/Local',
     AUTHENTICATION = (INTEGRATED),
     PORTS = (CLEAR),
     SITE = 'tweb24'
)
FOR SOAP
(
     WEBMETHOD 'GetContent'
         (name = 'teamowner.dbo.GetContent',
          schema = STANDARD)
     WSDL = DEFAULT,
     DATABASE = 'teamowner',
     NAMESPACE = 'http://www.thrifty.com/schemas/local'
)
 
There are quite a bit of parameters here but most of it is straight forwards.  This example creates an endpoint at tweb24/local/ContentWebService (notice there is no asmx extension).  You can get the WSDL by passing ?WSDL to the previous URL.  At that point you can reference the web service in a project like any other.
 
Here is what some of the parameters do.  PATH sets the path that the web service is going to be located at.  The name of the endpoint will be appended to the path.  The PORTS parameter sets which port it will be exposed on (a value of CLEAR indicates port 80).  The WEBMETHOD actually specifies the name of the web method and which stored procedure it will execute (in this case GetContent).   There are a ton of other parameters that can be used with this and I am not sure what all of the do yet.  I imagine I will post more on this in the future.
 
A new method of paging has been added through the use of SqlCommand's new ExecutePageReader method.  This method pages at the SQL Server layer by using a server-side cursor and fetching specific rows.  Normally, cursors, if misused, can adversely affect server performance, but in this case Microsoft has implemented it in an acceptable manner.
 
The ExecutePageReader method also returns a SqlDataReader.  Typically, it is used with three parameters: a CommandBehavior (i.e.: close the connection when you are done), start position, and size of page).  Here is an example of how it works:
 
SqlConnection myConnection = new SqlConnection(connectionString);
 
// open the connection   
myConnection.Open();
 
// create the command
SqlCommand sqlCommand = new SqlCommand("spDoSomething");
// get a paged data reader using the specified startPosition and pageSize
SqlDataReader sqlDataReader = sqlCommand.ExecutePageReader(CommandBehavior.CloseConnection, startPosition, pageSize);
 
Unfortunately, there is a down side.  Behind the scenes, this method makes use of dynamically created T-SQL statements.  Although the manner in which it is implemented prevents against SQL Injection attacks, the DBAs would probably never let us use this as it could be inefficient.  Even though we may never use it, I figured I would still tell you about it so that you would know.
Alright, I am a little late today on the Tip of the Day because I have been absorbed in use cases, but here it is none the less.  Although, asynchronous (I'll misspell that word at least two or three times in this article) calls are nothing new to .NET, they have been added to ADO.NET 2.0.  Asynchronous callbacks in ADO.NET work just like any other asynchronous call.  You start by initializing your connection and SqlCommand just like you would with a normal ADO.NET call.  The difference is that you assign an IAsyncResult using the BeginExecuteReader method (in the case of a SqlDataReader).  You pass as a parameter to that method the name of the method that will catch the response of the asynchronous call.  Lastly, that method will assign a SqlDataReader to the result of the EndExecuteReader method.  After that you use the SqlDataReader just as you normally would.
 
Here is what the code would look like
 
// declare a command at the class wide level
SqlCommand mySqlCommand;
 
// start the async process
protected void StartCommand
{
    SqlConnection myConnection = new SqlConnection(connectionString);
 
    // open the connection  
    myConnection.Open();
 
    // create the command
    sqlCommand = new SqlCommand("spDoSomething");
 
    // get an IAsyncResult and set the return method to EndCommand
    IAsyncResult asynchronousResult = sqlCommand.BeginExecuteReader(EndCommand);
}
 
// catch the completion of the command
protected void EndCommand(IAsyncResult asynchronousResult)
{
    // get a datareader from the result
    SqlDataReader sqlDataReader = sqlCommand.EndExecuteReader(asynchronousResult);
 
    // do something with the data reader
}
 
Of course, you can do this with other types of ADO.NET types (i.e.: SqlDataAdapter, etc.) not just with a SqlDataReader.
The TableAdapter is a new component brought to us by Visual Studio 2005.  This is basically the strongly typed equivalent of a DataAdapter.   When you create a new typed dataset now, the wizard aks if you would like to add any methods.  By default, there are methods available that allow you to fill a DataTable, return a DataTable, as well insert/update/delete directly from a database. 
 
When you opt to create a Fill method for example, it then asks you to specify a query or stored procedure.  You can even create multiple methods to fill by different parameters (i.e.: different id columns).
 
When you create the new dataset, besides the dataset there will be a table adapter class created for each table.  For example, if we have a dataset called DealsDataSet and it has a datatable called Deals, a TableAdapter would be created called DealsTableAdapter.  If we create a Fill method that filled the DataTable by ContentId, a statement to fill the table would look like this:
 
DealsTableAdapter.Fill(contentId);
 
These new DataSet methods should prove to be useful any time we have simple Sql data access requirements as it will allow us to cut out a lot of ADO.NET code.
More Posts Next page »