John Luif

via Rocky Lhotka blog.

“To switch a web site to run under IIS in VS 2005, do the following:

1. Add a virtual root to IIS using the IIS admin tool. Point the virtual root at your project directory; such as PTWeb. This is your existing project directory - you don't need to copy the files to wwwroot or anything. But you do need to make sure ASP.NET/IIS has directory security to your project directory.
2. Make sure that the virtual root is set to use .NET 2.0. This is done in the virtual root's properties dialog in the IIS admin tool.
3. Back in VS 2005, open the web site's properties dialog and change its startup option to use a Custom Server. The URL will be something like http://localhost/PTWeb

At this point you should be able to work with and use the web site like normal - including pressing F5 to debug, or right-clicking and choosing View in Browser to run outside the debugger.”

After any of you use the personal web server this will be one of the first things you will do.

This is not fun trying to figure out what Reporting Services is trying to do when it auto populates a Dataset for a report.  Here is what I found.  When you refresh a the Datasets it will make a call to your web service with no params thus an empty or null object is created as the return value.

So say I have a class with two properties: Name, Address.  These two properties are initialized to an empty string and the other to a null.  They will not show up in the Dataset unless you explicitly define them in your query.  Why?? Well it is because the Dataset population looks to ignore null value properties so if you want them they need to be initialized to something other than null or empty string.  This also is an issue if you are using nullable types.  Basically if you are using a basic class (have not dug too deep with datasets but this may hold true for them as well) on the other end of your XML Datasource you have two choices.

1) Initialize all members that are exposed as properties to something other than null or empty string.

2) Explicitly define the columns in your Query like below.

<Query xmlns:es="http://test.test.com" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <ElementPath>es:RetrieveInvoiceResponse{}/es:InvoiceInfo{Name}</ElementPath>
</Query>

I personally will be using option two because all the entities that are used by the web service are generated.  I hope this gets fixed sometime soon because this seems like a stupid limitation.

Today I ventured into the world of XML datasources in reporting services.  First off creating the XML datasource is easy but creating the Dataset from a query is another story.  Russle Christopher’s post provides a good starting point but there are some things that are not explained in his post.  The part I needed to know is how the Query and ElementPath work.  The xmlns in the Query works just how you would expect.  Define you namespaces and you can alias them so you can use them in ElementPaths.  The below is an example:

<Query xmlns:es="http://test.test.com”>
     <ElementPath>es:RetrieveInvoiceResponse{}/es:InvoiceInfo</ElementPath>
    <SoapAction>http://test.test.com/RetrieveInvoice</SoapAction>
</Query>

 In Russle’s post he talks about datasets (in the .NET sense), in my case I’m just serializing simple objects thus no diffgram or NewDataSet. 

Suppose you have xml for your datasource like the below as your datasource (NOTE:  I created a datasource directly off an xml doc).

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <RetrieveInvoiceResponse xmlns="http://test.test.com">
      <InvoiceInfo>
        <OrgId>2</OrgId>
        <Name>John</Name>
      </InvoiceInfo>
    </RetrieveInvoiceResponse>
  </soap:Body>
</soap:Envelope>

 Your Query and ElementPath would look like:

<Query xmlns:es="http://test.test.com" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <ElementPath>soap:Envelope {}/soap:Body{}/es:RetrieveInvoiceResponse{}/es:InvoiceInfo</ElementPath>
</Query>

Notice how the namespace aliases are used in the element path.  Another important piece to note is the “{}” in the ElementPath.  This is for defining columns to include.  If the “{}” are left off all columns are returned.  So the above query would return the columns “OrgId” and “Name”, but if I did this:

<Query xmlns:es="http://test.test.com" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <ElementPath>soap:Envelope {}/soap:Body{}/es:RetrieveInvoiceResponse{}/es:InvoiceInfo{Name}</ElementPath>
</Query>

Only the “Name” of InvoiceInfo would be returned.

I still have one thing I’m struggling with; if I leave off the “{}” because I want all columns returned my report dataset does not populate the columns (in the Datasets explorer) so I have to define each column right now for them to show up in my dataset.  Hopefully I can find a solution to this.

Web Service Studio 2.0 may not be the best tool of its breed out there but I found it useful for looking at soap messages.

If anyone is interested in learning more about CAB then come join me at the front range code camp on May 20th where I will be talking about it.

see you there!

Just bought a new car this past weekend and I ended up using H.M. Brown to purchase it.  I will never go back to buying a car at a dealership.  I was in and out in 30 minutes and got the car at invoice less $1000.

If you are in the Denver area and looking to get a new car give Dave Nolt a call at H.M. Brown.

Tomorrow I’m off to Fruita and Moab for some early season training.  It is time to get away from work and just let my mind wonder; of course that is usually when stuff like this happens.

Measuring productivity has been something companies have been trying to do for some time.  Believe it or not some companies out there still use lines of code to measure productivity.  I would not mind working for one of those companies as long as I could bring Code Smith along with me  I work in an agile environment where we work with stories.  The approach I take to measure how productive a team is how many stories are accepted by the customer.  Just to clarify my use of the word “accepted” it means that a story is implemented by a developer and is said to be done by the customer.  The point I’m trying to make is the process start with the customer and ends with the customer.