MCMS and TFS

Microsoft Content Management Server (MCMS) and Team Foundation Server (TFS) in Visual Studio 2005 don't play nice together. Since MCMS is a dead-end product, I don't expect there will be an actual fix.

The KB Article fix (sort of).

Stefan's workaround. Essentially you need to use them separately, TFS with Visual Studio and a standalone version of the MCMS Template Explorer.

Posted: Tuesday, July 08, 2008 12:02:12 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
TFS | MCMS

DataSets and Calculated Columns

Ran into a performance issue in a .Net remoting situation. A Winforms app is calling an application server asking for data. A relatively large DataSet (>10,000 rows, <6 columns) being passed over the wire was causing a performance problem. The database and application servers processed it quickly. Examining the transfer with WireShark showed that the transfer wasn't so bad either. There was a flurry of data passed, and then a bunch of waiting on the client-side, with the client CPU usage around 50% the entire duration of the wait. Turns out there is a calculated column in one of the data tables. The column is not calculated on the application server-side, so as not to pass a bunch of data across the wire that would be unnecessary. The calc happens on the client. That was the source of the slowdown and CPU usage. In the end the solution to the problem was not using the calculated column, we found a different solution to fix the business problem. I suppose you could perform the calculation in the SQL statement that was ultimately filling the DataSet. That might take longer to transfer, but won't slow down the client app.

Posted: Wednesday, June 11, 2008 4:06:26 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
.Net 2.0 | Performance | Tools | Winforms

TFS Custom Work Items - Lessons Learned

  1. Work on a dummy TFS project that you can delete. Delete the project before you deploy for production.
  2. Not all the attributes for Work Item layout are documented.  
  3. A Work Item Type defined in more than one project is sort of shared between the two. The definition can be different, but the name is shared. So anything you want to change or remove in one has to be done in the other. See item 1.
  4. Work items are not easy to delete. It can only be done through the database. See the SQL statements for doing removing work items. I found a GUI tool for this, but ultimately it was executing the SQL statements.
  5. Work Item Type fields are not easy to modify. Essentially you have to delete it and re-add it. The basic steps are:
    1. Remove the field(s) from the Work Item Type XML definition (both field and in the layout)
    2. Re-import the Work Item Type XML so the definition in use no longer contains the field(s)
    3. Delete the fields using the TFS command line tools. This also deletes any data you had stored for existing work items using your custom type.
    4. Re-process the cube using the TFS web service
    5. Update the Work Item XML with the updates you need
    6. Re-import the Work Item Type XML

 

Of course, after-the-fact I found a good overview of the custom Work Item process.

Posted: Friday, June 06, 2008 4:11:48 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
TFS

ASP.NET 2.0 and Global.asax: What not to do

I deployed a site today that has some code in the Global.asax event handlers. I let Visual Studio 2008 add the file to my project when I created it, and it put the code directly in the file inside <script runat="server"> tags. I went with it. So when I deployed the file, none of the events fired. Ever. The lesson is: Don't put your code in the global.asax file. Apparently this problem is by design. There is a vague KB Article on this problem, but the solutions aren't all that helpful, I didn't want to pre-compile, and the first solution made no sense at all. A little searching and I found one good solution: put a class that inherits HttpApplication in the App_Code folder as described here. What I don't understand is why Visual Studio adds the file that way if it isn't going to work on an xcopy deployment. Microsoft seems to go out of their way to protect us from ourselves so often that I am surprised the IDE does something intentionally that won't work.

Posted: Wednesday, February 06, 2008 3:57:21 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
ASP.NET | Visual Studio

Technical Irony

While looking for a URL rewriting tool for a client I found a reference to a tool, clicked the link and got a 404 error.

Posted: Saturday, January 26, 2008 6:02:27 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
Strange Problems

Defining Project Success

There is an article in Dr. Dobbs that describes a survey performed by the author. The survey was intended to query Project Managers, IT Managers, IT staff and business stakeholders on what defined the success of a project.

There were definitely some interesting findings:

  • The IT industry has a long way to go to achieve a 100% success rate for projects
  • Agile projects were more successful than traditional waterfall projects
  • Off-shored projects were most likely to fail
  • Respondents rated quality as the most important issue, and rated the importance of following items this way when analyzed as a group:

    Quality > Scope > Staff Health > Time of Completion > Money
  • Project managers differed significantly from all other groups in their perception of success, rating time and money over quality.
  • Business stakeholders placed a higher value on ROI and and shipping when ready than the rest of the groups
  • A majority of respondents in all groups worked on projects they knew would fail from the start, but canceling a troubled project was not viewed as a successful outcome

I am not surprised by project managers having a different view, given that they are trained to value on-time and on-budget projects. Someone has to keep an eye on the bottom line, but I have experienced this gap when a project runs into trouble. I have been thinking about the differences between Agile and Waterfall-style projects and how they differ. I think there is some middle ground between the two that is yet to be identified that gives us the benefits of heavier requirements and design and the responsiveness to change.

Posted: Tuesday, January 15, 2008 12:11:06 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback

Reporting Services - Page Breaks and PDF Files

In Reporting Services reports, page breaks occur when the size of the body exceeds the page size. The crux of the lesson I learned is that the size of a sub-report cannot exceed the size of the parent containing it. Funny page breaks occur in the PDF output if this is the case.

Brian Welcker posted some terrific details on how page breaks work in Reporting Services, this post is essential if you are creating reports.

Posted: Wednesday, November 07, 2007 4:11:44 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
SSRS

Building a Basic Excel Document with Open XML

I recently gave a talk about Open XML, and found that there were not many complete code samples out there which described how to build Office 2007 documents using .Net and SpreadsheetML. Most of the examples I ran into were snippets or functions, or just examples of the SpreadsheetML. As one of my demos, I created a C# class which builds a basic spreadsheet. This post describes that class.

There are prerequisite installs required to run this code:

  • .Net 3.0 Framework (System.IO.Packaging is part of WPF)
  • SDK for Open XML Formats, which is currently a CTP, so the code is subject to change if the object model changes at all with the final release (so therefore does the code in this post).
  • Code Snippets that are available for Open XML.

The class (called Spreadsheet) does two basic things:

  1. Create a spreadsheet package
  2. Insert data into a worksheet in the newly created package

The first step is creating the package, which consists of XML files for the SpreadsheetML and XML files which manage the relationships between those files. In an Open XML spreadsheet, the minimal spreadsheet package requires three documents containing SpreadsheetML:

  1. A workbook file
  2. A worksheet file
  3. A relationship file

Additionally, SpreadsheetML uses a concept called "Shared Strings". SpreadsheetML dictates storing Shared Strings separately from the worksheet in their own document, so the document stores less data if the document re-uses strings. Strings can also be added to the spreadsheet "in-line" and not used Shared Strings storage. For this example labels are stored as Shared Strings to demonstrate the concept, therefore the spreadsheet package also requires a Shared Strings document.

The SDK for Open XML Formats provides a new component, Microsoft.Office.DocumentFormat.OpenXml.dll, that wraps some of the functionality of creating an Open XML document with System.IO.Packaging. Essentially it manages creating the files and the relationships between the files in the package. Once you have created the files and relationships, you still need to create code to insert actual data into the documents. This example uses two steps:

  1. Create the basic XML document using a template of existing XML
  2. Insert data into the existing XML.

The following are the contents of three small XML files created and added to a Templates directory in the solution. These three files are the basis for the required parts of the package:

The workbook template

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">

    <sheets>

        <sheet name="{1}" sheetId="1" r:id="{0}" />

    </sheets>

</workbook>

Notice that the XML contains .Net placeholders. Later on we can replace these with actual values that can vary at run time.

The worksheet template

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" >

    <sheetData/>

</worksheet>

The shared strings template

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<sst xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">

</sst>

These XML templates make up the basic content of the package. The C# class contains a CreateSpreadSheet procedure which will create the basic pieces of the package. The main thing to notice is that  by creating the part object (workbook, shared strings, worksheet), you are only creating the part file, not the content of that part file. The templates above become the content for the parts. There is no need to manage the relationship files directly, the API is doing that automatically.

public void CreateSpreadsheet(string path, string firstSheetName)

{

    using (SpreadsheetDocument doc = SpreadsheetDocument.Create(path, SpreadsheetDocumentType.Workbook))

    {

        //Add the workbook

        WorkbookPart workbook = doc.AddWorkbookPart();

 

        //Create the shared strings part

        SharedStringTablePart stringTable = workbook.AddNewPart<SharedStringTablePart>();

        this.AddPartXml(stringTable, this.ReadXML(@"Templates\SharedStringTemplate.xml"));

 

        //Create a worksheet

        WorksheetPart sheet = workbook.AddNewPart<WorksheetPart>();

 

        //Get the relationship id so the workbook and worksheet can be related

        string sheetId = workbook.GetIdOfPart(sheet);

 

        this.AddPartXml(workbook, this.WorkbookXml(sheetId, firstSheetName));

        this.AddPartXml(sheet, this.ReadXML(@"Templates\WorkSheetTemplate.xml"));

 

        doc.Close();

    }

}

The only interesting part is retrieving the ID of the worksheet part when building the workbook part. To create the content of each part the procedure opens an XML file and streams the content into the file. There are helper functions for this, which are really just standard ways of handling XML in .Net:

protected void AddPartXml(OpenXmlPart part, string xml)

{

    using (Stream stream = part.GetStream())

    {

        byte[] buffer = (new UTF8Encoding()).GetBytes(xml);

        stream.Write(buffer, 0, buffer.Length);

    }

}

 

protected string ReadXML(string fileName)

{

    StreamReader reader = new StreamReader(Environment.CurrentDirectory + @"\" + fileName);

    string contents = reader.ReadToEnd();

 

    return contents;

}

 

protected string WorkbookXml(string sheetId, string sheetName)

{

    string contents = this.ReadXML(@"Templates\WorkbookTemplate.xml");

 

    return string.Format(contents, sheetId, sheetName);

}

Notice the WorkbookXml procedure has a call to string.Format to replace some placeholders with actual data: the ID of the worksheet part relationship and the name of the worksheet. The name of the worksheet is important later, when we want to add data to the worksheet.

The second step is to actually add data to the worksheet. The class uses two functions available as Code Snippets (XLInsertStringIntoCell, and XLInsertNumberIntoCell). I won't reproduce the code here as I don't own it, but essentially the functions open the proper parts and insert the data. These functions take in the file, the sheet name, cell reference and cell value as parameters.

Lastly, I wrote a console app to exercise the Spreadsheet class:

class Program

{

    protected static readonly string fileName = "example.xlsx";

    protected static readonly string firstSheetName = "Sheet1";

 

    static void Main(string[] args)

    {

        string path = Environment.CurrentDirectory + @"\" + fileName;

 

        Spreadsheet file = new Spreadsheet();

 

        file.CreateSpreadsheet(path, firstSheetName);

 

        file.XLInsertStringIntoCell(fileName, firstSheetName, "A1", "Category");

        file.XLInsertStringIntoCell(fileName, firstSheetName, "B1", "Value");

        file.XLInsertStringIntoCell(fileName, firstSheetName, "A2", "Red");

        file.XLInsertNumberIntoCell(fileName, firstSheetName, "B2", 30);

        file.XLInsertStringIntoCell(fileName, firstSheetName, "A3", "Blue");

        file.XLInsertNumberIntoCell(fileName, firstSheetName, "B3", 60);

        file.XLInsertStringIntoCell(fileName, firstSheetName, "A4", "Green");

        file.XLInsertNumberIntoCell(fileName, firstSheetName, "B4", 10);

 

        Console.WriteLine("Workbook created at " + path);

 

        Console.ReadKey();

    }

}

Before the comments start to fly, I want to point out a couple things:

  • This bit of code is not that efficient, I realize it opens and closes the package a bunch of times. This is really just to demonstrate what is possible and not what is necessarily the best practice. There are very few code samples available, and I am shooting for simplicity here.
  • I know ExcelPackage is on CodePlex and does a better job of wrapping the APIs involved and is much easier to write code with. Once you have a basic understanding of these APIs you will appreciate for the work being done on that project.

Download the VS 2005 project. Don't forget to install all the prerequisites listed above before trying the project. I didn't include the two functions necessary from the Code Snippets in the project either (since I didn't write that code), you will have to put those in yourself.

Posted: Tuesday, November 06, 2007 6:40:30 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
.Net 3.0 | Office | Speaking