The .NET Endpoint blog announced this morning the availability of Windows Server AppFabric Beta 2, which can be downloaded at http://msdn.microsoft.com/appfabric. According to the announcement, Beta 2 was written to work against the RC of Visual Studio 2010, and is apparently now feature complete:

This build represents our “feature complete” milestone. That is, it contains all the features that we plan to ship in Windows Server AppFabric v1 by Q3 of 2010. For this release we focused on building a provider model for persistence, monitoring, and cache configuration stores. In our Beta 1 release we supported only the SQL Server based persistence and monitoring providers that we shipped and supported only an XML file based or SQL Server based cache configuration store. In Beta 2 we now also support providers for other database platforms or for other types of stores, in the case of persistence and cache configuration.

This is an exciting milestone for the team, and will certainly be a great time to begin evaluating Windows Server AppFabric for inclusion in upcoming projects.

Last week I undertook a completely unscientific study of the .NET Blogosphere (as much as I loathe that term), to determine which namespaces and classes people are most excited about, confused by, or frustrated with – at least to the point that they would dedicate the time to write in their blog about them. My methods for undertaking this study were rather simplistic. I wrote a quick and dirty console application to reflect through the .NET Framework namespaces and classes, and search the internet for mentions of them alongside the terms .NET and blog. For classes whose namespaces contained no periods, the full name of the class was used as the search term. For those classes whose namespaces did contain periods, the namespace and name of the class were used as separate search terms. For example, the class System.IO.File would result in a search for “System.IO File .NET blog”, whereas the class System.String would result in a search for “System.String .NET blog”.

More than to just do a popularity contest of the different classes, I wanted to try to determine the best sources of information for each component of the framework. I wanted to see which sites seemed to consistently beat out others as authoritative sources with complete coverage of a given area. In preparation for the transition to .NET 4, I also was interested to see if the features new to .NET 3, and .NET 3.5 received similar coverage to those classes/namespaces that are used in nearly every project created. This final concern will require further testing and analysis before any conclusions can be reached.

What I did find, however, was that (perhaps unsurprisingly considering the methods) those classes/namespaces which one might use more often round out the top 10 result getters:

I was surprised at how strong of a showing the Microsoft.VisualBasic namespace had among all other contenders. Another interesting study would be to look into those sites that are represented in the result count and find the ratio of C# to VB code contained within.

When looking only at classes, we find the following in the top 10:

From here it looks like features from .NET 2.0 (List<T>) and .NET 3.0 (System.Windows.Window) have gotten enough traction to make a big splash. Generics have had quite a long time to catch on so that’s not surprising. Features from WPF making the top 10 already is surprising (considering how much longer classes have had to be written about), and in this case may simply come as a result of the search term that the application used, which would split off Window from System.Windows.Window as its own term alongside the rest.

The top 10 sources for information about .NET would appear to be the following:

The number next to the name of the site indicates how many classes/namespaces for which the site is the top result. Further investigation shows that this might be inaccurate since dotnet247 seems to just index the entire framework and aggregate information from other sites in an automated fashion. Sounds like a great way to make some money from ads, but it might not be the best information source (though is still fairly genius). MSDN blogs definitely provide some serious coverage of the .NET Framework, and likely have excellent information about those classes/namespaces for which they were the top results.

Another interesting statistic that came out of this entirely informal study is that 29% of the .NET Framework (3.5) has less than 5 articles of coverage on the internet. In fact there are 389 classes or namespaces that would appear to have nothing written about them at all (according to the semi-flawed methodology described above).

You can use the download link below to download the complete results that contain all of the raw data that was analyzed, as well a pivot table, and some charts that can be used to explore it to some extent. What interesting information can you find? Has anyone else done a more formal survey of the same?

I was looking over some of the industry news this morning, and spotted this gem from Miguel de Icaza’s blog:

We are also porting our C# compiler to work with Microsoft's Reflection.Emit to enable us to run our C# Interactive Shell in Silverlight applications and to allow .NET developers to embed our compiler in their applications to support C# Eval.

For those that typically shy away from penguins: Miguel is heavily involved in the Mono project. Mono is a project under the wing of Novell to create an EMCA-334/335 compliant implementation of C# and the CLI. The project includes much of the base class library found in the .NET framework, and also includes more project specific classes. The big selling points for me are binary compatibility with existing .NET assemblies, and availability on multiple platforms.

This is certainly exciting technology (just look at the reaction Anders received demoing very similar functionality at PDC2008). Now imagine that same type of experience in the browser (minus the Windows Form popping up out of no where, since no one likes pop-ups anyway). Imagine games that can be scripted in-play, or instantly extensible rich client applications.

Naturally there will be security considerations, and testing considerations, but for now it is what it is: fairly awesome.

I was lurking around the ESB Toolkit forums yesterday, and got involved in an exchange with someone who was hitting the same roadblock to the Itinerary Designer that a lot of people hit: confusion with the model elements and extenders. Upon my first exposure to the Itinerary Designer it took me a week to get over the learning curve of this, and to understand why every send operation seemingly involved two off-ramp shapes instead of one.

Now in the case of that thread, the problem was actually not having a properly formatted SOAP request for the service that was going to be invoked (also a fairly common issue), but getting to the actual issue took cutting through some of the confusing bits of how the itinerary services themselves are implemented, and what they do.

That being said, I took some time last night to write up an article on the different model elements in the itinerary designer, their extenders, and how they can be used to compose an itinerary. You can access the article here: Making Sense of Model Elements and Extenders in the Itinerary Designer

Side note: The article is now part of the brand new (and still under-construction) QuickLearn Technical Library, which will soon contain many more similar articles and links to technical resources for all of the technologies about which QuickLearn teaches.

That’s all for now!

Imagine that you have written an application that will need to invoke a service at some point. You can hard code the service address, you could place it in configuration, you can stick it into an external registry (a la UDDI), or you could come up with some custom method for resolution (e.g., storing endpoint information in a table of a SQL database).

However, Juval Lowy reminds us that we don’t have to re-invent the wheel. He wrote an excellent article in last month’s MSDN magazine about simple discovery in WCF. In the article he provides a simple explanation of what it is, and how it works, and even provides sample classes that can jump-start your development.

You can check out the article here: Foundations - Discover a New WCF with Discovery