Antimail : .NET

.NET Framework source code - public

AdiOltean — Wed, 03 Oct 2007 22:12:20 GMT

I sure hope that you will appreciate this - the .NET 3.5 source code will be publicly released. Initially, we will see .NET BCL, ASP.NET, Windows Forms, ADO.NET, XML and WPF. Later, more libraries will be added (WCF - yes!), LINQ and Workflow.

[RO] Seminar - Storage si programare distribuita

AdiOltean — Thu, 03 May 2007 20:57:00 GMT

Florin Lazar, Todi Pruteanu si cu mine am demarat in cursul acestei saptamani un seminar tehnic pe teme de storage in Vista si programare distribuita in WCF. Mai multe detalii aici: http://reg.studentclub.ro.

Pana acum seminariile din Bucuresti si Cluj au avut un raspuns fantastic! Daca aveti opinii, impresii (pozitive sau negative) m-as bucura sa le puneti in sectiunea de comentarii...

Si nu in ultimul rand, multumiri lui Todi si Microsoft Romania pentru organizarea acestui eveniment.

WS-Management? Already here in Vista!

AdiOltean — Sat, 19 Aug 2006 08:19:00 GMT

WS-Management is a new web services-based management protocol. It's SOAP-based of course, and it is compatible with the rest of the specifications in the WS-* Web Service stack, like WS-Transfer, WS-Enumeration, WS-Addressing.

WS-Management is enabled in Vista (and Longhorn Server) in several ways.

On the client side, you have a standard library (called WinRM) which can "consume" other WS-Management enabled interfaces. You could also use Indigo, or other web service frameworks to access the same services as well. Finally, there is a command-line tool also named WINRM which can be used to communicate with WS-Management enabled servers.
On the server side, any WMI class can be made remotely accessible through WS-Management.

Security

WS-Management is securely enabled on Vista machines. To find out the security configuration of your machine (both for client and server) you can use WS-Management itself like in the command below:

C:\>winrm get winrm/config
Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 20
    MaxProviderRequests = 25
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = false
            Digest = true
            Kerberos = true
            Negotiate = true
        DefaultPorts
            HTTP = 80
            HTTPS = 443
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 100
        EnumerationTimeoutms = 60000
        MaxConnections = 5
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
        DefaultPorts
            HTTP = 80
            HTTPS = 443
        IPv4Filter = *
        IPv6Filter = *
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 900000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 28800000
        MaxProcessesPerShell = 5
        MaxMemoryPerShellMB = 80
        MaxShellsPerUser = 2

By default, WS-Management is not enabled for remote access, Windows authentication is used by default on local acceess, and encryption is turned on.

You can enable remote access by typing:

C:\>winrm quickconfig
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Set the WinRM service type to delayed auto start.
Start the WinRM service.
Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.

Make these changes [y/n]? y

WinRM has been updated for remote management.

WinRM service type changed successfully.
WinRM service started.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.

The output above already illustrates one main advantages of web services - their flexibility with respect to firewall access. Say that you want to enable your current machine to accept incoming WS-Management SOAP requests through the port 80 (as HTTP requests). Then, all you need to do is opening port 80 and that's it! Also, NAT is not a problem, of course.

Try this type of exercise when enabling DCOM through the firewall, and you'll have nightmares. This can get really complicated. Furthermore, DCOM doesn't really work in NAT environments.

A simple example

At this point, you have a secure web service enabled on your machine, that you can then use to perform regular management queries, in WMI style. Let's get some information about a Windows service, like the status of the Spooler service.

Note that I am doing a remote query - basically contacting the machine AOLTEAN-D2, through an internal, WS-Management web service interface:

C:\>winrm get wmicimv2/Win32_Service?Name=spooler -r:aoltean-d2
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = Print Spooler
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = Loads files to memory for later printing
    DesktopInteract = true
    DisplayName = Print Spooler
    ErrorControl = Normal
    ExitCode = 0
    InstallDate = null
    Name = spooler
    PathName = C:\Windows\System32\spoolsv.exe
    ProcessId = 1472
    ServiceSpecificExitCode = 0
    ServiceType = Own Process
    Started = true
    StartMode = Auto
    StartName = LocalSystem
    State = Running
    Status = OK
    SystemCreationClassName = Win32_ComputerSystem
    SystemName = AOLTEAN-D2
    TagId = 0
    WaitHint = 0

Well, it looks like the spooler service is started. We can perform even more complicated queries, such as this one, to find the list of stopped services which are supposed to be started:

C:\trace>winrm enumerate wmicimv2/* -filter:"select * from win32_service where StartMode=\"Auto\" and State = \"Stopped\" " -r:aoltean-d2

XmlFragment
    Win32_Service
        AcceptPause = false
        AcceptStop = false
        Caption = Media Center Service Launcher
        CheckPoint = 0
        CreationClassName = Win32_Service
        Description = Starts Media Center Scheduler and Media Center Receiver services at startup if TV is enabled within Media Center.
        DesktopInteract = false
        DisplayName = Media Center Service Launcher
        ErrorControl = Ignore
        ExitCode = 0
        InstallDate = null
        Name = ehstart
        PathName = C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork
        ProcessId = 0
        ServiceSpecificExitCode = 0
        ServiceType = Share Process
        Started = false
        StartMode = Auto
        StartName = NT AUTHORITY\LocalService
        State = Stopped
        Status = OK
        SystemCreationClassName = Win32_ComputerSystem
        SystemName = AOLTEAN-D2
        TagId = 0
        WaitHint = 0

So, where does WS-Management comes into play? At its roots, WS-Management is a simple management protocol that allows us to operate with resources. WS-Management defines a few operations on these resources:

Get resource properties - this is used by the "winrm get ..." command above. We can see that we interrogate here a resoure (the "spooler" Windows service) and we obtain various properties like PathName, Started, etc.
Enumerate resources - this is a more complex command that allows us to enumerate several resources at once
Set properties on a resource
Create or delete resources
Execute methods on a resource, just like WMI methods.

In some sense, resources can be viewed as "objects" in OOP point of view, and WS-Management defines a simple protocol to manipulate these "objects".

Under the hood

So where do web services come into play? Can we peek into the actual management protocol?

With web services, it is actually easy - all we need to do is to use a network protocol analyzer to sniff the HTTP packets between client and the server. Ultimately, web service interactions are nothing more than exchanging XML packets using HTTP/HTTPS, so analyzing these interactions is no more difficult than analyzing HTTP request/response commands between a browser and a web server.

Let's take the GET command above (winrm get wmicimv2/Win32_Service?Name=spooler -r:aoltean-d2). In our case, the client program attempts to get the properties of a given resource of type "wmicimv2/Win32_Service", identified by the selector "Name=spooler".

Let's dive in. With the network sniffer we obtain the following SOAP request message:

<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">
<s:Header>
    <a:To>http://aoltean-d2:80/wsman</a:To>
    <w:ResourceURI s:mustUnderstand="true">http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service</w:ResourceURI>
    <a:ReplyTo>
      <a:Address s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
    </a:ReplyTo>
    <a:Action s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</a:Action>
    <w:MaxEnvelopeSize s:mustUnderstand="true">153600</w:MaxEnvelopeSize>
    <a:MessageID>uuid:2A553640-AA45-4BE1-8CE8-C3F20BD3C74E</a:MessageID>
    <w:Locale xml:lang="en-US" s:mustUnderstand="false" />
    <w:SelectorSet>
      <w:Selector Name="Name">spooler</w:Selector>
    </w:SelectorSet>
    <w:OperationTimeout>PT60.000S</w:OperationTimeout>
</s:Header>
<s:Body></s:Body>
</s:Envelope>

Correspondingly, the WS-Man response packet looks like this:

<s:Envelope xml:lang="en-US" xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">
<s:Header>
    <a:Action >http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</a:Action>
    <a:MessageID >uuid:3E0BE062-2615-497E-BE6A-2FC7D5B7C9C3</a:MessageID>
    <a:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To>
    <a:RelatesTo >uuid:2A553640-AA45-4BE1-8CE8-C3F20BD3C74E</a:RelatesTo>
</s:Header>
<s:Body>
    <p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:cim="http://schemas.dmtf.org/wbem/wsman/1/base" xsi:type="Win32_Service">
      <p:AcceptPause>false</p:AcceptPause>
      <p:AcceptStop>true</p:AcceptStop>
      <p:Caption>Print Spooler</p:Caption>
      <p:CheckPoint>0</p:CheckPoint>
      <p:CreationClassName>Win32_Service</p:CreationClassName>
      <p:Description>Loads files to memory for later printing</p:Description>
      <p:DesktopInteract>true</p:DesktopInteract>
      <p:DisplayName>Print Spooler</p:DisplayName>
      <p:ErrorControl>Normal</p:ErrorControl>
      <p:ExitCode>0</p:ExitCode>
      <p:InstallDate xsi:nil="true"/>
      <p:Name>spooler</p:Name>
      <p:PathName>C:\Windows\System32\spoolsv.exe</p:PathName>
      <p:ProcessId>1596</p:ProcessId>
      <p:ServiceSpecificExitCode>0</p:ServiceSpecificExitCode>
      <p:ServiceType>Own Process</p:ServiceType>
      <p:Started>true</p:Started>
      <p:StartMode>Auto</p:StartMode>
      <p:StartName>LocalSystem</p:StartName>
      <p:State>Running</p:State>
      <p:Status>OK</p:Status>
      <p:SystemCreationClassName>Win32_ComputerSystem</p:SystemCreationClassName>
      <p:SystemName>AOLTEAN-D2</p:SystemName>
      <p:TagId>0</p:TagId>
      <p:WaitHint>0</p:WaitHint>
    </p:Win32_Service>
</s:Body>
</s:Envelope>

That's it for now. I hope that in a future post I will cover the actual structure of WS-Management messages.

How to do atomic writes in a file

AdiOltean — Thu, 29 Dec 2005 01:51:00 GMT

Let's assume that you want is to write some simple code that writes to a text file. A few assumptions:
1) You need avoid corruptions of any kind.
2) Either all of your writes have to make it to the disk, or none of them.
3) The file is updated serially - no concurrent updates from separate processes are allowed. So only one process writes to the file at a time.
4) No, you cannot use cool new techologies like TxF.

Remember, all you want is just to write to a text file - no fancy code allowed.

What are the possible problems?

Many people mistakenly think that writing to a file is an atomic operation. In other words, this sequence of function calls is not going to cause garbage in your file. Wrong. Can you guess why? (don't peek ahead for the response).

echo This is a string >> TestFile.txt

The problem is that the actual write operation is not atomic. A potential problem is when the machine reboots during actual write. Let's assume that your file write is ultimately causing two disk sectors to be overwritten with data. Let's even assume that each of these sectors is part of a different NTFS clusters, and these two clusters are part of the same TestfFile.txt file. The end of the first sector contains the string "This is" and the beginnning of the second sector "a string". What if one of the corresponding hardware write commands to write these sectors is lost, for example due to a machine reboot? You ended up with only one of these sectors overwritten, but not the other. Corruption!

Now, when the machine reboots, there will be no recovery at the file contents level. This is by design with NTFS, FAT, and in fact with most file systems, irrespective to the operating systems. The vast majority of file systems do not support atomicity in data updates. (That said, note that NTFS does have recovery at the metadata level - in other words, updates concerning file system metadata are always atomic. The NTFS metadata will not become corrupted during a sudden reboot)

The black magic of caching

So in conclusion you might end up with the first sector written, but not with the second sector. Even if you are aware of this problem you might still mistakenly think that the first sector is always written before the second one. In other words, assuming that "this is" is always written before "a string" in the code below:

using System;
using System.IO;

class Test
{
    public static void Main()
    {
        using (StreamWriter sw = new StreamWriter("TestFile.txt"))
        {
            sw.Write("This is");
            sw.Write("a string");
        }
    }
}

This assumption is again wrong. You again can have a rare situation where the machine crashes during your update, and "a string" can end up in the file, but "This is" not saved. Why?

One potential explanation is related with the caching activity. Caching happens at various layers in the storage stack. The .NET Framework performs its own caching in the Write method above. This can interfere with your actual intended order of writes.

So let's ignore .NET and let's present a second example, this time using pure Win32 APIs:

WCHAR wszString1[] = "This is";
WCHAR wszString2[] = "a string";

   fSuccess = WriteFile(hTempFile, wszString1, sizeof(WCHAR) * wcslen(wszString1), &dwBytesWritten, NULL);
   if (!fSuccess)
      ...
   fSuccess = WriteFile(hTempFile, wszString2, sizeof(WCHAR) * wcslen(wszString2), &dwBytesWritten, NULL);

Again, here you can also have caching at the operating system level, in the Cache Manager, where the file contents can be split across several in-memory data blocks. These blocks are not guaranteed to be written in their natural order. For example, the lazy writer thread (a special thread used by Cache Manager that flushes unused pages to disk) can cause an out-of-order flush. There are other considerations that can cause an out-of-order data flush, but in general you need to be aware that any cache layers in your I/O can cause writes to be randomly reordered.

The same reasoning applies to our third example:

echo This is >> TestFile.txt
echo a string >> TestFile.txt

Again, you cannot be sure that the file will not end up corrupted - you can have rare scenarios where the resultant file with contain either the word "This" or the word "string" but not both!

The solution? One idea is to use special write modes like FILE_FLAG_WRITE_THROUGH or FILE_FLAG_NO_BUFFERING, although in these cases you lose the obvious benefit of caching. You have to pass these flags to CreateFile(). Another idea is to manually flush the file contents through the FlushFileBuffers API.

So, how to do atomic writes, then?

From the example above, it looks like it is entirely possible that our writes migth complete partially, even if this case is extremely rare. How we can make sure that these writes are remaining atomic? In other words, my write to this file should either result in the entire write being present in the file, or no write should be present at all. Seems like an impossible problem, but that's not the case.

The solution? Let's remember that metadata changes are atomic. Rename is such a case. So, we can just perform the write to a temporary file, and after we know that the writes are on the disk (completed and flushed) then we can interchange the old file with the new file. Something like the sequence below (I used generic shell commands like copy/ren/del below but in reality you need to call the equivalent Win32 APIs):

Write process (on Foo.txt):
- Step W1: Acquire "write lock" on the existing file. (this is usually part of your app semantics, so you might not need any Win32 APIs here)
- Step W2: Copy the old file in a new temporary file. (copy Foo.txt Foo.Tmp.txt)
- Step W3: Apply the writes to the new file (Foo.Tmp.txt).
- Step W4: Flush all the writes (for example those being remaining in the cache manager).
- Step W5: Rename the old file in an Alternate form (ren Foo.txt Foo.Alt.txt)
- Step W6: Rename the new file into the old file (ren Foo.Tmp.txt Foo.txt)
- Step W7: Delete the old Alternate file (del Foo.Alt.txt)
- Step W8: Release "write lock" on the existing file.

This solution has now another drawback - what if the machine reboots, or your application crashes? You end up either with an additional Tmp or Alt file, or with a missing Foo.txt but with one or two temporary files like Foo.Alt.txt or Foo.Tmp.txt). So you need some sort of recovery process that would transparently "revert" the state of this file to the correct point in time. Here is a potential recovery process:

Recovery from a crash during write (on Foo.txt):
- Step R1: If Foo.txt is missing but we have both Foo.Alt.txt and Foo.Tmp.txt present, then we crashed between Step W5 and Step W6. Retry from Step W6.
- Step R2: If Foo.txt is present but Foo.Tmp.txt is also present, then we crashed before Step W5. Delete the Foo.Tmp.txt file.
- Step R3: If Foo.txt is present but Foo.Alt.txt is also present, then we crashed between Step W6 and Step W7. Delete the Foo.Alt.txt file.

More and more problems...

The sequence of operations above looks good, but we are not done yet. Why? Sometimes shell operations like Delete, Rename can fail for various reasons.

For example, it might just happen that an antivirus or content indexing application randomly scans the whole file system once in a while. So, potentially, the file Foo.Tmp.txt will be opened for a short period which will cause either the step W7 or R1..R3 to fail due to the failed delete. And, not only that, but also Rename can fail if the old file already exists, and someone has an open handle on it. So even the steps W2 or W5 can fail too...

The fix would be to always use unique temporary file names. In addition, during the recovery process, we will want to clean up all the "garbage" from previous temporary file leftovers. So, instead of files like Foo.Tmp.txt or Foo.Alt.txt, we should use Foo.TmpNNNN.txt and Foo.AltNNNN.txt, together with a smart algorithm to clean up the remaining "garbage" during recovery. Here is the overall algorithm:

Write process (on Foo.txt):
- Step W1: Acquire "write lock" on the existing file.
- Step W2: Copy the old file in a new unique temporary file. (copy Foo.txt Foo.TmpNNNN.txt)
- Step W3: Apply the writes to the new file (Foo.TmpNNNN.txt).
- Step W4: Flush all the writes (for example those being remaining in the cache manager).
- Step W5: Rename the old file in a new unique Alternate form (ren Foo.txt Foo.AltNNNN.txt)
- Step W6: Rename the new file into the old file (ren Foo.TmpNNNN.txt Foo.txt)
- Step W7: Delete the old Alternate file (del Foo.AltNNNN.txt). If this fails, simply ignore. The file will be deleted later during the next recovery.
- Step W8: Release "write lock" on the existing file.

Recovery from a crash during write (on Foo.txt):
- Step R1: If Foo.txt is missing but we have both Foo.AltNNNN.txt and Foo.TmpNNNN.txt present, then we crashed between Step W5 and Step W6. Retry from Step W6.
- Step R2: If Foo.txt is present but Foo.TmpNNNN.txt is also present, then we crashed before Step W5. Try to delete all Foo.TmpNNNN.txt files and ignore failures.
- Step R3: If Foo.txt is present but Foo.AltNNNN.txt is also present, then we crashed between Step W6 and Step W7. Try to delete all Foo.AltNNNN.txt files and ignore failures.

That's it!

Did you know that MySpace.com runs ASP.NET 2.0 on x64?

AdiOltean — Wed, 07 Dec 2005 10:21:00 GMT

I found this quote interesting:

The Internet Information Services 6.0 Web server featured in the OS has been enhanced with 64-bit support. This provides access to more memory and scalability for applications, Goldfarb said. "In high-performance scenarios, it's very, very important."

64-bit computing translates to needing fewer servers, requiring less management and lower licensing costs, Goldfarb said. Also included in Internet Information Services is a Web-security configuration wizard for setting security levels in Web applications.

Support for 64 bits in ASP.Net 2.0, meanwhile, has enabled MySpace.com, which runs a high-volume social networking portal, to consolidate operations from approximately 100 multiprocessor systems to 33 of these systems, said Aber Whitcomb, CTO at MySpace.com. The company has been using ASP.Net 2.0 with an earlier version of Windows.

"With 64-bit hardware, you can increase your memory footprint from 4GB on a single server to in our case, up to 16GB, but you can go a lot further than that," Whitcomb said. MySpace.com describes itself as the third most trafficked site on the Internet, with 11.5 billion page views in October alone.

SSE - an RSS extension for two-way synchronization

AdiOltean — Mon, 21 Nov 2005 23:25:00 GMT

Ray Ozzie mentioned an interesting variation of the RSS protocol. RSS is essentially a one-way synchronization protocol. What it would take to change the RSS standard in a very minimal way, such that it will work for two-way replication. A simple idea, with very deep implications. The new RSS is now called SSE: Simple Sharing Extensions. You need relatively little programming work to implement it.

In the preliminary discussions, Dave Winer immediately pointed out another interesting extension, for something he wanted for some time: how to cross-update OPML files.

Here is the SSE draft and a FAQ.

Singularity - a new research OS from Microsoft

AdiOltean — Sun, 06 Nov 2005 20:40:00 GMT

Here it is: http://research.microsoft.com/os/singularity/

There are several interesting ideas in this new operating system. It's not just an "OS written in managed code". There are a new set of techniques in modern software development: contracts, verifiability and static analysis. Singularity combines them in an elegant framework, and applies these notions in the operating system development. New areas that benefit from these new techniques are, for example, writing device drivers.

P.S. There is also a technical report here - a must-read for anyone interested in operating system research.

.NET FX 2.0 available for download

AdiOltean — Fri, 28 Oct 2005 23:42:00 GMT

http://msdn.microsoft.com/netframework/downloads/updates/default.aspx

How big is Hotmail?

AdiOltean — Fri, 23 Sep 2005 08:41:00 GMT

Huge. Here is some data from a PDC Hotmail presentation:

~200 million active users

3.3 billion inbound emails a day

1.5 billion blocked at the router
1.0 billion deleted as spam (never hits the user's mailbox)
0.5 billion sent to the junk folder

Over 100 million messages sent a day

80 - 100 milllion logins per day

5000 peak logins per second

But the most interesting part in this PPT is the new FrontEnd design. It is based on the Atlas framework. The client code (Javascript - in the browser) is able to call into front-end components (written in C#). The requirements for the protocol are interesting: minimize the data on wire, purely asynchronous processing at the server side. All this combined with an OOP component framework.

LINQ: a post-modern revolution in software development

AdiOltean — Wed, 14 Sep 2005 09:09:00 GMT

Arguably, LINQ (Language Integrated Query) will be the next major revolution in programming languages. LINQ is a language-independent, platform-independent technology that solves an old problem - data queries in your code- in a very elegant way. First, it brings a highly declarative approach in performing queries and data-bindings. Second, it is strongly typed at compile time. Third, it is easily extensible for any type of data stores (databases, XML documents, or anything else).

I personally view LINQ as the SQL language of the XXI century. I won't be surprised to see the same idea propagated in any modern strongly-typed programming language (for example Java).

To illustrate its full power, we will present a simple LINQ query, in C# 3.0:

Northwind db = new Northwind("c:\\northwind\\northwnd.mdf");

var q =
      from c in db.Customers
      where c.City == "London"
      select c;

foreach (var cust in q)
Console.WriteLine("id = {0}, City = {1}",cust.CustomerID, cust.City);

Everything you see here is strongly typed. All the data bindings (the Customer data structure to the Customer table) are done at compile time. Not only that the generated code is extremely fast, but the language integration is natural.

Under the cover, there is a lot going on. First of all, the "Customers" property above is inferred at compile time as being the Customers table from the Northwind database. The associated fields (CustomerID, City) are inferred as columns in the Customers database.

All the type assignments are done at compile time, including the type binding for every field. For example, don't be fooled by the "var q" declaration above. It is not a type-less variable like in JScript. Rather, the "q" variable has a well-defined type: a list/array of structures identifying query records, each of them being a well-defined structure, with strongly-typed fields (whose typeis inferred from the database or XML schema).

The same technology can be extended efficiently to do declarative data manipulation directly in the query. For example, the following code:

var q =
      from c in db.Customers, o in db.Orders
      where c.CustomerId == o.CustomerID && c.City == "London"
      select o;

will be used to construct under the covers a true SQL Join statement, binding the Customers and Orders tables. It's that simple!

I think that programmers that are doing database programming, or XML processing will love it.

More links on LINQ

- LINQ home page on MSDN. This is the most comprehensive page.
- LINQ project overview.
- LINQ samples in C#.
- LINQ downloadable preview (compiler, samples, and more!) here.

ECMA standards now aligned with the new Whidbey, C# 2.0

AdiOltean — Wed, 03 Aug 2005 22:12:00 GMT

Few days ago, ECMA approved the third edition of the C# and CLI standards. This aligns the language and runtime to the latest enhancements in Whidbey, like generics, nullable types, etc.

The effects of this standard approval are almost immediate - Miguel de Icaza mentioned in his blog that Mono will be soon aligned too.

Interview with Anders Heljsberg on the next version of C#

AdiOltean — Fri, 15 Jul 2005 22:59:00 GMT

(No, I didn't mean Whidbey. I meant C# 3.0)

The interview appeared on Microsoft Watch. Here is the link.

I like the new approach on dynamic/inferred typing for database queries. The problem is this: whenever you have to mix highly declarative languages like SQL with imperative, strong-typed language environments like C#, then you will always end up with some amount of boiler-plate code. And you don't want too much boiler-plate code...

P.S. On the same subject, if you missed that, there is also an older interview on Channel 9 around C# 3.0.

Managed Speech APIs and other cool utilities...

AdiOltean — Thu, 14 Jul 2005 01:33:00 GMT

New speech-related utilities here. A new addition is BuildAppLex:

BuildAppLex Speech Utility for Microsoft Speech Technologies
BuildAppLex.exe is a command-line tool that allows you to create an Application Lexicon, using the Speech API. It takes one required command-line argument: a text file containing a list of words and their corresponding pronunciations.

Also, a while back, Robert Brown mentioned that a new managed interface for the Speech APIs is now available here. In a few lines of C# code, you can do either speech recognition or speech synthesis. (To play with the API, you also need to install a regognition engine - for example the one from the latest SAPI SDK)

Atlas: Seamless AJAX programming

AdiOltean — Tue, 28 Jun 2005 23:24:00 GMT

Scott Guthrie has a great blog entry on several platform enhancements, code-name Atlas, that will address AJAX-style programming. At the same time, Charles Fitzgerald presented the Atlas technologies.

Microsoft will release a technology preview of Atlas at the PDC, which will be held in Los Angeles.

This is very nice - it makes complete sense to have AJAX-style development facilities built in the development platform. You should not be required to write and debug complex AJAX code.

Welcome Max

AdiOltean — Tue, 14 Jun 2005 10:09:00 GMT

Max Feingold just started a blog!

In the past, I knew him as one of the good COM experts around. Incidentally, one of my previous posts describes an intricate COM+ setup issue on which Max helped me to see the light... :-)