Windows Server Core is a subset of Windows Server 2008 dedicated to a specific mission. If you want to setup a DNS Server, a File Server, or a Media Server you don't need to full blown Windows Server machine. You don't need the Windows Shell, You don't need sound capabilities, you don't need ... you have got the idea.
Using a subset of Windows Server 2008 results a smaller memory footprint, faster server and smaller attack service. For example comparing to the full Windows Server 2008, only 40 percents of the patches were needed for the Server Core.
The first release of Server Core was a good choice for all the predefined roles that came with it, but was not suitable as a target machine for many of the current projects in the industry. You can argue that there are many server applications that don't need UI and that may benefit from running on such installation and I'd agree, but there was not managed code support. You could use IIS but with no ASP.NET applications.
Server Core 2008 R2 will support a subset of the .NET framework as well as the ability to host an ASP.NET application.
Here are some facts about the product:
- There will be only an x64 bit version, however WoW64 is an option for 32bit compatibility, so it is better to target x64.
- Since we will have the .NET framework we will have the PowerShell
- We will have a subset of .NET 2.0, 3.0, 3.5.
- We will be able to install .NET 2.0 and/or .NET 3.x with WF, WCF and LINQ support
- No WinForm and no WPF, actually nothing that related to UI and User Experience (MMC, Sound, Etc.)
- Remote debugging (Msvsmon.exe) works
- You can manage IIS and ASP.NET remotely (no MMC on Server Core)
You can think about managed development for Server Core as another target platform such as .NET CF, XNA, Silverlight and so forth. It is .NET but you should know the differences, what is in there, how to install, how to configure, how to debug and what is there that you can use.
One of the main problems of COM interop is the need to distribute the interop libraries with your application. If your application footprint is 50K, and you use only one API from the Office interop library, you will need to have the 1.2MB PIA library installed with your executable. The situation is even worth because the only way to install the Office PIA is by installing the Office redistribution pack which its footprint is over 6MB. To fix this situation Microsoft has developed a new feature in C# 4.0, The NoPIA. No Primary Interop Assembly means that you can use a COM interop without distributing and loading the Interop assembly that contains the COM Types definitions (COM Interfaces, structs). The feature is triggered by the /link compiler option or by a new property setting in VS2010. What is actually happen is that the compiler extracts the type information in compile time and embeds it in the calling assembly. To optimize the footprint, the compiler embeda only the interfaces and methods that are actually in use. When you ildasm the result you see a namespace that contains those type definitions. If you look at the interface definition, you see only the methods that are in use and a bunch of void gap##() methods. The gap method helps the CLR when it builds the vtable of the interface. Since we only have few methods from the interface the CLR has to know how many entries to skip between those methods. Using embedded types may lead to type collision if there we have more than one assembly that uses the same interop assembly. To resolve the problem we need to add a GUID attribute to the type. There are other attribute and conditions that should be set to have Type Equivalency. For more information read the lecturer blog post:
The day started with the announcement of a new "Operating System" for the cloud - Windows Azure. Windows Azure is a foundation to build scalable and robust applications and services that will be deployed to Microsoft servers (the "Cloud"). Windows Azure also support a .NET Services such as SQL services, Exchange services and so forth. It seems that .NET MyServices (Hailstorm) is back with a more mature design and implementation.
The only problem that I find in this model is that I think that many companies will not put their core business data and functionality in Microsoft hands. You can argue that companies put their money in a bank, and that they trust this bank, but at least they can choose the bank and can move to another bank if they want to. Microsoft wants to move from selling Windows servers to selling services and to make the paradigm shift to "Software + Services". As I see it, they should sell the "Cloud O/S" to other independent companies that will use the technology to host their application as the case today with hosting ASP.NET applications.
For now Windows Azure appears to be a good solution for SMB companies that want to cut the IT and development costs.