MSDN Blogs - SharePoint, XBOX, .NET, Technology

10/11/2007 Call for Papers: Microsoft Visual Studio Team System Konferenz 2008

Am 22.04 - 24.04.08 findet in München die erste Microsoft Visual Studio Team System Konferenz statt. Die Konferenz rund um das Thema Team System beschäftigt sich neben der Technik auch noch um Praxisberichte und -erfahrungen. Wenn Sie etwas zu dem Thema zu sagen haben, der Call for Papers ist bis zum 15.12.07 offen. Hier der Auszug der Konferenzwebseite. Der Call for Papers läuft noch bis zum 15. Dezember 2007 . Die ersten Vorträge werden ab Anfang Januar auf dieser Webseite veröffentlicht. Themengebiete,...(read more)

10/11/2007 CS: properly educated for the 21st century

Alfred Thompson has these quotes in his blog entry What Guidance Needs to Know About Computer Science:

Today"s college graduates simply can"t call themselves properly educated for the 21st century if they don"t have appropriate fluency in computing and information technology. (Dan Reed, Director of the Renaissance Computing Institute)

Computing and information "is the liberal arts education of the 21st century - the skill that can be universally applied across domains to help solve the toughest scientific, economic and social problems.

The blog entry refers to a recent post on the CSTA blog, titled "What School Counselors Need to Know About CS"

10/11/2007 Performance Improvements in 2008 releases

Somasegar"s WebLog has a entry on VC++ Performance Improvements in VS 2008.

A couple of days ago he blogged about the performance improvements in Visual Studio 2008 and on Code Analysis Features in VS 2008

10/11/2007 What Guidance Needs to Know About Computer Science

When ever computer science teachers get together and talk about what makes their life difficult school guidance counselors come into the discussion. Listen in and you will hear stories of guidance "dumping" unqualified students into CS classes to fill elective needs, counselors advising students to avoid CS because "there are not jobs there" or because "colleges want to see more foreign languages on the transcript", and other tails of counselors who just don"t appreciate computer science education.

This came up in the CSTA blog recently with a post titled "What School Counselors Need to Know About CS" I"ll tell you that blog has been on a roll lately and this post contributed by Dr. Debra Richardson, Dean of the Donald Bren School of Information and Computer Sciences at the University of California at Irvine packs a punch.

Two paragraphs in particular are worth repeating (emphasis mine):

I"m going to repeat a somewhat controversial quote, but it"s something that is echoing the halls of higher education today: Computing and information "is the liberal arts education of the 21st century - the skill that can be universally applied across domains to help solve the toughest scientific, economic and social problems. Nurturing and energizing the next generation of liberal arts specialists will bring about new dreams and new discoveries."
It was Dan Reed, Director of the Renaissance Computing Institute who I first heard say this, and it"s just so true. Today"s college graduates simply can"t call themselves properly educated for the 21st century if they don"t have appropriate fluency in computing and information technology.

There you have it. In the future, and I think that future is coming fast, students who are not fluent in computing and information will not be seen as properly educated. Not quite "reading, [w]riting and [p]rogramming" but close. Insert the broad "computational thinking" as an extension of math that includes programming concepts (can you search a database without Boolean expressions? Not really.) and I think you get the picture. There are far sighted people who are starting to say out loud that computer science (not applications usage either) should be a required course.

The guidance department needs to understand that computer science will soon no longer be optional and if they really want to prepare students for the future they should work with computer science educators and not against them.

10/11/2007 The Repository Factory - Try It, Use It, Contribute!

This news isn"t exactly hot of the presses, but it probably flew under the radar for many of you so I thought it was worth a blog post. The first official release of the Repository Factory is now available to download from CodePlex. Not sure what this is or why you might care? Read on...

Some history

The Repository Factory isn"t actually a brand new release; it"s an update to the Data Access Guidance Package which was a component of the first two releases of the Web Service Software Factory. The purpose of Data Access Guidance Package, and now the Repository Factory, is to automate many of the common development tasks required when building data access layers in ADO.NET. Specifically, it contains recipes that automate the following:

Generating business entity classes using metadata from database schema definitions
Generating stored procedures for common CRUD operations, from database schema definitions
Generating data access classes, using the Repository pattern, to retrieve and persist business entities from the database.

While the Repository Factory plays a similar role to Object-Relational Mapping solutions such as NHibernate, the philosophy behind it is quite different. Rather than attempting to abstract away the mechanics of the data access layer, the Repository Factory aims to generate data access layer code that looks the same as what you would write by hand. Also, there is absolutely no expectation that the factory is able to generate all of the code you need. While the generated code is a great accelerator, it won"t include a number of important things such as converting object hierarchies to and from related tables, so you"ll almost certainly need to extend the generated code by hand.

As for why the team chose to spin off this solution from the Web Service Software Factory into its own deliverable, that"s a bit of a long story. Right from the start of the WSSF project there were discussions on whether we should focus purely on the service interface layer, or whether we should take a more holistic approach and consider all of the functionality typically included in service-oriented applications. I successfully argued for the latter, but now that I"ve left it looks like the pendulum has swung back around :-). Actually there is another good reason why they made this decision, which is that the team plans to focus their efforts around data access guidance on LINQ and ADO.NET Entities, and didn"t feel that they had enough bandwidth to continue to evolve their ADO.NET guidance. So by spinning the Repository Factory out to CodePlex, the community is now able to move it forward on their own.

What"s new?

I wasn"t involved in the development of Repository Factory since it was spun off, so I"m just going by what I"ve found while playing with the new release and what I"ve seen on the CodePlex site. From what I"ve seen, the changes from the original DAGP are small but very worthwhile. The organisation and implementation of the generated code has been cleaned up, for example the generated repositories all implement interfaces to allow for multiple implementations (eg for unit testing purposes).

There have also been a number of changes to the recipes and wizards. For example, UI in the wizards for generating repository classes have been reworked to have more pages with fewer controls. These changes are all nice, however there are two other changes in the wizard for generating repository classes that are enough on their own to justify an upgrade:

Any business entity properties which have the same name and type as stored procedure parameters are mapped automatically, eliminating about 73 clicks and the onset of RSI
The wizard will remember the operations and mappings you generated previously, making it possible to re-run the wizard to create new operations or modify existing ones.

My thoughts

I"m really glad to see this project move ahead, and want to thank Chris Tavares and the team for their great work on the new release. While I love the new features, there are a few rough spots:

On my box, the MSI for installing the guidance package returned an error and refused to complete. Also the manual registration required quite a few awkward steps. I know that guidance package installation is often painful and it may be an issue with GAX or my machine, rather than with the Repository Factory. Still I know everybody finds these kinds of usability problems very frustrating.
Some of the new wizard UIs are still a bit rough around the edges
The documentation links all point to WSSF pages rather than Repository Factory pages
It would have been nice to see some more functional improvements such as support for object hierarchies or more control over concurrency models. Still I know these problems are hard to solve, so there is an argument for keeping the solution simpler rather than doing a complex task badly.

That said, I know this release was essentially community-driven with very few resources. Which brings me to my next topic:

Get involved!

I"m very excited to see the growth of community-driven projects for the .NET platform. While the patterns & practices team does fulfil a similar role that is often played by OSS projects on other platforms, I think people are beginning to understand that p&p is a complement to, rather than a replacement for community-driven OSS projects. The Repository Factory is a very interesting example, since it was started by p&p but has now been handed over to the community for further evolution.

I"m sure everyone would love to see initiatives like this succeed, but of course it doesn"t happen unless people sign up to get involved in the project - whether as a coordinator, developer, tester or doc writer. If you think you"ve got what it takes, the team would love to hear from you.

10/8/2007 Wanna take a look at the collation bug Kim pointed out? You"re in for a hell of a Tripp!

Over on the side is that list of blogs I read, in various categories, one of them is Kimberly L. Tripp"s, who I once had like an hour-long conversation with, incredibly impressed by her for what she was saying before being even more impressed after realizing who she is and connecting her to all the stuff she has said in the past.

I think the last time I linked to her was back in May 2006 (Avoiding SQL Server collation woes in the TempDB), but it was a great tip since I was doing it the hard[er] way when I really didn"t need to....

The fact is, she is a hell of a Tripp. :-)

Late last week when she posted The perils of case-insensitive data (and our life in tangent-land) I was captivated once again by the words.

Not for the two problems the post was nominally posing solutions for (both of which had good solutions suggested) but one of the tangents, quoted in part here:

-- First, I"ll create a test database. Without a collation specified,
-- it will use the server"s default collation.

CREATE DATABASE TestAdventureWorks
go

-- Verify the database collation
SELECT DATABASEPROPERTYEX("TestAdventureWorks", "Collation")
go

-- database is set to SQL_Latin1_General_CP1_CI_AS as expected
-- this is a case-insensitive database

USE TestAdventureWorks
go

SELECT LastName collate database_default AS LastName
, FirstName collate database_default AS FirstName
, MiddleName collate database_default AS MiddleName
INTO MyTestContacts
FROM Adventureworks.Person.Contact
go

SELECT *
FROM MyTestContacts
WHERE Lastname = N"Adams"
go -- (86 row(s) affected)

SELECT *
FROM MyTestContacts
WHERE Lastname = N"adams"
go -- (86 row(s) affected)

SELECT *
FROM MyTestContacts
WHERE Lastname COLLATE Latin1_General_CS_AS_KS_WS = N"Adams"
go -- (86 row(s) affected)

SELECT *
FROM MyTestContacts
WHERE Lastname COLLATE Latin1_General_CS_AS_KS_WS = N"adams"
go -- (0 row(s) affected)

-- Next, create a view:
CREATE VIEW ContactLastNameCaseSensitive
AS
SELECT LastName COLLATE Latin1_General_CS_AS_KS_WS AS CSName
FROM MyTestContacts
go

SELECT *
FROM ContactLastNameCaseSensitive
WHERE CSName = N"Adams"
go -- (86 row(s) affected)

SELECT *
FROM ContactLastNameCaseSensitive
WHERE CSName = N"adams"
go -- (0 row(s) affected)

And, everything works... in TestAdventureworks. In the *real* AdventureWorks, I get an error when I try to create the view:
Msg 2791, Level 16, State 5, Procedure ContactLastNameCaseSensitive, Line 3
Could not resolve expression for schemabound object or constraint.

So, this is the first issue. It seems as though you can"t create the view if your database has a different collation than the server collation. Well, (again), I haven"t spent all that much time on this one but I did repro what the chain on the forum seemed to have found.

This does indeed seem like a bug, but one that is easy to imagine in a world where collations that will return identical results (e.g. Unicode data in LATIN1_GENERAL_CI_AS and GREEK_CI_AS) yet they will be considered incompatible for the purposes of trying to compare columns using each of them.

Those errors all tend to fall under the "Columns in this expression have incompatible collations" or "The collation properties of columns <Columnname> and <Columnname> do not match" type of categories, which if trapped during the view creation process I can easily imagine being re-thrown under the more generic "Could not resolve expression" category.

Which does not mean it wouldn"t still be a bug, it is just easy to see how (given the generic (documented) limitation where an indexed view definition cannot contain the collation clause, it is easy to imagine running into this kind of problem in view creation any time the collations do not match, even when they are complete subsets of on another and should be able to do better, as I pointed out in A&P of Sort Keys, part 8 (aka You can often think of ignoring weights as a form of ignorance) only worse since it leads to not just a performance problem but a bug.

It is hard to say which looks worse:

Collations that are literally identical (Unicode data, LATIN1_GENERAL_CI_AS vs. GREEK_CI_AS) being incompatible under any circumstances, or
Collations that are literal subsets (LATIN1_GENERAL_CI_AS vs. LATIN1_GENERAL_CS_AS) being incompatible under any circumstances.

The former is clearly stupider from the standpoint of a Windows collation purist who views the arbitrary separation of these identical collations as a flaw in the SQL Server collation design, sure.

(That would be me, Mondays, Wednesdays, and Fridays!)

But the latter is much more likely to come up in real world customer situations, as it did here for Kim.

(That would be me Tuesdays, Thursdays, and Saturdays!)

I"m going to ask some people over on the SQL Server side about this issue, in any case -- it is certainly not a documented limitation if there is no way to address it, but whether it can be fixed o not I"d at least like to make sure it is tracked somehow....

This post brought to you by ⓚ (U+24da, a.k.a. CIRCLED LATIN SMALL LETTER K)

10/8/2007 Path Finding Using A* in C# 3.0, Part Three

In order to make the A* algorithm work we need to get the lowest-estimated-cost-path-discovered-so-far out of the list of paths under consideration. The standard data structure for doing so is called a “priority queue”. Priority queues are so-called because they are typically used to store a list of jobs where each job has an associated priority.

Now, there’s a bit of a semantic problem with priority queues in that we typically think of “priority 1” as being higher priority than “priority 2”, even though 1 is a smaller number than 2. Fortunately for us, that is exactly what we want in this case; the “highest priority” path is the one with the least estimated cost.

There are lots of ways to implement priority queues – I have a nice example of an immutable priority queue that I’ll probably blog about at some point, but for now, let’s go with an old-fashioned mutable priority queue.

A priority queue can be implemented as list of sub-queues with the list sorted in priority order. The implementation is pretty straightforward:

class PriorityQueue<P, V>
{
    private SortedDictionary<P, Queue<V>> list = new SortedDictionary<P, Queue<V>>();
    public void Enqueue(P priority, V value)
    {
        Queue<V> q;
        if (!list.TryGetValue(priority, out q))
        {
            q = new Queue<V>();
            list.Add(priority, q);
        }
        q.Enqueue(value);
    }
    public V Dequeue()
    {
        // will throw if there isn’t any first element!
        var pair = list.First();
        var v = pair.Value.Dequeue();
        if (pair.Value.Count == 0) // nothing left of the top priority.
            list.Remove(pair.Key);
        return v;
    }
    public bool IsEmpty
    {
        get { return !list.Any(); }
    }
}

We could implement IEnumerable<V>, a Peek operation, etc, but this is all we need for A*, so let’s not go crazy here.

Next time: now we have all the parts we need to implement A*, so let"s do it already.

10/8/2007 Free Workshops - Integrating Workflow into your .NET Applications workshop has been moved!

I"ve recently had to change the workshop series on Integrating Workflow into your .NET Applications for .NET 3.0 download location. They are still freely downloadable.

Part 1 - Introduction to building workflow"s with Microsoft Windows Workflow Foundation (.NET 3.0)

Blog Post and NEW Code Download Location: Click here

Part 2 - How to build custom Workflow Activities with Microsoft Windows Workflow Foundation (.NET 3.0)

Blog Post and NEW Download Location: Click here

~ Robert Shelton

10/8/2007 The roadꂸ to the solution starts with identifying the actual problem.NET

JJ"s question was simple enough:

Hello,

This is probably not the right alias for this, but...

I have a Globalization bug involving “Chinese Minority Characters Yi”. The root cause boils down to the fact that the String.EndsWith method is ignoring these characters at the end of the string. For example, "http://localhost:54031/ꂸꐯꉘ".EndsWith("/") returns true. As an alternative measure, I can use the indexer on the string to get the last character just fine, but EndsWith consistently fails. The machine in question is a JPN machine running Vista Ultimate.

Is there a good reason for this, or is this potentially a .Net bug? If so, where could I send the bug? This is blocking our exit criteria.

I am using String.EndsWith(String) exactly as shown in the e-mail (the lone argument is “/”). This consistently reproduces with any of the characters found in the bug:

ꌒꆏꉘꃅꌒꉘꃅꌒꂸꐯꉘꃅꎵꑳꀕꉘꃅꑌꐥꌒꌒꆏꅔꐎꌒꅔꐎꌒꂸꐯꅔꐎꁤꇅꀕꅔꐎꏰꐥꌒ

Let me know if you need anything else.

The answer to this one might feel like review to regular readers. :-)

The problem is really twofold here --

One, the problems implicit in that most cited post, The jury will give this string no weight. And Yi definitely falls in that category....

The other problem is the fact that we are looking at a URL, which like a system file path is one of the most non-linguistic things one can really have if one is having a string.

It falls in with The nature of OrdinalIgnoreCase vs. intuitive expectations, and suggests that the overload to be using here is String.EndsWith(String, StringComparison), specifying StringComparison.OrdinalIgnoreCase (or potentially StringComparison.Ordinal if one is running on a platform that is not case insensitive, which could be true of many a web server).

The problem is a common one, and there are more misuses like this one then almost any other problem I run across.

Now It may be convenient to blame the developers who write the incorrect code (and many people do), but really too convenient -- the framework points them in this direction by simply using methods intuitively.

It may also convenient to blame the default overload (and several others do, after all the problem wouldn"t happen with a different overload!) but once again too convenient -- because all this would do is shift the problem to the other cases when one actually needs linguistic comparisons.

It is easy to blame FxCop (and I do, a little bit) for it"s contributions in this space, but in reality it is just slow to helping people get the right methods; with a nudge here and a prod there, they will improve, in time.

But the underlying problem will still exist.

The real problem is in the fact that the whole framework, really the whole programming model, does not lead developers to use the correct method.

Remember the frustrations of Scott Hanselman when dasBlog had a Turkic I bug and that original jury / no weight post suffered from a .Text bug when I first tried to post about it -- smart developers everywhere are hitting these problems, and it is a frustrating truth that no matter how good FxCop becomes at helping here in future versions that it is little more than King Canute trying to sweep back the tide.

Because smart developers are going to keep writing the wrong code.

And let"s be honest for a moment -- if that is what the smart ones do then you know what happens with the not-so-smart ones....

What is needed is a whole new paradigm, a whole new way of looking at the problem.

It is not that FxCop sucks, to the extent that it does that can be blamed on the areas the .NET Framework itself sucks in. And those areas have their suckage built in, because they needed to be looking at the problem differently.

I have talked to and bounced ideas off of a bunch of really smart people about this (I"ll get into my criteria for calling someone a "smart" person in this context in another post), and I think I am approaching if not a solution then something much closer to it.

Since my full scope of influence is really limited in large part to the blog these days, I"ll post about it here and see if anyone is interested, rather than trying to sweep the problem under the rug (the current solution)....

This post brought to you by ꂸ (U+a0b8, a.k.a. YI SYLLABLE MAP)

10/8/2007 Improve Scalability With New Thread Pool APIs

Windows Vista and the upcoming Windows Server 2008 include a new thread pool API that should make it much easier for developers to employ the thread pool effectively.

In the October issue of MSDN Magazine, Robert Saccone shows you how the new thread pool component addresses a number of limitations of the legacy thread pool. For example, the new thread pool lets you create multiple thread pools per process, while the old model allowed only one.

To get you started, Robert included two sample applications in the download for this article. The first, ThreadPoolDemo, lets you experiment with work, wait, and timer objects so you can explore how they work.

The second sample application, CopyFile, is an update of the Windows SDK file-copying example that demonstrates how a completion port works.

Enjoy!

Terrence Dorsey