Microsoft All-In-One Code Framework is updated on 2010-09-06.
Download address: http://1code.codeplex.com/releases/view/51868
If it’s the first time that you hear about Microsoft All-In-One Code Framework, please read the introduction on our homepage http://1code.codeplex.com/, and this Port25 article http://port25.technet.com/archive/2010/01/18/the-all-in-one-code-framework.aspx.
How to write a Windows Shell extension using managed code (C#/VB.NET) is an extremely host question in MSDN forums and newsgroups. Prior to .NET Framework 4, the development of in-process shell extensions using managed code is not officially supported because of the CLR limitation allowing only one .NET runtime per process. Jesse Kaplan, one of the CLR program managers, explains it in this MSDN forum thread: http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e.
In .NET 4, with the ability to have multiple runtimes in process with any other runtime, Microsoft can now offer general support for writing managed shell extensions—even those that run in-process with arbitrary applications on the machine. This article introduces the in-process side-by-side feature in detail. However, please note that you still cannot write shell extensions using any version earlier than .NET Framework 4 because those versions of the runtime do not load in-process with one another and will cause failures in many cases.
The documents explains the theory. How can I on earth write a managed shell extension?
If you search on the internet, you would find that there’s almost zero .NET 4 shell extension samples. The few .NET 2 shell extension samples (not supported because of the above reason) have more or less some defects, e.g. not being able to load in x64 environment. In order to meet customers’ want, All-In-One Code Framework would like to fill in the blank. The project group has planned a series of .NET 4 managed Shell extension code samples for Context Menu Handler, Property Sheet Handler, Icon handler, Data handler, Drop handler, Drag-and-drop handler, Thumbnail Handler, Icon Handler, Icon Overlay Handler, and so on. In this release of All-In-One Code Framework, we provide the first batch of samples. You can find them in the Visual Studio 2010 folder. More will be provided in the future releases. Please stay tuned.
Shell context menu handler (C++)
Shell context menu handler (C#)
Shell context menu handler (VB.NET)
Shell property sheet handler (C++)
CSAzureXbap, VBAzureXbapIn a typical cloud development scenario, you host a web service in the cloud, distribute a client application from the cloud, and consume the service from the client application.This sample demonstrates the above typical scenario, where the client application is a XBAP application, and the cloud service is a WCF service hosted in a Windows Azure Web Role.
CSEFPOCOChangeTracking, VBEFPOCOChangeTrackingThese two samples demonstrate how to update POCO entity properties and relationships with and without Change Tracking proxies. You can read more about Tracking Changes in POCO Entities here.
CSSL4WCFNetTcp and VBSL4WCFNetTcpSilverlight4 support netTcp transport binding element, which gives us a new choice to implement duplex WCF. In this sample, we create a simple weather report subscription application to demonstrate how to consume netTcp WCF in Silverlight.
CppCheckProcessBitness, CSCheckProcessBitness, VBCheckProcessBitnessA frequently asked question in MSDN forums is that, given a process, how can I programmatically detect if it’s running in the 32bit mode or 64bit mode. These code samples answer it. The code logic is that 1. All processes running under 32bit OS are 32bit.2. On 64bit OS, 32bit process can only run under Wow64. 1) if the process is running under Wow64, it's a 32bit process. 2) if the process is not running under Wow64, it's a 64bit process.
Hi, just a small comment the last entry in your rss feed is for may... all the new posts don't seem to appear.
Um, I'm given to understand that writing shell extensions in .NET still isn't supported, and that the consequences of doing it anyway have merely been downgraded from "extensions using different .NET runtimes will break" to "loading .NET runtimes into every app that embeds the shell might make your computer grind to a halt much more quickly than it ordinarily would". Oh, plus the contractual requirements regarding reference counts that can't be satisfied with automatic garbage collection ...
In fact, Raymond Chen says so on his blog: <blogs.msdn.com/.../10396079.aspx>. Oh, hmm, you even recanted yourselves: <blogs.msdn.com/.../is-it-officially-supported-to-write-windows-shell-extension-using-net-4-today.aspx>.