.Net Micro Framework SDK 2.5 釋出

3月6日，微軟.Net Micro Framework SDK 2.5 在MSDN上提供了下載下傳連結（ http://www.microsoft.com/downloads/details.aspx?familyid=EB0EF2A6-03E2-402C-89A4-A636BD0080C5&displaylang=en

）。

安裝最新版本的SDK之前，需要解除安裝掉原來的老版本。

安裝後，我初步看了一下，好像大的改動不多，以前我編寫的MF程式都可以正常運作，至于新功能嘛，其釋出檔案上如是說：

===============================================================================

What new in V2.5?

The V2.5 release includes a optionally installed beta release of the assemblies

for the .NET managed Devices Profile for Web Services (DPWS) stack.

Samples demonstrating how to create or use: 

 - hosted services on devices

 - clients on the desktop and on devices

 - Discovery and Eventing

The .NET Micro Framework DPWS stack requires TCP/IP (Sockets) to function.

Device firmware must be developed with the V2.5 version

of the .NET Micro Framework Porting Kit in order to include

the .NET Micro Framework TCP/IP network stack.

Issues

Issue:

Calling SocketConnect on a second set of sockets causes an exception in the

Emulator.

Resolution:

This is a known issue and will be fixed in a subsequent release.

If a DispatchTimer is declared on the stack of a method, and the method

returns, the DispatchTimer object may be garbage collected, even though

still enabled.

Declare DispatchTimer objects as globals.

The EnableDynamicDNS method of the

Microsoft.SPOT.Net.NetworkInformation.NetworkInterface class is not

implemented in the .NET Micro Framework TCP/IP stack, and will cause

an exception if called from a managed application.

Dynamic DNS address assignment is accomplished by enabling DHCP after

setting the static DNS address to 0.0.0.0.

For example, the following code will cause DHCP to assign the DNS addresses:

        // set DNS to 0 so DHCP DNS is used
        string[] dns = new string[] { "0.0.0.0", "0.0.0.0" };
        interfaces[0].EnableStaticDns(dns);
        // Enable DHCP
        interfaces[0].EnableDhcp();           

When changing the network configuration in a managed application, it is

necessary to follow these guidelines:

   1) When changing the network configuration from DHCP-enabled to static,

      it is necessary to update the static DNS addresses

   2) When changing the network configuration from static to DHCP-enabled,

      it is necessary to change the two DNS addresses to 0.0.0.0 so that DHCP

      will update the DNS addresses. If you want to then replace the

      DNS addresses provided by DHCP, call EnableStaticDns with the two

      replacement addresses.

DHCP behavior on the .NET Micro Framework differs from DHCP on the desktop.

The .NET Micro Framework makes three attempts within 7 seconds to obtain

a DHCP lease at bootup. If the DHCP server is not found within this time frame,

the framework ceases searching for a DHCP server. This is the intended behavior

that application developers should be aware of since it differs from all

versions of the Windows operating system.

Because of the finite number of attempts to find the DHCP server, your device

may not obtain a DHCP lease if it is not properly connected to the network at

boot time.

Connect the device to the network before booting.

Deploying multiple times to the iMXS platform in Visual Studio can cause

deployment errors.

Resolution

A solution to this problem is being investigated for version 3.0. Currently,

there are multiple workarounds available. Here are a few.

1.  Press F5.

2.  Restart the device.

3.  Check to see if you have multiple devices with the same name.

4.  Restart Visual Studio.

There is a known issue when debugging a .NET Micro Framework V2.0 SP1

application running on the V2.5 firmware. This typically happens when loading

a resource.  This issue will be resolved in a subsequent release.

Use the V2.5 SDK for all application development.

Dns.GetHostEntry with an empty input string ("") will return the local

IP address

This is by design and expected behavior.

After deploying an application from Visual Studio, the device is rebooted. In

some cases, DHCP can cause Visual Studio to time out while waiting for a

reconnect, preventing Visual Studio from debugging the device.

Add a registry key and value to increase the amount of time Visual Studio will

wait for a reconnect. The default of 5 seconds may be extended by creating the

following key and setting its timeout, retries, and override values:

HKCurrentUser/

  Software/

    Microsoft/

      .NetMicroFramework/

        NonVersionSpecific/

          Timing/

            AnyDevice

'timeout' (DWORD): milliseconds to wait before retrying

    (constrained to 50 < timeout < 60000)

'retries' (DWORD): count of retries to attempt

    (constrained to 1 < retries < 1000)

'override' (DWORD): if present and non-zero, ignore constraints above,

    and attempt to apply any valid DWORD values.

If any one of the values provided is out of bounds or malformed, it is

silently ignored and the default values remain in effect. However, the others

that are valid are still be applied.

The default values are as in v2 SP1: timeout = 100 for platforms that support

a soft reboot, 1000 otherwise; retries = 10.

Calling a NetworkInterface method that changes the IP address will invalidate

any bound sockets.

If running as a server, re-bind any open sockets after any IP address change.

進一步的詳情，等我研究後在說。