怎样给控件加提示？

如果你想给一个控件加入控件提示，首先，检查是否允许引用ToolTipService命名空间，如果可以，你可以用以下的方式添加控件提示：

Xaml

<Button x:Name="MyButton" Content="Hello!" Width="50" Height="30">

   <ToolTipService.ToolTip>

       <TextBlock x:Name="ToolTip" Text="Click me!"></TextBlock>

   </ToolTipService.ToolTip>

</Button>

C#

ToolTipService.SetToolTip( MyButton, new TextBlock() { Text = "Click me!" } );

你也可以用其它的控件替换TextBlock，比如图片控件或者方形控件。

Visual Studio unit testing intro

Visual Studio’s unit testing framework isn’t widely covered in books or in other places, and this makes it tougher for teams to adopt strict test guidelines for their developers. At the end of the day, if you aren’t unit testing from day one of your project, you’re in for a world of hurt down the line.

If you’ve new to Visual Studio unit testing, or just wanting to learn about Silverlight unit testing, you may feel a little lost. Here’s some information that just scratches the surface of the Visual Studio unit testing world.

So here are some of the questions people may have, let me know if there are others that you have! If you’re already familiar with unit testing this will all be redundant.

What makes up a unit test project?

Most unit tests are simple class libraries written in your language of choice. They reference your production application’s projects or built assemblies, and also the unit test framework.

Metadata decorates the tests, and the tests themselves typically include calls to the test framework’s assertion classes.

Where do I go to get started?

Must-read resources:

• MSDN: Unit Testing Framework (One page that covers just about all the metadata)
• MSDN: Using the Assert Classes
• MSDN: The most common Assert methods
• MSDN: Structure of Unit Tests
• Stephen Walther does a very detailed walkthrough of unit testing, with an emphasis on testing ASP.NET MVC code

Patterns and examples:

• The Composite WPF guidance by Microsoft’s Patterns & Practices includes tests
• TypeMock has a useful, general article about unit testing patterns. Note that their examples aren’t using the Visual Studio metadata, but instead nUnit’s… but it’s pretty much the same.

Videos:

• Eric Lee has an 11 minute screencast walkthrough of unit testing basics inside Visual Studio

For testing desktop applications, class libraries, and other code built for the full .NET framework, you’re in for a treat: Visual Studio 2008 Professional and other SKUs put great built in unit test support right inside your development environment. You’ll always be a click away from running a test or seeing where you stand.

What’s a unit test?

• Simple.
• Quick to run.
• Independent and self-contained: Should not rely on any previous test results or any particular execution order.
• Doesn’t cross any unit test boundaries (as defined by Phil Haack)
• Easy to maintain over time. Documented. Not archaic.
• Lacking variability: a valid unit test should always consistently pass.
• Positive or negative: They can validate exceptions and error conditions as well as expected results and states.

What isn’t a unit test?

• A test that validates integration (your database and your class library).
• A test that interacts with UI, network resources, or the file system.
• Something that takes a long while to run.
• An end-to-end test of a user scenario.
• A performance, stress, load test, security, or other advanced test.
• Complex.

What other kinds of tests are written?

There are integration tests, end-to-end tests, performance and stress tests, and many, many more. But at Microsoft I like to think of tests in 3 sets. In some cases it is possible for all the tests in a product to build upon a ‘unit test framework’.

Unit: “True” unit tests. Quick, small, efficient, very useful to always run. Independent.

Developer: Unit tests plus tests that exercise simple scenarios and conditions, such as the control framework in WPF, or performing a super simple request. Often these reach outside of the typical “unit test boundaries,” but are still quick to run and useful.

Developers are typically required to run all of the developer tests on their machine when preparing a check-in to validate the state of the code.

All tests: The set of all developer tests and everything that the test development team has created. Sometimes reaches into the tens of thousands of scenarios and cases at the end of a product cycle once a matrix of platforms and configurations is taken into consideration.

Developers and testers work together to make sure that all tests are run regularly, and especially when working on approaching a major product milestone, release, or servicing activity.

Why would you use a unit test framework to create more than unit tests?

• Consistency.
• Can usually run many integration and scenario tests in the same test runs.
• Run integration tests on many platforms in an automated fashion using test controllers and harnesses.
• The definition of a unit test is pretty academic. At the end of the day, I want to get my job done efficiently and without needing to continually learn new systems. So doing more than true “unit testing” is cool with me.
• Allow your developers and test developers to share experience, test cases, and help each other succeed.

Why does the Silverlight unit testing framework have tests that look just like the full desktop framework’s? Are they the same?

When building out the Silverlight unit test system that runs tests inside of your web browser, we made the call to reuse Visual Studio’s unit test framework metadata. This is a great win, for a few reasons:

• Reuse of existing tests: many simple API tests can be run as they are.
• Many .NET developers already know Visual Studio’s unit test framework, or nUnit. No need to waste time learning the basics of another system.
• If you’re new to Microsoft’s unit testing framework in general and starting with Silverlight, you’ll walk away with the information you need to start unit testing in Visual Studio as well.
• Why re-invent the wheel?

I like the Silverlight test framework, but how can I make sure that my tests can be ported to a desktop Windows Forms, class library, or WPF project?

Make sure that your unit tests are actually small, independent, simple, and not dependent on the web browser, Silverlight itself, or the more advanced “beyond unit testing” capabilities that are also present in Microsoft.Silverlight.Testing. If you inherit from the “SilverlightTest” base class, you probably have a test that won’t port to the desktop .NET framework.

We’ve worked hard to provide a subset of the full Visual Studio unit test metadata, but here’s a quick guide for you:

OK to use in both worlds:

• All the metadata attributes including TestClass, TestMethod, ClassInitialize, ClassCleanup, TestInitialize, TestCleanup, AssemblyInitialize, AssemblyCleanup, Ignore.
• StringAssert, Assert, CollectionAssert static types.

Desktop features that will not work with the Silverlight test framework today (or are no-ops):

• Data-driven tests
• TestContext
• File-based assertions and accessing the file system
• Using WorkItem or TestProperty attributes
• Web/ASP.NET test functionality.
• DeploymentItem.

Silverlight test features that will not port to the desktop:

• Using Silverlight or web browser features.
• Inheriting from the SilverlightTest base class.
• Using any of the Silverlight “TestSurface” or TestPanel features exposed by the SilverlightTest base class.
• Using the “Asynchronous” features in the framework, including the Enqueue and test work item / test task features.
• Using any of the attributes defined in the Microsoft.Silverlight.Testing namespace, such as AsynchronousAttribute, BugAttribute, and ExclusiveAttribute.
• Writing your own UnitTestProvider, your own Harness, or your own UnitTestHarness
• Writing your own test tasks and work items.

Hope this helps get some of you started!

XML building blocks

What are some good XML specifications to get acquainted with? Here are the ones I find myself referring people to the most.

• Extensible Markup Language (XML) 1.0 (Fourth Edition). Close to a must-read, although XML basics are simple enough that it's often not necessary. Great to refer back to refresh whitespace and newline handling and which characters are allowed where.
• Namespaces in XML 1.0 (Second Edition). A must-read these days, as namespaces proved wildly popular and show up everywhere.
• XML Base. Very useful, especially with documents served over the Internet.
• XML Schema Part 0: Primer. Grok XSD.
• XML Schema Part 1: Structures. How to put schemas together.
• XML Schema Part 2: Datatypes. Again, this one proved popular beyond schema definitions, and is used to annotate typed XML in a bunch of other technologies.
• XSL Transformations (XSLT). Useful to go over once to play with a processor for a while, but the stuff I usually look up to answer questions is more often the next.
• XML Path Language (XPath). Again, another wildly popular building block, used to select, shred and transform documents the world over.
• XQuery 1.0: An XML Query Language. To be honest, I typically need this in the context of SQL Server, so I go to the highly awesome Books Online more often than not.

And there you go. File them away in a little "XML" folder in your favorites, and see how often to go back to them when you're working with XML-centric projects.

Enjoy!

ASP.NET MVC Framework

Prerequisites

A brief Introduction to the ASP.NET MVC Framework by Scott Guthrie:

• ASP.NET MVC Framework
• ASP.NET MVC Framework (Part 1)
• ASP.NET MVC Framework (Part 2): URL Routing
• ASP.NET MVC Framework (Part 3): Passing ViewData from Controllers to Views

An excellent Screencast by Scott Hanselman.

Overview

The MVC (Model-View-Controller) is a popular pattern to develop UI-centric applications based on a simple concept: divide the implementation into three logical components:

• Model,
• View,
• Controller.

The ASP.NET MVC Framework is an implementation of the MVC pattern, and has built-in support for developing web applications. Let's take a quick look at these three components.

Figure 1: The MVC Framework

• Model: Refers to the domain logic of your application. Usually the state of the Model is persisted in the database. Consider it as the middle tier in a typical n-Tier application, which consist of the business logic and domain objects.
• View: Is typically the User Interface, which is used to show the Model data and take input from the User.
• Controller: Is responsible for handling the user interaction. This is the Ultimate Driver of the whole ASP.NET MVC Framework. Depending upon the User gesture it decides which action to perform on the model; it also builds the view data and finally decides which View to render.

The ASP.NET MVC Framework is an alternate and better way to develop web applications, comparing to the regular web form model. It provides us with:

• Clean Separation of Concerns, where each component is serving only one purpose. Thus it also gives us the opportunity to integrate TDD (Test-Driven Development) in the development workflow and unit test each component without considering the others, as most of the framework components are interface-based. This allows us to mock them out.
• The whole framework is very much extensible and pluggable. It is really easy to replace or customize each part without affecting the others.
• Pretty/SEO (Search Engine Optimization) URLs. Full controls of how URLs are constructed. No need to do URL Rewriting anymore.
• True stateless model of the web. We no longer have to deal with postbacks and ViewState.
• Full control of the generated HTML. This means no more naming containers.
• Utilize the existing knowledge of ASP.NET like Providers, Caching, Configuration and so on.

Request Flow

In regular ASP.NET web form applications, URLs are usually mapped to physical disk files. When a URL is requested, the code of the associated file gets executed, which generates the HTML. However, in the ASP.NET MVC Framework the URLs are tied with the Controllers rather than the disk file. The component that is responsible to map the URL with the Controller is the Routing Handler. When the application starts, it is required to register the URL Routing Rules, which the Routing Handler uses to map the controller when the request arrives. Let's take a quick view of how a request is carried in different layers of the ASP.NET MVC Framework:

Figure 2: The Request Flow

• The user requests a URL.
• The ASP.NET MVC Framework evaluates the requested URL against the registered Routing Rules and finds a matching Controller. The Framework forwards the request to the matching Controller.
• The Controller calls the Model to build ViewData. It can call the model multiple times depending upon the ViewData that it is building.
• The Model, as mentioned earlier, is the middle tier, which might involve data access components, workflow activities, external web service dependencies etc. The Model returns the requested data to Controller.
• The Controller selects a View and passes the data to the View which it previously got from the Model. The View Renders the data and returns the generated HTML to the User.