So gehts einfacher:
C

typedef struct {
    TCHAR Description[128];
    TCHAR Driver[128];
    LARGE_DRIVER DriverVersion;
} MYSTRUCT;

BOOL GetInformation(int Number, MYSTRUCT *s);

C#

[StructLayout (LayoutKind.Sequential, CharSet=CharSet.Ansi)]
struct MYSTRUCT {
    [MarshalAs (UnmanagedType.ByValTStr, SizeConst=128)]
    string Description;
    [MarshalAs (UnmanagedType.ByValTStr, SizeConst=128)]
    string Driver;
    long DriverVersion;
}

bool GetInformation(int Number, out MYSTRUCT s);

=> Marshal.PtrToStringAnsi.
Allerdings ist deine C-Funktion etwas eigenartig. Wie gibtst du den Speicher, den die Strings belegen wieder frei?

=>CodeDOM

Version Information
.NET Framework
Supported in: 3.5, 3.0, 2.0, 1.1, 1.0

Gibt es nicht im CF

Du musst terminationRequired und stopRequired als volatile deklarieren.
Das lock um terminationRequired und stopRequired kannst du dir sparen, ist unnötig.
Du solltest außerdem die Threadmethode umschreiben, da der Thread sonst sinnlos CPU-Zeit benötig(stopRequired=true), eventuelle reicht auch ein Timer für deinen Fall.

Der Webserver erwartet die Daten im Format "VarName=Value". Du hast dem Webserver irgendwas geschickt. Würde mich nicht wundern, wenn der Webserver die Daten einfach verwirft.

Der Code für die SHELLEXECUTEINFO Struct ist falsch und wird so nur unter 32-Bit Betriebssystemen funktionieren.
Auf pinvoke.net findest du die korrekte Version.

Nimm doch einfach einen StreamReader bzw. StreamWriter.

oder du suchst selbst nach der Assembly =>AppDomain.AssemblyResolve

Setz ein [STAThread] vor die Main-Methode

Du kannst dir auch mal Wix ansehen. Das hat bereits einige Custom Actions für SQL.

  
Bitmap bm = new Bitmap(imgOriginal, width, heigth);  
  

Das erzeugt dir ein neues skaliertes Bild, aber mit entsprechend schlechter Qualität. Dafür aber schnell. Wenn du die Qualität selbst beeinflussen willst, musst du wohl den Umweg über die Graphics-Klasse nehmen.

des weiteren würde ich es eher so implementieren ,das ich ein "original"bitmap hätte und in der onpaint einfach mit DrawImage das zeichnen würde, was ich brauche und im zoomevent nur ein invalidate aussprechen würde.

Wenn du die Qualität beim Skalieren auf hoch änderst, würde ich bei der von dir verwendeten Bildgröße davon abraten. Das ist einfach zu langsam. Du solltest auf alle Fälle neben dem Originalbild ein entsprechend skaliertes Bild speichern. Im OnPaint zeichnest du das skalierte Bild und im OnResize erzeugst du dir das skalierte Bild.

Erstell dir eine Dll in C oder C# und binde diese als CustomAction ein.

Definiere "große Mengen von Daten" genauer.
.Net Remoting ist nicht dafür konzipiert um Megabyte-große Dateien zu übertragen. So fehlt es an der Möglichkeit den Vorgang abzubrechen, oder Infos über den Fortschritt zu erhalten.
Auch mit Events wirst du dir mit .Net Remoting schwer tun. Prinzipiell ist es möglich, dass der Server eine Methode am Client aufruft. Aber dafür muss der Client ebenfalls als Server fungieren. Im Intranet mag das noch funktionieren, aber übers Internet bekommst du schnell Probleme mit Firewalls.

Zu WCF kann ich dir leider keine genaueren Auskünfte geben.

ruf streamWriter.Flush() in der Schleife auf.

Schau dir mal die AnimateWindow-Funktion an. C#-Imports findest du auf pinvoke.net

Ja, schau dir die PlatformAdaptationLayer-Klasse an(siehe spec-hosting.doc).
Alternativ kannst du die DLR auch in einer eigenen AppDomain laufen lassen.

=>GCHandle

@LittleBoy
Du kannst das VersionNT64-Property als Condition für die Dll verwenden.

In der Methode wird die kernel32.dll geöffnet und nachgeschaut, ob überhaupt die exportierte Funktion "IsWow64Process" existiert. Nur wenn das der Fall ist, wird auch diese Methode aufgerufen. Das hat folgenden Grund: Die Methode IsWow64Process kann natürlich nicht auf einem 32bit System aufgerufen werden, da es sonst sofort knallt. Die gibts halt nicht.

IsWow64Process gibt es sehr wohl auch auf 32-Bit Betriebssystemen und liefert hier erwartungsgemäß false zurück. Allerdings gibt es IsWow64Process erst seit Windows XP SP2, deshalb die Überprüfung analog zum Beispielcode der MSDN zu IsWow64Process.
Da es Is64BitOperationSystem erst mit .Net 4.0 gibt, und dieses zumindest Windows XP SP3 voraussetzt ist diese Überprüfung eigentlich nicht nötig.

@BerndFfm:
Schau dir mal die IsWow64Process Funktion an.

Nicht ganz, ich habe auch mit größerem Buffer versucht, das gleiche Ergebnis

Was ich dir damit sagen wollte ist: Pack die Read-Methode in eine Schleife und ruf diese solange auf, wie noch Daten vorhanden sind.
Das findest du auch in jedem Tutorial zu Dateien/Sockets

Bei dir ist die Struct, die Methodensignatur und auch der Aufruf falsch. Probier mal folgendes:

[StructLayout(LayoutKind.Explicit)]
public struct tagCMD_fifo {
    [FieldOffset(0)]
    public int nControl;
    [FieldOffset(4)]
    public fixed byte szData[9];
    [FieldOffset(4)]
    public ushort nData;
    [FieldOffset(4)]
    public ulong lData;
    [FieldOffset(4)]
    public float fData;
    [FieldOffset(4)] 
    public double dData;
}

[DllImport("SFP2_MCP_SDK.dll")]
protected static extern bool SFP2_MCP_Open();

[DllImport("SFP2_MCP_SDK.dll")]
protected static extern void SFP2_MCP_Close();

[DllImport("SFP2_MCP_SDK.dll")]
protected static extern bool SFP2_MCP_Read(ref tagCMD_fifo val);

[DllImport("SFP2_MCP_SDK.dll")]
protected static extern bool SFP2_MCP_Write(ref tagCMD_fifo val);

Du ließt ja auch nur max. 1024 Bytes ein. Wie willst du denn da alles empfangen, wenn der Client mehr als die 1024 Bytes sendet? 😁

Hallo herbivore,

Bei Standard-Windows-Messages gebe ich dir Recht, hier würde es mich auch nicht wundern. Aber bei extra für IPC geschaffenen Windows-Messages - und diese würde der Threadersteller ja sinnvollerweise verwenden - mache ich mir keine Sorgen.
Genautogut könnte man .Net Remoting als "zukunftsunsicher" bezeichnen, da sich hier seit .Net 2.0 nichts mehr getan hat, obwohl es noch einige verbesserungswürdige Punkte gibt.

Hallo,

Ich sehe das nicht so.
Microsoft wird vielleicht in Zukunft System Messages wie WM_Click blockieren, allerdings sicher nicht extra für diesen Zweck (IPC) geschaffene Nachrichten wie WM_COPYDATA oder WM_APP.
Abgesehen davon lassen sich mit der WM_COPYDATA-Nachricht sehr einfach Benachrichtigungen und auch .Net Objekte verschicken. Sollte es nur darum gehen einfache Nachrichten (Ping, Statusinformationen) auszutauschen, würde ich viel eher Windows-Messages als .Net Remoting verwenden.

Du könntest per Reflection.Emit dynamisch Code erzeugen der auf dein Property zugreift.

Probier mal

[DllImport("cardterm32.dll"", CharSet = CharSet.Ansi)]
private static extern short tcs_auto_vor(string betrag, StringBuilder rc_allstatus);

Für Sockets bieten sich I/O Completion Ports an. Laut Microsoft die effizienteste Möglichkeit mehrere parallele I/O-Zugriffe unter Windows zu bedienen.
Mit .Net kannst du einfach die BeginXXX und EndXXX Methoden der Stream-Klasse nutzen. Siehe Asynchronous Programming Design Patterns

Mit

Graphics.CompositingMode = CompositingMode.SourceCopy

erreichst du, dass die Farbe überschrieben wird.

@tkrasinger:
Du musst ja auch zuerst den Key und IV setzen.

Mir ist aufgefallen, dass du relativ oft den Tippfehler Enrypted statt Encrypted hast.

Da hat sich wohl ein kleiner Tippfehler per Copy&Paste vervielfältigt.

@gfoidl

Dein Benchmark ist nicht aussagekräftig, denn du vergleichst Äpfel mit Birnen.
Auf der einen Seite verwendest du den sicher hochoptimierten matmul-Befehl von Fortran und auf der anderen Seite eine naive C# Implementierung.

=>Common Gateway Interface

Ok, dann werde ich das mal lassen. Und wie sieht es mit meiner RAM-Idee aus? Würde sich das etwas bringen?

So eine "Herausforderung" hat mal egrath geposted. War aber innerhalb eines Tages geknackt...

Der Type int hat - sofern der Microsoft C++ Compiler verwendet wurde - fix 4 Byte Länge. Entspricht also einem C# int.
Siehe auch http://msdn.microsoft.com/en-us/library/s3f49ktz%28VS.80%29.aspx

Wenn du GUID_DEVINTERFACE_USB_DEVICE angibst, bekommst du den Event bei jedem USB-Device, du musst hier die Interface Class GUID von deinem Device verwenden.
Btw.:
dbcc_devicetype sollte auf DBT_DEVTYP_DEVICEINTERFACE gesetzt werden und dbcc_classguid auf die GUID.

Das [MarshalAs(UnmanagedType.ByValArray)] musst du auf das Array im struct anwenden.
Zeig einfach mal die Header-Datei her, dann kann man dir besser helfen.

Ich habe es nun selber ausprobiert und unten stehender Code erzeugt eine zweite AppDomain und lädt die WinForms-Anwendung "myapp.exe", welche sich im selben Verzeichnis befinden muss, in die neue AppDomain.

class Program {

    static void Main(string[] args) {
        AppDomainSetup setup = new AppDomainSetup();
        setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
        setup.ConfigurationFile = "myapp.exe.config";

        AppDomain newDomain = AppDomain.CreateDomain("myAppDomain", null, setup);
        AppDomainLoader remoteLoader = (AppDomainLoader)newDomain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, "AppDomainLoader");
        remoteLoader.Load();

        Console.WriteLine("Press <ANY> Key to exit...");
        Console.ReadKey();

        remoteLoader.SendQuitMessage();
    }
}

public class AppDomainLoader : MarshalByRefObject {

    public void SendQuitMessage() {
        Application.Exit();
    }

    public void Load() {
        Assembly a = Assembly.Load("myapp");

        Thread t = new Thread(delegate() { a.EntryPoint.Invoke(null, new object[] { new string[0] }); });
        t.Start();
    }

}

Dein Objekt muss auch global sein , d.h. keine lokale Variable.
Abgesehen davon solltest du die Struktur im Speicher pinnen oder Marshal.AllocHGlobal verwenden.

Die FileAccess-Enumeration wurde für den managed FileStream geschrieben und deckt sich nicht mit den Win32-Defines für Read/Write - Access.

=>MarshalAs-Attribut mit UnmanagedType.ByValArray

@FatToni
Man braucht weder in deinem, noch in ibuddy Fall unsafe oder pointer.
In deinem Fall tut es ein einfaches byte-Array.

[DllImport(@"C:\CamUsb_API.dll", EntryPoint = "CamUSB_GetErrorString")]
static extern intGetErrorString(StringBuilder buffer, int maxLen, int errCode); 

StringBuilder buffer = new StringBuilder(256);
GetErrorString(buffer, buffer.Capacity, errorid);

Dann nimm statt SafeWaitHandle einfach das AutoResetEvent.Handle Property und ändere entsprechend den dritten Parameter von FT_SetEventNotification auf IntPtr.

das ist schon klar, hatte ich ja auch! Wegen der AppDomain, ist natürlich jeweils ne andere!

Das geht aus deinem Code nicht hervor. Und ehrlich gesagt bezweifle ich das.
Also poste doch deinen Code, dann kann man dir auch helfen.

Btw.: Mit deinem Code-Schnipsel kann man nur raten, aber ich vermute mal du lädst die zweite Anwendung nicht in die neue AppDomain sondern (auch) in die AppDomain deiner Hauptanwendung. Dadurch wird natürlich das Config-File deiner Hauptanwendung verwendet.
=> Such mal nach Plugin-Architektur, AppDomain RemoteLoader um das Problem zu lösen

In deinem Beispiel setzt du auch nirgends das ConfigurationFile-Property. Ausserdem ist das "@" vor dem ApplicationBase-Verzeichnis falsch.

Versuch mal bei AppDomainSetup.ApplicationBase nur das Verzeichnis anzugeben.

Schau dir mal die AppDomainSetup-Klasse an. Insbesondere das ConfigurationFile-Property.
Abgesehen davon umgehst du damit Probleme wie das zuvor geschilderte Aufrufen von

Application.SetCompatibleTextRenderingDefault(false);

Bei dem was du vorhast ist es sicher besser die Assembly in eine eigene AppDomain zu laden.