DCSIMG
June 2006 - Posts - Justin myJustin = new Justin( Expriences.Current );

June 2006 - Posts

[MSDNWiki] MSDNWiki RSS# (New RSS feed for MSDNWiki)

For those of you living in a cave I present - MSDNWiki.

Looks nice and very useful. However, Look closer. Look at the MSDNWiki Rss feeds. MSDNWiki has two Rss Feeds: New blocks and New edits. I've got no idea what's the difference between those two feeds. I can guess, but I'm not sure. Also, These RSS feeds are extremely non-informative. All you know is that some guy (who's name you know) made an edit somewhere and you get a link to the relevant MSDNWiki page. That's great in case you have TIME to open 300 MSDN pages each week (and rising), I don't.

I need a MSDNWiki RSS feed that actually tells me all I need to know.
So I built
MSDNWiki RSS#.
Check it out at http://www.justinangel.net/msdnwiki/MSDNWiki.aspx.

What's cool about it:

1. The title of each RSS post in MSDNWiki RSS# is the Title of the edit/block AND the MSDN page the edit was done at. This is extremely important! the old feeds didn't even say where the edit/block was. You simply had to guess.
in stand of "this doesn't do what you expect" you get "This doesn't do what you expect. (NetworkStream.CanWrite Property (System.Net.Sockets))".

2. There's only ONE feed - not two feeds.

3.  Full Community edit content. Not just the half of the first sentence. You get all the community content, right in your RSS reader.

4. Full MSDN content. If you don't understand some comment made about the MSDN value - you have it in front of you. no more opening MSDN pages & waiting for them to load just so you can understand what the heck this guy is talking about.

5. Filter by phrase. You don't have to suscribe to the full feed, you just need say what interests you. just type your search value in the "filter" querystring variable. For example:
- "System.web.ui" - http://www.justinangel.net/msdnwiki/MSDNWiki.aspx?filter=System.Web.UI
- "yield" - http://www.justinangel.net/msdnwiki/MSDNWiki.aspx?filter=yield
- "Visual basic" - http://www.justinangel.net/msdnwiki/MSDNWiki.aspx?filter=Visual%20Basic

Just subscribe to http://www.justinangel.net/msdnwiki/MSDNWiki.aspx?filter=Your phrase here.

6. Doesn't show duplicate edits/blocks. MSDNWiki RSS# checks you only get the latest changes and not twenty links to the same page.

 

Full source available for download at: http://www.JustinAngel.Net/files/MSDNwiki.zip

If you need more features, want to report a bug or anything else - Just ask.  Thanks to Miki Watts for beta testing.

 

Here's an example of MSDNWiki original RSS feeds VS. MSDNWiki RSS# feed on the "yield" update. After you see this - you choose which feed you rather subscribe to.



Original MSDNWiki Rss feed information:

 

RSS/ATOM Post Notes

MSDN Wiki New Blocks — Today 05:56

Edit by TAG -- ADDITIONAL NOTES: You also use System.Collections.Generic.IEnumerable<T> as return type o...

 

MSDNWiki RSS#:

RSS/ATOM Post Notes (yield (C#))

MSDNWiki RSS# — Today 05:56

Community Content
Notes
edit | discuss | notify me | show history (4)
created by  TAG

modified on 6/24/2006 3:56:51 AM UTC by  TAG

ADDITIONAL NOTES:
You also use System.Collections.Generic.IEnumerable<T> as return type of iterator block.

A yield statement can not be used in body of finally block.

Using try/finally blocks with yield return statement inside them is unsafe if iteration performed using MoveNext/Current methods. Execution of statements inside finally block is not guaranteed. They will be executed only after all values before block will be iterated and next one requested OR IDisposable.Dispose method called on IEnumerator. Finally statements will not be executed during garbage collection as compiler generated iterator class have no finalizer. Using with foreach is safe as compiler will generate call to Dispose.


MSDN original Content

yield (C# Reference) 

Used in an iterator block to provide a value to the enumerator object or to signal the end of iteration. It takes one of the following forms:

yield return <expression>;
yield break;

expression is evaluated and returned as a value to the enumerator object; expression has to be implicitly convertible to the yield type of the iterator.

The yield statement can only appear inside an iterator block, which might be used as a body of a method, operator, or accessor. The body of such methods, operators, or accessors is controlled by the following restrictions:

  • Unsafe blocks are not allowed.

  • Parameters to the method, operator, or accessor cannot be ref or out.

A yield statement cannot appear in an anonymous method. For more information, see Anonymous Methods (C# Programming Guide).

When used with expression, a yield return statement cannot appear in a catch block or in a try block that has one or more catch clauses. For more information, see Exception Handling Statements (C# Reference).

In the following example, the yield statement is used inside an iterator block, which is the method Power(int number, int power). When the Power method is invoked, it returns an enumerable object that contains the powers of a number. Notice that the return type of the Power method is IEnumerable, an iterator interface type.

// yield-example.cs
using System;
using System.Collections;
public class List
{
    public static IEnumerable Power(int number, int exponent)
    {
        int counter = 0;
        int result = 1;
        while (counter++ < exponent)
        {
            result = result * number;
            yield return result;
        }
    }

    static void Main()
    {
        // Display powers of 2 up to the exponent 8:
        foreach (int i in Power(2, 8))
        {
            Console.Write("{0} ", i);
        }
    }
}

Output

2 4 8 16 32 64 128 256 

For more information, see the following sections in the C# Language Specification:

  • 19.3 Iterators

  • 22 Iterators

Reference

Concepts

Other Resources

Source: MSDNWiki


 

MSBuild SideKick is out! Get it now!

If you're using MSBuild you know there're a few annoying caveats when editing XML MSBuild scripts. The biggest one of them all - You're editing XML MSBuild scripts. I like notepad & Visual studio's XML editor like the next guy. But it just wasn't meant for this kind of use.

So the guys from Attrice created "MSBuild SideKick" which is  VERY cool & powerful GUI for editing MSBuild Scripts.

If you don't already have it - Go download it now!
 
After that being said, here's some feedback for the creators of this wonderful tool:

  1. Create some default "using" file for projects. I've got projects with more then 25+ build assemblies (MSbuildTasks, MSBee, Script# and so on). It's just not feasible to go adding them one by one.
  2. Add a "run" button that saves the MSBuild script and sends it to the MSBuild.exe tool.
  3. Create a Visual studio add-in so in order to edit a project file I’d be able to use your cool tool (in stand of having to unload the project, edit the project file and load it back again). It should be something like the reflector folks have.
  4. Add an "add-in" capability. Again, like the reflector folks have. That way I won't need to give you feedback and ask you to add stuff, I could build my own add-ins. CodeProject has a great article about how to add an addin feature to an application.
  5. The main treenode should point to a window that contains the XML MSBuild document (The "Show XML" button is nice, but it's not very intuitive).
  6. DRAG & DROP! I miss it :)
    A drag&drop feature from the "using" tasks to the targets would be great.
  7. The targets "Add task" dialog should give you the option of adding the "using" assembly for tasks and refreshing itself. That's one less step newbies will have to do.
  8. Multiple select in DataGridViews. I wanted to delete two files together from an itemgroup and couldn't do that. Same about removing multiple "using" Tasks.
  9. Adding a row from within the DataGridView by clicking on the "down" arrow in the last row.
  10. How about a feature like Management studio for sql 2005 has that in each screen let's you see your current script at each time. Let's say I’m editing a target element, I’d like to have to option of switching right there and then to see only this target's XML script. Same goes for Item groups & Property Groups & Tasks & Imports.
  11. Condition Intellisense. I'd LOVE to have some sort of condition intellisense so I won't have to flip between scripts in various screens to get my Tags & Properties & Target names.
  12. Dialogs. In the item groups the "include" group should have an option of opening an OpenFileDialog to get the file name & relative path.
  13. Assembly navigator (maybe a GAC navigator?) For ItemGroup "References".
  14. Temporary file backup. After the first change is made it'll prudent to create a temp file that contains recent changes. That way if the tool crashes there's a backup.
  15. Maybe a special contextMenu in the "Value" of properties? Like, "Generate GUID" for project GUID, "Add path", "Add file" and so on.
  16. This one is purely me getting all worked up from NDepend - how about some cool graphics to ilustrate the build process? Some arrows, 3d boxes, start & end points. Could be very cool.