|
|
Browse by Tags
All Tags » Computer Related;Computer Related/.Net (RSS)
Sorry, but there are no more tags available to filter with.
-
Many moons ago I discussed the foreach loop . I expand on that post here as I continue my series for the MSDN C# Developer Center . The advantage of a foreach loop over a for loop is the fact that it is unnecessary to know the number of items within the collection when an iteration starts. This avoids iterating off the end of the collection using an index that is not available. As Bill Wagner pointed out in his Custom Iterators article last week, a foreach loop also allows code to iterate over a collection without first loading the collection in entirety into memory. In this article I am going to explore how the foreach statement works under the covers. This sets the stage for a follow on discussion of how the yield statement works. foreach with Arrays Consider the foreach code listing shown in Listing 1: Listing 1: foreach with Arrays int [] array = new int []{1, 2, 3, 4, 5, 6}; foreach ( int item in array) { Console.WriteLine(item); } From this code, the C# compiler creates CIL equivalent of a for loop like this (Listing 2): Listing 2: Compiled Implementation of foreach with Arrays int [] tempArray; int [] array = new int []{1, 2, 3, 4, 5, 6}; tempArray = array; for ( int counter=0; (counter < tempArray.Length); counter++) { readonly int item = tempArray[counter]; Console.WriteLine(item); } Since the collection is an array and indexing the array is fast, the foreach loop implementation relies on support for the Length property and the index operator ([]). However, these two array features are not available on all collections. Many collections do not have a known number of elements and many collection classes do not support retrieving elements by index. foreach with IEnumerable<T> To address this, the foreach loop uses the System.Collections.Generic.IEnumerator<T> . (Given C# 2.0’s generics support, there is very little reason to consider using the non-generic equivalent collections so I will ignore them from this discussion except to say their behavior is almost identical.) IEnumerator<T> is designed to enable the iterator pattern for iterating over collections of elements, rather than the length-index pattern shown in earlier. IEnumerator<T> includes three members. The first is bool MoveNext() . Using this method, we can move from one element within the collection to the next while at the same time detecting when we have enumerated through every item using the Boolean return. The second member, a read-only property called Current, Read More...
|
-
I just noticed today that Charlie Calvert has posted my Chapter 11 - Generics of my Essential C# (Addison-Wesley) book to the C# Developer Center . Thanks Charlie! © Copyright 2005 Mark Michaelis Read More...
|
-
I just noticed today that Charlie Calvert has posted my Chapter 11 - Generics of my Essential C# (Addison-Wesley) book to the C# Developer Center . Noah Coad pointed out to me that this shows up in on the Start Page of Visual Studio if you have C# as you language (and SQL Server didn't change the RSS feed). Thanks Charlie! Read More...
|
-
2000 Microsoft releases beta versions of the .NET Framework. At that time the .NET Framework and the CLR were the core, the foundation of .NET. The CLR was modernizing/popularizing/mainstreaming compile-on-demand, runtime hosted programming. (Sure, Java was doing it, but .NET ushered in a change such that programming languages were to predominantly consist of languages compiled to IL and hosted in a runtime.) The Microsoft development division leaders were those building the framework. (Okay, C# was cool to but not really a revolution... just the perfect language to match the Framework. What made C# spectacular was it's meticulous development and painstaking pursuit of OOP perfection. 2003 Generics are added to early betas of the .NET Framework. Revolutionary... no... just an obvious next step that folks begged for at the language level but Microsoft wisely postponed so that it could be in the Framework. Was there anything revolutionary at the time for the .NET CLR.... not particularly. 2006 Okay, so what is on the horizon in the .NET CLR? I would say LINQ but unlike generics, this is a language implemented feature, not some fundamental change in the CLR. Well, Microsoft is obviously very pregnant with WCF/WF/WPF - known as .NET 3.0. But this didn't emerge from the CLR team and there wasn't any fundamental CLR change needed to support .NET 3.0 development. Phoenix is cool too but not anything that is garnering wide spread adoption. So... what's next for the CLR? As I see it there are three main possibilities: Move to maintenance only mode. Heck, lets focus higher up the stack, we have solved this level in the same way that we "solved" assembler - making it unnecessary detail for the vast majority of developers. Aspect Oriented Programming: The idea has fallen out of vogue but there is still an untapped vision here. .NET scripting/dynamic language support Well, Microsoft's recent hire of John Lam seems to be pretty indicative of where they are investing. And I am excited. If the pain I have endured to learn PowerShell is any indication, Microsoft has lots of work to do in this area. Sure, I love PowerShell but only because it has a .NET object pipe and that it exposes .NET objects on the command line. After that... Yuck! Anyway, imagine a world in which the CLR changes to truly embrace and conquer the dichotomy between strongly typed languages and scripting languages . Imagine scripting languages that supported intellisense. Imagine writing C# code on the command Read More...
|
-
2000 Microsoft releases beta versions of the .NET Framework. At that time the .NET Framework and the CLR were the core, the foundation of .NET. The CLR was modernizing/popularizing/mainstreaming compile-on-demand, runtime hosted programming. (Sure, Java was doing it, but .NET ushered in a change such that programming languages were to predominantly consist of languages compiled to IL and hosted in a runtime.) The Microsoft development division leaders were those building the framework. (Okay, C# was cool to but not really a revolution... just the perfect language to match the Framework. What made C# spectacular was it's meticulous development and painstaking pursuit of OOP perfection. 2003 Generics are added to early betas of the .NET Framework. Revolutionary... no... just an obvious next step that folks begged for at the language level but Microsoft wisely postponed so that it could be in the Framework. Was there anything revolutionary at the time for the .NET CLR.... not particularly. 2006 Okay, so what is on the horizon in the .NET CLR? I would say LINQ but unlike generics, this is a language implemented feature, not some fundamental change in the CLR. Well, Microsoft is obviously very pregnant with WCF/WF/WPF - known as .NET 3.0. But this didn't emerge from the CLR team and there wasn't any fundamental CLR change needed to support .NET 3.0 development. Phoenix is cool too but not anything that is garnering wide spread adoption. So... what's next for the CLR? As I see it there are three main possibilities: Move to maintenance only mode. Heck, lets focus higher up the stack, we have solved this level in the same way that we "solved" assembler - making it unnecessary detail for the vast majority of developers. Attribute based programming. The idea has fallen out of vogue but there is still an untapped vision here. .NET scripting/dynamic language support Well, Microsoft's recent hire of John Lam seems to be pretty indicative of where they are investing. And I am excited. If the pain I have endured to learn PowerShell is any indication, Microsoft has lots of work to do in this area. Sure, I love PowerShell but only because it has a .NET object pipe and that it exposes .NET objects on the command line. After that... Yuck! Anyway, imagine a world in which the CLR changes to truly embrace and conquer the dichotomy between strongly typed languages and scripting languages . Imagine scripting languages that supported intellisense. Imagine writing C# code on the command Read More...
|
-
I came across a PowerShell script for creating TFS Work Items from Alan Stevens today. There are a couple more thougts and ideas I would add. Here is the output from my interactive PowerShell session (notice that I start with Alan's code to load the TFS assemblies. However, I begin to vary shortly after that. >$key = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\VisualStudio\8.0 >$dir = [string] (Get-ItemProperty $key.InstallDir)$dir += "PrivateAssemblies\" >$lib = $dir + "Microsoft.TeamFoundation.WorkItemTracking.Client.dll"[Reflection.Assembly]::LoadFrom($lib)>$lib = $dir + "Microsoft.TeamFoundation.Client.dll"[Reflection.Assembly]::LoadFrom ($lib) >"Please enter your Team Foundation Server Name:"$server = [Console]::ReadLine()$server = $server.Trim() >$server="tfs" >$NetCredentials=new-object System.Net.NetworkCredential ("Mark", "P@ssw0rd", "Michaelis") >$tfs=new-object Microsoft.TeamFoundation.Client.TeamFoundationServer($server, $NetCredentials) > To begin with I instantiate the TeamFoundationServer object rather than calling GetService() . This is because I want to change the network credentials that I use to connect to the server (see Buck Hodges post on this ). >$type = [Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore] >$workItemStore = [Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore] $ tfs .GetService($type) >$bug=$store.Projects["MSF for CMMI"].WorkItemTypes["Bug"].NewWorkItem() >$bug.Title="The application isn't working" >$bug.Save() Exception calling "Save" with "0" argument(s): "TF26201: This work item has unsupported fields, or user does not have permissions." > The next problem was that saving the bug results in an error. I am pretty sure it is not permissions since I specified the credentials explicitly. This leaves the unsupported fields option (whatever that means). I check the Fields property and determine what the required fields are. After setting these fields I am able to store the bug. A non-zero ID and the revision number are just a few properties that verify the work item was successfully stored. >$bug.Fields | where {$_.IsRequired -and (-not $_.IsValid)} | ft Name Name ---- Symptom Steps To Reproduce >$bug.Fields["Symptom"].Value="Headache" >$bug.Fields["Steps To Reproduce"].Value="Drink too much alcohol" >$bud.Save() >$bug.Id 183 >$store.GetWorkItem($bug.Id) Id : 183 Uri : vstfs:///WorkItemTracking/WorkItem/183 Revision : 1 Revisions : {Microsoft.TeamFoundation.WorkItemTracking.Client.Revision} Read More...
|
-
In an eWeek article titled, "Microsoft Tools Team Readies 'Rosario'" , Sam Guckenheimer, group product planner for Visual Studio Team System, is interviewed on future Team System developments and time frames. For a high level overview of the Team System plan along with some time frames, it is a good read. © Copyright 2005 Mark Michaelis Read More...
|
-
Check out this .NET 3.0 (WinFX) road show coming to the US. The current list of cities is Los Angeles, Mountain View, Downers Grove (just outside of Chicago), Reston, New York, and Waltham. According to the schedule , the majority of content will be on Windows Communication Foundation (WCF) with all presentation handled by gurus from IDesign . © Copyright 2005 Mark Michaelis Read More...
|
-
I have been working with Microsft’s eBuisiness Suite and Oracle adapter (the one they purchased from iWay) for several months now and I would describe the experience as disappointing at best. The core problem is that the adapter is built using the ODBC adapter. This is a critical problem, however, because the vast majority of the Oracle eBusiness Suite Adapter APIs use REC TYPE parameters and ODBC doesn’t support REC TYPE parameters. You can’t even generate the schema for these APIs. In other words, Microsoft’s adapter for connecting to eBusiness Suite is incompatible with Oracle’s approach for putting data into eBusiness Suite. For all practical purposes, this renders the adapter useless for the vast majority of scenarios. In fact, the eBusiness Suite adapter, therefore, has no additional functionality beyond that provided by the Oracle adapter (and I am not exaggerating). By the way, the Oracle adapter is also built using ODBC and, therefore, it suffers from the exact same problem. What to do? The workarounds are by no means attractive but there are some: Take the Oracle API that you wish to call, the one that uses REC TYPE parameters, and wrap it in a custom API that flattens out the REC TYPE parameters into simple parameters instead. The result is very long parameter lists, but at least you can now call the APIs. Define a staging table into which data is pushed and then call a custom PL/SQL procedure that sends the data into the Oracle APIs. This forces you to use an orchestration but it will likely work. Take the Oracle BEPL engine, what Oracle offers to compete with BizTalk, and call into it using the SOAP adapter. (Personally, I haven’t tried this but it was Oracle’s proposed solution when I encountered this issue.) © Copyright 2005 Mark Michaelis Read More...
|
|
|
|