Tuesday, August 26, 2008
I only learnt about this featurette very recently (from a reader's comment) and immediately found a use for it – read on.
If you tried to debug the code from this exercise (still no correct answers to the quiz!), you probably found out that the variable corresponding to the Task that you want to examine is usually out of scope. You can look at the Threads window and try and map the Thread to the Task but there is another way: add once to the Watch window the expression
The only problem is that we have to tediously expand the variable each time to determine its Id, since the default display when the expression is evaluated is not useful ("{System.Threading.Tasks.Task}").
This is where the C#-only debugger feature comes in: Make Object ID, accessible from the ContextMenu in the Watch window. Once you break in the debugger, Make Object ID for the Task.Current, then switch Threads and do the same for the other. Now you can distinguish between them easily due to the appended {1#}, {2#}, and you can add a Watch directly to the objects in memory:
This is a neat little feature and even more useful for other scenarios where there is a need to distinguish between 2 or more identical-looking objects in the debugger.
If you tried to debug the code from this exercise (still no correct answers to the quiz!), you probably found out that the variable corresponding to the Task that you want to examine is usually out of scope. You can look at the Threads window and try and map the Thread to the Task but there is another way: add once to the Watch window the expression
Task.Current. When breaking in the debugger, switch between the threads in the Threads window to see the active/current Task for that Thread in the Watch window.The only problem is that we have to tediously expand the variable each time to determine its Id, since the default display when the expression is evaluated is not useful ("{System.Threading.Tasks.Task}").
This is where the C#-only debugger feature comes in: Make Object ID, accessible from the ContextMenu in the Watch window. Once you break in the debugger, Make Object ID for the Task.Current, then switch Threads and do the same for the other. Now you can distinguish between them easily due to the appended {1#}, {2#}, and you can add a Watch directly to the objects in memory:
This is a neat little feature and even more useful for other scenarios where there is a need to distinguish between 2 or more identical-looking objects in the debugger.
Labels: dot NET general
Friday, August 22, 2008
Steps:
1. New C# Console Project in VS2008
2. Add Reference to
3. Replace the entire contents of
4. Insert a breakpoint (F9) wherever there is a comment.
Questions:
A. Without running the project, what can you predict about which breakpoints will be hit and in what order?
B. Can you predict at each breakpoint, which of the two variables (
1. New C# Console Project in VS2008
2. Add Reference to
System.Threading.dll (from Parallel Extensions June CTP)3. Replace the entire contents of
Program.cs with the following (overly simplified extract of a more complex piece of code):using System;
using System.Threading.Tasks;
static class Program
{
static void Main()
{
Task t1 = Task.Create(delegate
{
Task t2 = Task.Create( // breakpoint #1
(o) =>
Console.WriteLine(o.ToString()) // breakpoint #2
, "hey");
t2.Wait(); // breakpoint #3
});
t1.Wait(); // breakpoint #4
Console.ReadLine(); // breakpoint #5
}
}
4. Insert a breakpoint (F9) wherever there is a comment.
Questions:
A. Without running the project, what can you predict about which breakpoints will be hit and in what order?
B. Can you predict at each breakpoint, which of the two variables (
t1, t2) is in scope (e.g. if they were in the Watch window)?Labels: ParallelComputing
Wednesday, August 13, 2008
Everyone close to me that knows I recently changed jobs keeps asking me what it means to be a feature PM (not to be confused with Product Manager which is primarily a marketing role). The Program Manager role is so complex I am having trouble explaining it. I am not ready yet, so I will revisit the topic in the future but someone once told me:
Looking at it from a different angle it seems that there are several hats that a PM wears and I find myself alternating between writing specs, project managing, testing scenarios on the product, creating walkthroughs, threat modelling, writing demos/samples, liaising with sister teams, liaising with internal customers and, finally, preparing to imminently liaise with developer customers (both inbound and outbound comms, gathering feedback and sharing the vision) when we release it.
Some view the "drawback" of this role being that: you have tons of responsibilities which you can only deliver via a team on which you have no authority. Read that sentence again. I think this is what differentiates this role from others outside of Microsoft. I actually enjoy this because it creates a true team spirit. Because most new PMs seem to find this the hardest part, most experienced PMs focus on sharing tips on how to overcome this "hurdle". Today I found such a post that advises on the success patterns for PMs (with many good links).
"a product needs developers to write the code and testers to test it. There are other things involved with shipping a product and the PM does those".So far I can share that I spend 75% of my time in meetings. The funny thing is that I used to view meetings as a waste of time, but for the first time in my career I am actually having tons of useful meetings. The reason is probably because most of them are of the brainstorming variety (where by the end your creativity juices are just oozing all over the place) or of the unblocking variety (where at the end someone is unblocked and can do their job, which they couldn't do without that meeting having taken place).
Looking at it from a different angle it seems that there are several hats that a PM wears and I find myself alternating between writing specs, project managing, testing scenarios on the product, creating walkthroughs, threat modelling, writing demos/samples, liaising with sister teams, liaising with internal customers and, finally, preparing to imminently liaise with developer customers (both inbound and outbound comms, gathering feedback and sharing the vision) when we release it.
Some view the "drawback" of this role being that: you have tons of responsibilities which you can only deliver via a team on which you have no authority. Read that sentence again. I think this is what differentiates this role from others outside of Microsoft. I actually enjoy this because it creates a true team spirit. Because most new PMs seem to find this the hardest part, most experienced PMs focus on sharing tips on how to overcome this "hurdle". Today I found such a post that advises on the success patterns for PMs (with many good links).
Labels: Personal
Friday, August 01, 2008
The Professional Developers Conference (PDC) is held in October at Los Angeles, which is one of the reasons I am looking forward to be going there (as a teenager I was a huge The Doors fan), another reason being the party.However, the main reason I am excited to be going this year is because I will have the opportunity to share with developers from around the world some of the cool things that our teams have been working on.
Parallel Computing has a very strong presence at PDC08, so follow the links to find out more:
1. A whole PreCon day of Concurrent, multi-core programming on Windows and .NET.
2. Four breakout sessions (click on the Parallelism [4] tag in the sessions list)
3. Even more on the final day of PDC, to be shared later...
Hope to see you there!
Labels: Events
Tuesday, July 29, 2008
Tip #1 – datatips on comments
One of the coolest debugger features introduced in VS2005 was DataTips (grey editable, navigable tooltips on steroids that also become transparent when you hold down the Ctrl key). Did you know that you can get data tips for commented code? At first this made me raise an eyebrow, but I can see how for some piece of code I may always need to inspect some other variables quickly and do not want to have to enter them in the watch window manually or navigate to the required area from existing variables that do exist in code. Here is a screenshot that shows this feature in action:
Notice how the datatip appears after highlighting a variable that is in a commented area of the editor (my highlight is set to yellow).
Tip #2 – save output window
In Visual Studio many times we need to transfer the text from the Output window to an actual txt file. Dunno about you, but I always selected all (Ctrl+A), copied (Ctrl+C) and then pasted (Ctrl+V) into a notepad instance that I always have running (Alt+TAB). It turns out that there is a direct way of saving that output to a file. Simply hit Ctrl+S (or invoke it from the menu item) once you've given focus to the Output window – nice!
What cool debugger features do you like in Visual Studio (or would like to see)?
One of the coolest debugger features introduced in VS2005 was DataTips (grey editable, navigable tooltips on steroids that also become transparent when you hold down the Ctrl key). Did you know that you can get data tips for commented code? At first this made me raise an eyebrow, but I can see how for some piece of code I may always need to inspect some other variables quickly and do not want to have to enter them in the watch window manually or navigate to the required area from existing variables that do exist in code. Here is a screenshot that shows this feature in action:
Notice how the datatip appears after highlighting a variable that is in a commented area of the editor (my highlight is set to yellow).
Tip #2 – save output window
In Visual Studio many times we need to transfer the text from the Output window to an actual txt file. Dunno about you, but I always selected all (Ctrl+A), copied (Ctrl+C) and then pasted (Ctrl+V) into a notepad instance that I always have running (Alt+TAB). It turns out that there is a direct way of saving that output to a file. Simply hit Ctrl+S (or invoke it from the menu item) once you've given focus to the Output window – nice!
What cool debugger features do you like in Visual Studio (or would like to see)?
Labels: dot NET general
Monday, July 28, 2008
When most people's brains first light up on why parallelism is the next BigThing, some jump to the conclusion that Moore's law is over. Let's clear that up below.
All of you know Gordon Moore's law which boils down to the prediction of
So, now that chip manufacturers cannot make single CPUs any faster (well, they can, but they can't cool them down enough to make them useful), they are resorting to having chips with multiple cores, which we are terming the manycore shift. The manycore shift has a profound impact on developers (especially those programming for the desktop client) in that their software now has to learn how to take advantage of parallelism.
So if you followed the logical flow so far, you'll conclude that Moore's law is still alive: we are still getting more silicon, but it does not translate to increased linear speed, but rather to parallel "engines" that your software must learn to utilise.
I am glad we cleared that up :)
All of you know Gordon Moore's law which boils down to the prediction of
"the number of transistors on a chip will double about every two years"In the last 30-40 years the previous prediction has manifested itself in clock speed increases and that is what has tricked most of us to associate Moore's law with CPU speed.
So, now that chip manufacturers cannot make single CPUs any faster (well, they can, but they can't cool them down enough to make them useful), they are resorting to having chips with multiple cores, which we are terming the manycore shift. The manycore shift has a profound impact on developers (especially those programming for the desktop client) in that their software now has to learn how to take advantage of parallelism.
So if you followed the logical flow so far, you'll conclude that Moore's law is still alive: we are still getting more silicon, but it does not translate to increased linear speed, but rather to parallel "engines" that your software must learn to utilise.
I am glad we cleared that up :)
Labels: ParallelComputing
Tuesday, July 22, 2008
One of my pet peeves is ensuring that whenever there is code that explicitly creates a thread, to always have an accompanying statement that names the thread. This is invaluable in debugging. With managed code, it is so simple, just one extra statement to set the thread's Name property (which you can only do once at runtime, of course).
This is such a useful thing to have when debugging, that in VS2008 the ability was added to name threads after execution had started. The idea there is for naming Threads that you don't control but still need to easily identify for debugging purposes. The name does not persist cross debugging sessions and indeed it is not used at runtime by anything other than your... eyes. I describe this feature as part of my video on all the new VS2008 threading enhancements (watch minutes 06:00 through 08:20, although I recommend the full 15 minutes).
At the OS level the ability to have names against threads is not supported (but you can use nice HEX ids to assist with your debugging ;)). Recently I discovered that there is an old trick (or hack IMO) that you can use with certain tools (inc. Visual Studio) to set names on native threads too. To get the details visit this short How To on MSDN. I did a quick search and discovered two more places on the web where this is described. One is on codeproject which is blatantly lifted from MSDN but it adds a couple of screenshots. The other also points to (an obsolete place on) MSDN and adds a bit more detail.
In short, for my managed friends: Search your code base now for the string "= new Thread" and for every match that you find, verify that you are also setting the Name property. You'll thank me later.
This is such a useful thing to have when debugging, that in VS2008 the ability was added to name threads after execution had started. The idea there is for naming Threads that you don't control but still need to easily identify for debugging purposes. The name does not persist cross debugging sessions and indeed it is not used at runtime by anything other than your... eyes. I describe this feature as part of my video on all the new VS2008 threading enhancements (watch minutes 06:00 through 08:20, although I recommend the full 15 minutes).
At the OS level the ability to have names against threads is not supported (but you can use nice HEX ids to assist with your debugging ;)). Recently I discovered that there is an old trick (or hack IMO) that you can use with certain tools (inc. Visual Studio) to set names on native threads too. To get the details visit this short How To on MSDN. I did a quick search and discovered two more places on the web where this is described. One is on codeproject which is blatantly lifted from MSDN but it adds a couple of screenshots. The other also points to (an obsolete place on) MSDN and adds a bit more detail.
In short, for my managed friends: Search your code base now for the string "= new Thread" and for every match that you find, verify that you are also setting the Name property. You'll thank me later.
Labels: ParallelComputing
Saturday, July 12, 2008
Yesterday a new 1-hour video interview on C# 4.0 was posted on channel9.
At some point the question is posed to Anders:
At some point the question is posed to Anders:
"What are some of the big issues that you are thinking about for the future?"and Anders' reply (ffw to 39:56) identifies concurrency as the #1 thing:
"Concurrency is by far... profoundly changing... Moore's law... we've been ignoring concurrency because we could... now we can't... it is a damn hard problem..."My favorite quote comes at 45:13 and includes hand gestures too:
"It is foolish to think that somehow we are going to be able to pepper concurrency on your code and you wouldn't need to modify anything in your apps today for them to run concurrently"For the stuff in-between and to get the complete picture, watch the video.
Labels: ParallelComputing
Wednesday, July 02, 2008
As I did last year, thought I'd share that today (or yesterday depending on where you are) is(was) my 34th. I'll always remember this day as the day I received my SSN (progressing nicely thru the unordered list).
Labels: Personal
Monday, June 23, 2008
The goal: to withdraw some cash from one account and deposit it to another. How hard can it be? Isn't ATM user interface design an established known thing? Apparently not, as I found out...
I walked up (with a helper friend) to a cashpoint (the "hole in the wall") which had a big colour screen with buttons either side of it and more buttons in a keypad below. The screen rotated through some adverts and included no instructions as to what do: I inserted my card to make a withdrawal. Nothing happened. We both stared at the screen and start pressing some buttons – nothing. Eventually she went in to the bank to ask for instructions while I continued tapping on the screen and buttons for a little longer. I got bored so withdrew my card... and after a couple of seconds, guess what? It asks me for the PIN number! Wow! You have to pull the card out in order for it to operate... good thing I didn't walk away immediately as the next person could have come along and played "guess the PIN" without ever getting hold of my card! Anyway, in the end the withdrawal succeeded and I had $500 in $20 denominations which is what it gave out. Next step: deposit that cash into another account.
I insert the other card, nothing happens but now I know the trick so I pull the card out and I get prompted for the PIN (after a brief delay). It asks how much I want to deposit. I enter the amount of $500. It dispenses an envelope and instructs me to insert the cash in the envelope and stick it back in the slot; it states that the envelope must not contain more than 10 banknotes! How am I to deposit $500 that it just gave me in 20s by using only 10 notes?! If that is its limitation why didn't it state that before asking me how much I wanted to deposit? This is yet another example of getting the steps in the wrong order. Anyway, since I couldn't find a cancel button (or some other Ctrl+Z option) I put $200 in the envelope and stuffed it in the slot. It gave me a receipt thanking me for depositing $500 :-) By this stage, the person working at the bank comes out and after hearing the story says: "Yeah that happens all the time, I'll correct it on the computer". Sigh.
Why do we put up with such systems? I don't think we'll advance our profession as long as users have already decided to tolerate the crap we serve them.
I walked up (with a helper friend) to a cashpoint (the "hole in the wall") which had a big colour screen with buttons either side of it and more buttons in a keypad below. The screen rotated through some adverts and included no instructions as to what do: I inserted my card to make a withdrawal. Nothing happened. We both stared at the screen and start pressing some buttons – nothing. Eventually she went in to the bank to ask for instructions while I continued tapping on the screen and buttons for a little longer. I got bored so withdrew my card... and after a couple of seconds, guess what? It asks me for the PIN number! Wow! You have to pull the card out in order for it to operate... good thing I didn't walk away immediately as the next person could have come along and played "guess the PIN" without ever getting hold of my card! Anyway, in the end the withdrawal succeeded and I had $500 in $20 denominations which is what it gave out. Next step: deposit that cash into another account.
I insert the other card, nothing happens but now I know the trick so I pull the card out and I get prompted for the PIN (after a brief delay). It asks how much I want to deposit. I enter the amount of $500. It dispenses an envelope and instructs me to insert the cash in the envelope and stick it back in the slot; it states that the envelope must not contain more than 10 banknotes! How am I to deposit $500 that it just gave me in 20s by using only 10 notes?! If that is its limitation why didn't it state that before asking me how much I wanted to deposit? This is yet another example of getting the steps in the wrong order. Anyway, since I couldn't find a cancel button (or some other Ctrl+Z option) I put $200 in the envelope and stuffed it in the slot. It gave me a receipt thanking me for depositing $500 :-) By this stage, the person working at the bank comes out and after hearing the story says: "Yeah that happens all the time, I'll correct it on the computer". Sigh.
Why do we put up with such systems? I don't think we'll advance our profession as long as users have already decided to tolerate the crap we serve them.
Labels: Personal
Sunday, June 22, 2008
It has been a week since I used a one way ticket to move from the UK to the USA. Closing down my life in the UK was a strainful experience and now I need to open a new one in the US.
There are tons of things to do in order to settle in – it is what I call "getting a life". I am sharing this list below partly for my tracking, partly because it may be of interest to anyone else going through the same relocation and partly so those of you that interact with me in person know where the stress is coming from:
1. Rent a mailbox for a year (redirecting mail from UK)
2. Move into temporary accommodation for a couple of months
3. Rent a car for a month
4. Communicate with legal parties to finalise the L1 Visa process
5. Get acquainted with area e.g. grocery stores, how to drive to work etc
6. Receive the AIR shipment of personal belongings (10 large boxes) and unpack
7. Get a new mobile phone (number + device)
8. Open a bank account
9. Apply to get pre-approved for a mortgage
10. Start house hunting, make offer, buy, move (this can be a whole list on its own)
11. Get a Social Security Number (SSN)
12. Get a credit card
13. Have driving lessons
14. Take driving written test (after learning some new road signs)
15. Take driving test and hence driving licence
16. Buy car (do this via a loan in order to build some US credit history)
And last but not least:
17. Settle into new job / role
Another reason I am sharing the above is so those of you staying tuned on the RSS feed know why it is going to be a quiet summer... I can't wait to get through to the other side of all that and start sharing with you the coolest stuff coming in the next version of Visual Studio ;)
There are tons of things to do in order to settle in – it is what I call "getting a life". I am sharing this list below partly for my tracking, partly because it may be of interest to anyone else going through the same relocation and partly so those of you that interact with me in person know where the stress is coming from:
1. Rent a mailbox for a year (redirecting mail from UK)
2. Move into temporary accommodation for a couple of months
3. Rent a car for a month
4. Communicate with legal parties to finalise the L1 Visa process
5. Get acquainted with area e.g. grocery stores, how to drive to work etc
6. Receive the AIR shipment of personal belongings (10 large boxes) and unpack
7. Get a new mobile phone (number + device)
8. Open a bank account
9. Apply to get pre-approved for a mortgage
10. Start house hunting, make offer, buy, move (this can be a whole list on its own)
11. Get a Social Security Number (SSN)
12. Get a credit card
13. Have driving lessons
14. Take driving written test (after learning some new road signs)
15. Take driving test and hence driving licence
16. Buy car (do this via a loan in order to build some US credit history)
And last but not least:
17. Settle into new job / role
Another reason I am sharing the above is so those of you staying tuned on the RSS feed know why it is going to be a quiet summer... I can't wait to get through to the other side of all that and start sharing with you the coolest stuff coming in the next version of Visual Studio ;)
Labels: Personal
Wednesday, June 18, 2008
I know there is a generic lesson for UI designers in the mini-rant below...
Recently I had to change the pin of a smartcard that I have which required a number of steps:
Step 1: Insert smartcard into your laptop reader.
Step 2: Run client tool XYZ and click on a button which will auto-populate a textbox.
Step 3: Take the textbox results of Step 1 and paste them on a separate textbox on a webpage
Step 4: Enter in a second textbox on the webpage, the smart card number
Note: this is a number that is never used for anything else and is in small print on the side of the smart card. So I had to remove the card to copy the info.
Step 5: Hit the button on the webpage and check your email
Step 6: wait for email. Read the email (which is also sent to a bunch of approvers) which gives you a string – copy it
Step 7: Paste the string into a second textbox in the client tool we run at step 2
Result: BOOM with a message along the lines of: "The two strings (challenge / response) are not pairs. Please ensure that you do not remove the card during the entire process."
Why couldn't they have started with that statement up front? Why don't they state that next to step 4 at least? Why after removing and reinserting the card, don't they detect and give you a warning that remainder steps are futile? Why don't they take step 4 and move it to Step 0?
Recently I had to change the pin of a smartcard that I have which required a number of steps:
Step 1: Insert smartcard into your laptop reader.
Step 2: Run client tool XYZ and click on a button which will auto-populate a textbox.
Step 3: Take the textbox results of Step 1 and paste them on a separate textbox on a webpage
Step 4: Enter in a second textbox on the webpage, the smart card number
Note: this is a number that is never used for anything else and is in small print on the side of the smart card. So I had to remove the card to copy the info.
Step 5: Hit the button on the webpage and check your email
Step 6: wait for email. Read the email (which is also sent to a bunch of approvers) which gives you a string – copy it
Step 7: Paste the string into a second textbox in the client tool we run at step 2
Result: BOOM with a message along the lines of: "The two strings (challenge / response) are not pairs. Please ensure that you do not remove the card during the entire process."
Why couldn't they have started with that statement up front? Why don't they state that next to step 4 at least? Why after removing and reinserting the card, don't they detect and give you a warning that remainder steps are futile? Why don't they take step 4 and move it to Step 0?
Labels: Personal
Friday, June 06, 2008
On 12th June at TVP in Reading you should not miss the NxtGenUG Fest08. I'll be making a short appearance to give a brief glimpse at Parallel LINQ (PLINQ). Laughs are also guaranteed as the day ends with the game show "Whose Session Is It anyway" that I am told I must also participate in – oh dear... Register now.
Labels: Events
For those that I met in Orlando, here are the resources:
1. Talking about the 2 sessions.
2. Sharing Assets.
3. Five Cool things.
1. Talking about the 2 sessions.
2. Sharing Assets.
3. Five Cool things.
Labels: Events
Wednesday, June 04, 2008
While at Tech Ed, I spent 13 minutes chatting with Richard Campbell about my two sessions. View the recording on this page (or download the wmv).
Labels: Links
Thank you for attending the developer session with the title of this blog post. Below are some resources for you.
- Download the slides and demos for this talk here.
- For my relevant blog posts, follow all the links (the hyperlinked numbers 1-9) from this blog post.
- Best of all, ignore all of the above, and just read my MSDN mag article which I link to from here.
- Download the slides and demos for this talk here.
- For my relevant blog posts, follow all the links (the hyperlinked numbers 1-9) from this blog post.
- Best of all, ignore all of the above, and just read my MSDN mag article which I link to from here.
Labels: Mobile and Embedded
Monday, June 02, 2008
Following the first ever drop last December, the latest preview is now available. Ed has the link and details here.
Labels: Links, ParallelComputing
Thursday, May 29, 2008
I have 2 sessions at Tech Ed in Orlando this year. Add them to your schedule.
Also after my session on Wednesday, between 10:00 and 18:30, together with my 2 co-authors we will be signing copies of our book at the bookstore - brings yours along for instant devaluation :)
I'll be around all week (Sunday 1st to Sunday 8th), so if you are in the area between those dates and you want to catch up over a pint or 3, ping me.
- Wednesday 4th June, 16:30-17:45, MBL308 in room S230 G
Sharing Assets between the.NET Compact Framework and the .NET Framework
- Friday 6th June, 13:00-14:15, TLA318 in room S320 C
5 Cool Things to Know and Use for Smart Client Development with VS2008 and .NET Framework v3.5
Also after my session on Wednesday, between 10:00 and 18:30, together with my 2 co-authors we will be signing copies of our book at the bookstore - brings yours along for instant devaluation :)
I'll be around all week (Sunday 1st to Sunday 8th), so if you are in the area between those dates and you want to catch up over a pint or 3, ping me.
Labels: Events
Wednesday, May 28, 2008
Following from Part 1, Part 2 and Part 3, in this last part of the exploration I'll focus on the UI layer and I'll have even more of a statistical hat on.
11. System.Windows.dll is yet another Silverlight assembly with no direct counterpart in the full framework, but with tons of stuff inside (as evidenced by its size on disc and by the 21 namespaces!) that makes it the 2nd largest assembly. You can think of it as the brick that gives Silverlight its WPF UI. Its namespaces come from various v2.0 and v3.0 desktop assemblies as listed below (and it is in my opinion a prime candidate for refactoring):
-System.Net namespace with WebClient plus 6 related classes comes from the desktop's System.dll (!)
- System.ComponentModel comes from System.dll (! again) and is basically the BackgroundWorker implementation.
- 5 of its namespaces (System.Windows.Controls.Primitives, System.Window.Data, System.Windows.Documents, System.Windows.Resources, System.Windows.Shapes) and the System.ComponentModel.DesignerProperties class map to the desktop's PresentationFramework.dll
- 3 of its namespaces (System.Collections.ObjectModel, System.Collections.Specialized, System.Threading) map to WindowsBase.dll.
- 2 of its namespaces (System.Windows.Ink, System.Windows.Media.Imaging) map to the desktop's PersentationCore.dll.
- System.Windows namespace has a total of 61 types, coming from homonymous namespaces in PresentationCore.dll (e.g. FontStyle, RoutedEventHandler) and PresentationFramework.dll (e.g. Application, FrameworkElement) and WindowsBase.dll (e.g. DependencyProperty, Point) and also introduces some new types (e.g. AssemblyPart, ErrorType).
- System.Windows.Markup namespace with 2 types from WindowsBase.dll, 2 from PresentationFramework.dll and 1 from PresentationCore.dll.
- System.Windows.Media namespace which maps to PresentationCore.dll except for Matrix class from WindowsBase.dll and 5 new Silverlight types (MediaElementState, TimelineMarkerCollection plus 2 relatives and VideoBrush).
- System.Windows.Input largely maps to PresentationCore.dll, except for 2 classes (Key and ModifierKeys) from WindowsBase.dll and 1 class (KeyboardNavigationMode) from PresentationFramework.dll. There is also one new class in there: StylusInfo.
- System.Windows.Controls namespace has 24 types that come from PresentationFramework.dll (same namespace name of course). It also has 2 types (MultiScaleImage, MultiScaleSubImage) that make up the DeepZoom feature. It also has 3 types (2 from System.Windows.Forms.dll plus 1 brand new) that make up the OpenFileDialog feature.
- System.IO.IsolatedStorage.ApplicationSettings class has no counterpart in the desktop world and was touched upon here (scroll to the bottom).
- System.Windows.Interop namespace with 3 classes (Content, Settings and SilverlightHost) that is all new in Silverlight framework (even though that namespace name exists in various other WPF assemblies).
12. and 13. System.Windows.Controls.dll and System.Windows.Controls.Extended.dll
The overwhelming majority of the Silverlight controls reside in the System.Windows.Controls.dll assembly. The Extended.dll adds the Calendar, DatePicker, Slider and WatermarkedTextBox.
14. System.Windows.Controls.Data.dll
This adds a control not available at present in WPF: the Silverlight DataGrid. For all things DataGrid-related visit Scott's blog.
11. System.Windows.dll is yet another Silverlight assembly with no direct counterpart in the full framework, but with tons of stuff inside (as evidenced by its size on disc and by the 21 namespaces!) that makes it the 2nd largest assembly. You can think of it as the brick that gives Silverlight its WPF UI. Its namespaces come from various v2.0 and v3.0 desktop assemblies as listed below (and it is in my opinion a prime candidate for refactoring):
-System.Net namespace with WebClient plus 6 related classes comes from the desktop's System.dll (!)
- System.ComponentModel comes from System.dll (! again) and is basically the BackgroundWorker implementation.
- 5 of its namespaces (System.Windows.Controls.Primitives, System.Window.Data, System.Windows.Documents, System.Windows.Resources, System.Windows.Shapes) and the System.ComponentModel.DesignerProperties class map to the desktop's PresentationFramework.dll
- 3 of its namespaces (System.Collections.ObjectModel, System.Collections.Specialized, System.Threading) map to WindowsBase.dll.
- 2 of its namespaces (System.Windows.Ink, System.Windows.Media.Imaging) map to the desktop's PersentationCore.dll.
- System.Windows namespace has a total of 61 types, coming from homonymous namespaces in PresentationCore.dll (e.g. FontStyle, RoutedEventHandler) and PresentationFramework.dll (e.g. Application, FrameworkElement) and WindowsBase.dll (e.g. DependencyProperty, Point) and also introduces some new types (e.g. AssemblyPart, ErrorType).
- System.Windows.Markup namespace with 2 types from WindowsBase.dll, 2 from PresentationFramework.dll and 1 from PresentationCore.dll.
- System.Windows.Media namespace which maps to PresentationCore.dll except for Matrix class from WindowsBase.dll and 5 new Silverlight types (MediaElementState, TimelineMarkerCollection plus 2 relatives and VideoBrush).
- System.Windows.Input largely maps to PresentationCore.dll, except for 2 classes (Key and ModifierKeys) from WindowsBase.dll and 1 class (KeyboardNavigationMode) from PresentationFramework.dll. There is also one new class in there: StylusInfo.
- System.Windows.Controls namespace has 24 types that come from PresentationFramework.dll (same namespace name of course). It also has 2 types (MultiScaleImage, MultiScaleSubImage) that make up the DeepZoom feature. It also has 3 types (2 from System.Windows.Forms.dll plus 1 brand new) that make up the OpenFileDialog feature.
- System.IO.IsolatedStorage.ApplicationSettings class has no counterpart in the desktop world and was touched upon here (scroll to the bottom).
- System.Windows.Interop namespace with 3 classes (Content, Settings and SilverlightHost) that is all new in Silverlight framework (even though that namespace name exists in various other WPF assemblies).
12. and 13. System.Windows.Controls.dll and System.Windows.Controls.Extended.dll
The overwhelming majority of the Silverlight controls reside in the System.Windows.Controls.dll assembly. The Extended.dll adds the Calendar, DatePicker, Slider and WatermarkedTextBox.
14. System.Windows.Controls.Data.dll
This adds a control not available at present in WPF: the Silverlight DataGrid. For all things DataGrid-related visit Scott's blog.
Labels: Silverlight
Tuesday, May 27, 2008
A cool class that was introduced in .NET Framework v2.0 is the BackgroundWorker. If you do any kind of UI development I encourage you to learn about this class (e.g. by following the links below), which makes it easy to execute long running operations on a separate thread, supporting cancellation, progress reporting and marshalling results back to the UI thread.
Back in 2004 I described what the class looks like (inc. links to MSDN) when I implemented it for the .NET Compact Framework v1.0/v2.0 (and for .NET Framework v1.1): BackgroundWorker. I also provided sample code to demonstrate the usage.
An added incentive to learn about it is that Silverlight 2 includes a fully interface-compatible version of BackgroundWorker. A good way to learn about it is by porting to Silverlight the desktop PI sample from my previous blog post and follow what the code does... have fun!
Back in 2004 I described what the class looks like (inc. links to MSDN) when I implemented it for the .NET Compact Framework v1.0/v2.0 (and for .NET Framework v1.1): BackgroundWorker. I also provided sample code to demonstrate the usage.
An added incentive to learn about it is that Silverlight 2 includes a fully interface-compatible version of BackgroundWorker. A good way to learn about it is by porting to Silverlight the desktop PI sample from my previous blog post and follow what the code does... have fun!
Labels: dot NET general, Silverlight
Copyright © Daniel Moth
