Differences from CodePlex

Differences from CodePlex and Porting Kit Releases

1. There is no such thing as a Porting Kit anymore
   The Porting Kit (PK) was a hold over from when the .NET Micro Framework was a closed source product. Once it was Open Sourced and placed on CodePlex there wasn't a real need to have a Porting Kit but it was still produced. The PK had the advantage of a single, albeit large, download that contained all the files so you could just download the PK run the installer and get going. Due to a number of historical reasons the build infrastructure and build commands weren't identical to what was in the full CodePlex source tree. This led to a good bit of confusion and frustration as it wasn't always clear which version of the code base someone had when they were asking for help. With the move to GitHub there's no reason left to keep producing the PK. GitHub has the ability to clone a repository where it downloads a compressed copy of the code, which it then expands out to your working directory. You can also just download a zip of the tree to get all the code. Removing the PK also means everything uses an identical and consistent build thereby eliminating subtle problems and headaches associated with slightly different build infrastructures.

2. The legacy targets and platforms are not included in GitHub
   We have attempted to eliminate all legacy code that isn't targeting current modern hardware. This does not mean that NETMF can't or won't run on these devices. The NETMF team is committed to maintaining a CPU neutral and portable run-time. However, we don't see much value in retaining code for hardware platforms that are no longer available or listed as "not to be used in new designs" by their manufacturers. If there is interest in bringing any of the removed targets or solutions back we are always open to pull requests. However, we can't test every port on every board or CPU.

3. Previous SDK versions are no longer included
   In the past the SDK MSI included multiple framework versions, this increased the complexity of generating the setup as well as increased the size of the repository as the binaries were checked in for all the previous versions going back to v3.0. One of the advantages of splitting the Visual Studio support out of the SDK installer is that we don't need to pack all the versions together. If you only want the latest version you just install that SDK only. You can still install the new SDK side by side with old version and everything should still work. (No guarantees on a pre-release build of course, but if you find bugs or problems here then please file a bug as it is supposed to work seamlessly)

4. Building the SDK is much simpler
   While we don't expect device vendors to build the SDK unless working with pre-release code we've made building the SDK a simple command build_sdk.cmd. When we run official automated builds there are a few parameters applied, but for non-production builds no arguments are needed.

5. Legacy kernel mode USB drivers are no longer provided
   Support for the legacy driver is officially deprecated as of v4.4. While the debugger and MFDeploy will still see and support devices with the legacy driver, future major versions of the .NET Micro Framework and tools will not. See the sample in the MCBSTM32F400 solution for a USB configuration that does not require a driver or custom INF. (e.g. no WHQL signatures and driver installers needed! 😃 ) or the [USB driver configuration](USB Driver Configuration) Wiki article