Netzlaufwerk per Programm



  • DanielK. schrieb:

    Hallo Spezialisten,
    Wenn nicht, wie könnte man das sonst lösen?

    Du könntest

    net use lw: \\SERVER\FREIGABENAME

    aufrufen.

    Näheres sagt Dir net help use in der Kommandozeile.

    Gruss
    foodax



  • Ein Netuse Befehl geht zwar, ich hätte es aber schon gerne in ein bestehendes Programm integriert, um nicht zu viele Dateien zu haben.

    Ich habe schon lange im Netz gesucht, da scheint es aber tatsächlich nichts zugeben, was mein Problem und meiner Lösungsvorstellung in vc++ entspricht.

    Hat noch jemand ne Idee?





  • Hallo hustbaer,

    das mit dem google'n war nicht richtig nett.
    Das Ding mit der API habe ich schon vorher gefunden (WNetAddConnection2). Ich habe allerdings bei diesen Dingern immer das Problem, wie man die Variablen in das Visual c++ 2008 integriert.

    Wenn ich nun diesen Code aus Deinem Link einsetze, so bekomme ich eine Fehlermeldung:

    error C2440: 'Initialisierung': 'const char [13]' kann nicht in 'TCHAR [260]' konvertiert werden

    Mit Sicherheit liegt das an dem Typ, aber welchen muss ich verwenden?

    Kann man das irgendwo nachlesen, welche Datentypen allgemein in Visual c++ für die API Typen zuverwenden sind?



  • Ich brauche nochmal Hilfe,

    ich komme mit der API WNetAddConnection2 nicht weiter.

    Das funktioniert:
    ProcessStartInfo ^test=gcnew ProcessStartInfo("net"," use z: \\\comp1\\c$ test1 /user:testuser");
    test->WindowStyle=ProcessWindowStyle::Hidden;
    Process::Start(test);

    Das gleiche mit der API liefert immer Error 487:

    value struct net_resource{
    UInt32 dwScope;
    UInt32 dwUsage;
    UInt32 dwType;
    String ^lpLocalName;
    String ^lpRemoteName;
    UInt32 lpProvider;
    };

    [DllImport("Mpr.dll")]
    extern "C" UInt32 WNetAddConnection2(net_resource %,String,String,Int32);

    net_resource %resource= *(gcnew net_resource);
    resource.dwScope=RESOURCE_GLOBALNET;
    resource.dwUsage=RESOURCEUSAGE_CONNECTABLE;
    resource.dwType=RESOURCETYPE_ANY;
    resource.lpLocalName="z:";
    resource.lpRemoteName="\\\comp1\\c$";
    resource.lpProvider=NULL;

    String ^password="test1";
    String ^username="testuser";
    DWORD test=WNetAddConnection2(resource,password,username,CONNECT_UPDATE_PROFILE);

    Aus stdafx.h:

    #include <windows.h>
    #pragma comment (lib, "mpr.lib")
    #pragma comment (lib, "Netapi32.lib")
    #include <winnetwk.h>
    #include <stdio.h>
    #include <tchar.h>

    Warum geht das nicht?



  • DanielK. schrieb:

    Hallo Theta,

    leider ist das C# Code. Ich könnte was für visual c++ gebrauchen (Kenne mich nicht aus in c#).
    Kann ich diese Klasse möglicherweise in c++ aufrufen?

    Wenn ja, wie?

    Da Du im C++/CLI Forum bist und C++/CLI eine .NET Sprache ist, ist es überhaupt kein Problem den C# Code zu verwenden. Entweder Portierst Du ihn nach C++/CLI oder Du machst daraus ein eigenes Assembly und benutzt ihn dann im Programm (C++/CLI).

    Ausserdem kannst Du auch einfach (wie schon erwähnt) die Win32 API direkt verwenden (WNetAddConnection2 etc.). Da brauchst Du auch kein DLLImport.

    Ich rate Dir aber in einer Welt zu bleiben. Entweder .NET (C#, C++/CLI, VB.NET, etc) oder dann ganz auch die unmanaged Schiene gehen.

    Ich würde nicht mischen. Wenn dann an definierten Stellen über ein wohldefiniertes API.

    Simon



  • DanielK. schrieb:

    Wenn ich nun diesen Code aus Deinem Link einsetze, so bekomme ich eine Fehlermeldung:

    error C2440: 'Initialisierung': 'const char [13]' kann nicht in 'TCHAR [260]' konvertiert werden

    Das hängt damit zusammen, dass TCHAR je nach Compiler Einstellung (Unicode, Multibyte) entweder wchar_t ist oder ein char.

    DanielK. schrieb:

    Mit Sicherheit liegt das an dem Typ, aber welchen muss ich verwenden?

    Korrekt erkannt. Nimm doch TCHAR, wenn TCHAR verlangt wird.

    DanielK. schrieb:

    Kann man das irgendwo nachlesen, welche Datentypen allgemein in Visual c++ für die API Typen zuverwenden sind?

    Ja, im MSDN. Online und Offline. Auf deutsch und auf englisch:
    http://msdn.microsoft.com/de-de/default.aspx

    Simon



  • theta schrieb:

    Ich rate Dir aber in einer Welt zu bleiben. Entweder .NET (C#, C++/CLI, VB.NET, etc) oder dann ganz auch die unmanaged Schiene gehen.

    Ich würde nicht mischen. Wenn dann an definierten Stellen über ein wohldefiniertes API.

    Ganz schlechter Rat. Der Vorteil an C++/CLI ist es ja gerade mischen zu können. Nur sollte man *kontrolliert* mischen. Dinge die man in C++/CLI "einfach so" aufrufen kann über PInvoke zu machen finde ich auf jeden Fall total falsch.



  • Hallo Simon,

    danke für die Antworten.

    Ich habe ein Studium bei der HAF und ILS in Visual C++ 2005 gemacht. Das mit dem Code mischen, habe die uns so beigebracht.

    Auch wie man einen Teil von Vb Code integriert. Nicht aber, wie man C# Code dazu holt.

    Kannst Du mir hier nochmal aushelfen?



  • hustbaer schrieb:

    theta schrieb:

    Ich rate Dir aber in einer Welt zu bleiben. Entweder .NET (C#, C++/CLI, VB.NET, etc) oder dann ganz auch die unmanaged Schiene gehen.

    Ich würde nicht mischen. Wenn dann an definierten Stellen über ein wohldefiniertes API.

    Ganz schlechter Rat. Der Vorteil an C++/CLI ist es ja gerade mischen zu können. Nur sollte man *kontrolliert* mischen. Dinge die man in C++/CLI "einfach so" aufrufen kann über PInvoke zu machen finde ich auf jeden Fall total falsch.

    Mischen ist ja ok, aber nicht im ganzen Code. Für mich ist C++/CLI ein Weg um managed und unmanaged zusammenzubringen. Jedoch nicht um nach belieben zwischen managed und unmanaged hin und her zu wechseln.
    Und ja P/Invoke in C++/CLI ist sinnlos.

    Simon



  • theta schrieb:

    hustbaer schrieb:

    theta schrieb:

    Ich rate Dir aber in einer Welt zu bleiben. Entweder .NET (C#, C++/CLI, VB.NET, etc) oder dann ganz auch die unmanaged Schiene gehen.

    Ich würde nicht mischen. Wenn dann an definierten Stellen über ein wohldefiniertes API.

    Ganz schlechter Rat. Der Vorteil an C++/CLI ist es ja gerade mischen zu können. Nur sollte man *kontrolliert* mischen. Dinge die man in C++/CLI "einfach so" aufrufen kann über PInvoke zu machen finde ich auf jeden Fall total falsch.

    Mischen ist ja ok, aber nicht im ganzen Code. Für mich ist C++/CLI ein Weg um managed und unmanaged zusammenzubringen. Jedoch nicht um nach belieben zwischen managed und unmanaged hin und her zu wechseln.
    Und ja P/Invoke in C++/CLI ist sinnlos.

    Simon

    Gut dann sind wir uns eh einig. Klang nur so als ob du ganz gegen Mischen wärst, also auch gegen "sauber" Mischen.


Anmelden zum Antworten