Develop Reference

Creating windows-7 library using c#

Windows-7 introduced a concept of virtual folder, called 'Libraries'.
I am working on implementing a Library with my custom action. The constraint is that, I have to stick to .NET version 2 for this :(
While looking around, I didn't find any native (c/C++) API for doing this. I am planning to use Interop (p-Invoke) to make a library once I get native APIs.
Could any one point to a link or documentation which might help. If somehow I can do this directly from c# (with .NET v2), that would be great.
Thank you,
John

The MSDN topics that seem most pertinent are:
Inside Windows 7:Introducing Libraries
Windows Libraries
Windows 7 Libraries: Developer Resources
The library features are exposed through COM so there's no need for P/invoke.
However, since libraries only exist in Windows 7, and since Windows 7 has .net 3.5 as part of the OS, I would recommend that you put this part of your application in a .net 3.5 assembly. In fact the API CodePack assembly already does this for you.
Of course, since the CodePack is also delivered as source you could extract the necessary parts from there and do what is needed in order to build it against .net 2.0.

The concept of "virtual folder" exists already before Windows 7 and has AFAIK just been "refined"... you write you want to do this with your own custom handler...
IF you want to implement such a "virtual folder" and integrate it into Windows so that other applications can use it as a "virtual folder" then:
To implement and install a "shell extension" (which basically are a bunch of COM interfaces):
Remark: If the system you are running on doesn't have .NET 4 then Microsoft recommended NOT to use .NET for this because of the inherent restriction with the older versions that one process can't run multiple framework versions at the same time. Depending on the OS etc. case it could be recommended to implement this with C/C++.
Even with .NET 4 as pointed out in the comments the code injection problem remains - i.e. if any .NET app prior .NET 4 and/or with a different .NET versions than your shell extension accesses the file open dialog for example it can/will fail.
To circumvent that you need to implement a native proxy DLL which gets loaded into the respective processes (like Windows Explorer) and communicates with your .NET implementation via IPC.
In this specific case you need to build a shell extension which implements IShellLibrary.
That aside the implementation of shell extension is a really tough job... some links with information / samples / source code / libraries etc.:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774328%28v=VS.85%29.aspx
http://blogs.msdn.com/b/codefx/archive/2010/09/14/writing-windows-shell-extension-with-net-framework-4-c-vb-net-part-1.aspx
http://www.ssware.com/ezshell/ezshell.htm
http://www.codeproject.com/KB/shell/ratingcolumn.aspx?q=shell+extensions+c%23
http://www.codeproject.com/KB/shell/shellextguideindex.aspx
http://www.nirsoft.net/utils/shexview.html
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
To interact with a Windows 7 library see http://support.microsoft.com/kb/976027 and http://www.codeproject.com/KB/miscctrl/Windows7APICodePack.aspx and http://archive.msdn.microsoft.com/WindowsAPICodePack and http://www.codeproject.com/KB/cs/DDW7LibrariesLite.aspx . Some require .NET 3.5 but since 3.5 is just 2.0 plus some additional assemblies it might be an option...

Briefly searching in google, found this: How to programmatically manipulate Windows 7 shell libraries
if C# examples are not useful, it should be possible to export api methods used in c++ example.

Run C# code from Java and vice-versa

I have a game server which is made in Java. I want to make a plugin system that loads a .NET DLL and calls events / functions inside that DLL, then inside those I'll have to call functions in the game server (Java). The only part that is giving me trouble at the moment is how to interface java and a .NET dll.
I've been searching and found some things but they were all based on products and I want to make my own interface for that. Ah, not to mention it needs to have high performance, the code will be called a lot of times in a second if it has to. Could someone point or give-me ideas how could I work this out?
EDIT:
To make it more explicit:
Game Server (Java application) calls a function in .NET dll
The .NET function just called by java, calls multiple functions from Game Server (Java Application).

Take a look at jni4net if you're targeting Windows. It's an alpha quality release, but Robocode already uses it to run .NET robots inside the Java runtime.
Another option is to use a high-performance messaging approach. You'll need a second process - likely a .NET plug-in host. That process then exchanges messages with the main Java game process. Messaging libraries like 0MQ are pretty darn fast but may not be fast enough for what you have in mind. In addition, you'll have to create a lot of message plumbing which may be cost/time prohibitive.

Try using iKVM:
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET
Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries Tools that enable Java and .NET
interoperability
http://www.ikvm.net/

If you only have a few methods you are calling you might just use JNI and do it yourself instead of a 3rd Party tool (though I admit I don't know the details of jni4net). Just a word of caution, the project I'm on had to do a similar thing (C# -> C/C++ -> Java via JNI) and we had nothing but problems with it. Problems mainly because the java api didn't have any good documentation so that might have been part of it. If at all possible try to keep it to one language but if that is not possible, make sure you do lots of error checking. When the app crashes, it is very hard to find the problem (unless you own both the java and C# sutff). Just my $0.02...

Building An App With Plug-in Support

I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)

You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.

This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested

You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.

A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN

I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.

Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.

Why Microsoft not provide for C# a static Win32 class with the most native functions and structures inside like windows.h?

Everybody who used P/Invoke of Windows API knows a long list of declarations of static functions with attributes like
[DllImport ("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
The declaration of structures copied from Windows headers like WinNT.h or from web sites like www.pinvoke.net take also a lot of place in our programs.
Why we all have to spend our time for this? Why Microsoft not give us a simple way to include a line like in old unmanaged programs
#include <windows.h>
and we would be have access to a static class Native with all or the most Windows functions and structures inside?
UPDATED based on some answers:
It you will be honest with yourself, which part of your .NET programs are running not under Windows? 5%? 1%? If you use WMI, Process, Registry or ServiceProcess.ServiceBase classes etc. in .NET is your program so “platform independent” and more “compatible” if you not use native API? Has Thread.ApartmentState everywhere sense out of Windows?
Usage of SafeHandle or try {…} finally is of cause required. I would be happy to have a standard definition of Native API in any of these forms.
I know that some structures in windows.h have different versions 32/64 or XP/Vista etc. I think it would be enough to have also different version of Native structures like MIB_IPADDRROW_XP and MIB_IPADDRROW_W2K or IMAGE_NT_HEADERS32 and IMAGE_NT_HEADERS64 (see the same names in windows headers).
One should of cause use managed .NET classes and methods if there are exist. It’s a pity, but the implementation of some the most powerful features of Windows come in managed .NET too late and a lot of there are accessed till now only in unmanaged world. 10 year ago at one of the first Microsoft conference about .NET I asked about my favor Memory Mapped Files. Only .NET 4 has now MemoryMappedFile class implemented (see http://blogs.msdn.com/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx). The same problems exist permanently if one writes utilities for administrative purpose. For example, opening file with CreateFile and Flag FILE_FLAG_BACKUP_SEMANTICS or RegCreateKeyEx with REG_OPTION_BACKUP_RESTORE or REG_OPTION_CREATE_LINK. Hard Links and Junctions (see http://msdn.microsoft.com/en-us/library/aa365006(v=VS.85).aspx) are next examples. One more example: working with Job Objects instead of Process (see http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx and http://www.microsoft.com/msj/0399/jobkernelobj/jobkernelobj.aspx). If you want to start a process and wait not till this process, but also untill all it’s child processes be ended, job is very useful. One can use CreateJobObject and AssignProcessToJobObject and then use TerminateJobObject or WaitHandle like .NET version of (WaitForSingleObject).
Only in .NET 4.0 System.IntPtr und System.UIntPtr classes supports Add and Subtract methods.
I can continue the examples, but I hope you understand what I mean. So I want to write a program in .NET because of a lot of advantages but I can do this not always without usage of native API. Moreover, there are sometimes customer's requirement to the language of software implementation and I choose the required way.
UPDATED 2: Microsoft improved the interoperability with COM in .NET 4.0, but not with C-like Windows API. I see some ways to makes working with P/Invoke easier. What way to do this you see? I suggest three directions which I see:
One makes an assembly with declaration of all (or the most important) not yet fully implemented in .NET Windows API. This assemble can has only (or almost only) metadata of static Native class with static functions and corresponding classes / structures. This assembly can be placed in GAC and everybody could use it. (This way I tested. It works very well.)
One implements a collection of snippets with declaration and samples of using of different native Windows API.
One start an open source project on www.codeplex.com where one create .NET classes and extension methods to some most important native Windows API which are not yet implemented in .NET.
I am sure that exist more ways to make easier for developer the usage of native Windows API. Other suggestions are welcome.

I don't know why MSFT made that decision, but here are a few reasons why I think the decision was the correct one:
The Windows SDK header files (windows.h et al) make extensive use of conditional compilation based on things like the target Windows version and architecture to determine what functions get declared and how data structures are laid out. None of this would be possible in any of the .NET languages, as one does not target Windows versions but rather framework versions, with the resulting binaries able to run natively on 32- and 64-bit architectures across many versions and editions of Windows
Many Windows API calls and data structures cannot be fully expressed via P/Invoke. One that comes immediately to mind is DeviceIoControl. Another are the many so-called 'variable length' structures, containing arrays with an unknown (at compile time) number of elements in them
P/Invoke has evolved over time, particularly in the way handles are exposed (IntPtr in early versions of the framework; SafeHandle classes later); if MSFT maintained a single static class with most or all Win32 API functions, they would also be obligated to maintain compatibility with previous versions of this class, locking themselves in to however P/Invoke was implemented originally
Even MSFT themselves do not maintain a single Native class in the framework internals. Now that the .NET Framework 3.5 source code is available, you can see for yourself how ad-hoc use of P/Invoke is, even within the very framework we are supposed to use in lieu of P/Invoke. For example, System.Net and System.IO have their own separate P/Invoke declarations.
The .NET Framework and managed code were designed from the beginning as a new way of building software for Windows. How stupid would it be to provide this new way while at the same time requiring use of the old way for many tasks?
I say this as someone who makes extensive use of P/Invoke for things like IOCTLs and volume-level I/O operations. The more I use P/Invoke, the more I hate it. It's hard to work with, error prone, and slow. Every time I use P/Invoke, it's because I've exhausted all other options. If you find yourself with a problem whose solution requires a lot of direct Windows API calls, you probably:
a) Are missing some feature within the Framework that will do what you want
b) Are taking the wrong approach to solving the problem, particularly if you are used to the native Windows API and still think in those terms
c) Should write your low-level code in C++/CLI, and expose chunky higher-level interfaces for your .NET code to consume

I'm sure the thought crossed your minds but I think there should be an open source project that did this.
Rather than waiting on Microsoft to do this, we can collect all of the knowledge that people who've actually used P/Invoke day in day out so that others don't have to reinvent the wheel.
Keep collecting the API as people use them, need them.
Any volunteers? :)
pinvoke.net doesn't count - it's not readily pluggable to your solution.

One view is that PInvoke is a compatibility crutch. You should be using 100% .Net libraries and functions, not "legacy" Win32 calls.

Setting application hooks - C#/ASP.NET

Many popular applications such as Wordpress, WHMCS and the majority of PHP forums allow plugins to hook into core application events (such as registration, logging in, create post etc.) by simply specifying a function with a particular name.
I understand that these applications are not pre compiled, but is it possible to do something of the sort with C#? I've looked into event handlers, but it seems that you can only accomplish this if the plugin has the ability to instantiate the class that we want to hook into (or at least thats what searching has lead me to believe)
Ideally, these hooks would be into business layer class events/methods and can be hooked into by multiple objects, so it would function in either WinForms or ASP.NET MVC.

Given Alex's answer, this should be useful:
System.AddIn Tools and Samples
http://clraddins.codeplex.com/

If you design your application for extensibility, this is easy. The Managed Extensibility Framework is designed for exactly this sort of scenario, and makes it very easy.
It will be included as part of the core framework in .NET 4, but is downloadable now for use in 3.5.

There is an AddIn framework shipping with .NET 3.5. The framework provides very powerful mechanisms to expose interfaces by a host application and to manage, dynamically load-unload addins etc.

Why the core concept that comes up to my mind first, is Dependency Injection? I haven't ever played with a plug-in system in any app of mine. Does DI could help anyhow with that??

Specifics on our senerio would be helpful, but generally, You may want to explore the provider psttern.
There are 3 components:
- An abstraction of a piece of functionality, (Interface/baseClass)
- A Factory method that looks to config to determine what type of Class to create
- [your] Custom Class which extends/implements the abstraction. for example, a Membership provider class that hits a custom dasta source for user info.
This is very useful when switching out logic. If you want to create an app with swappble UI components, it is another story.
There is support for this in ASP.NET, starting with 2.0.
More info on the provider:
http://msdn.microsoft.com/en-us/library/ms972319.aspx