none
registrierung ocx debug/release RRS feed

  • Frage

  • hab das gleiche bereits fälschlicherweise in einen englischen thread geschrieben, darum hiernochmal:

    seltsames problem:
    ich entwickle ein control (ocx) mit vs2010. in den projekteinstellungen ist angehakt, daß die ausgabe registriert werden soll.
    projekt kompiliert prima, registrierung ebenfalls, sowohl bei debug als auch bei release.
    nach dem kompilieren/registrieren schau ich in die registry und sehe, daß unter

    HKEY_CLASSES_ROOT\CLSID\{9BA69CB2-637A-11D3-844E-004005E288E4}\InprocServer32

    je nach build tatsächlich der debug- oder release-pfad zum erzeugten ocx steht (und die datei existiert dort auch, gerade frisch)

    so weit so prima, jetzt zum gui (ebenfalls vc++)
    per ressourceneditor packe ich das gerade erzeugte ocx in ein formular - es wird ein entsprechender wrapper generiert:

    class CSPCRegelkarte : public CWnd
    {
    protected:
      DECLARE_DYNCREATE(CSPCRegelkarte)
    public:
      CLSID const& GetClsid()
      {
        static CLSID const clsid
          = { 0x9ba69cb2, 0x637a, 0x11d3, { 0x84, 0x4e, 0x0, 0x40, 0x5, 0xe2, 0x88, 0xe4 } };
        return clsid;
      } 

    das sieht soweit auch gut aus.

    das problem ist nun, daß egal, ob ich das control als release oder debug baue, die release-variante angezogen wird (zu erkennen am den ausschriften im output-fenster bzw. an den trace ausgaben des controls).

    hat jemand eine idee, woran das liegen könnte?

    ich arbeite unter vista, user mit adminrechten, starte visual studio als admin (damit regsvr32 klappt)

    ob ich mit vc6 oder vs2010 kompiliere, ändert am ergebnis nichts

    ich kann das gebaute release-control manuell ins debug-verzeichnis kopieren, dann wird das auch fehlerfrei benutzt

    dankbar für hilfe oder hinweise

    micha
    • Bearbeitet suriel6666 Dienstag, 13. Juli 2010 18:35 beim einfügen grützig formatiert
    Dienstag, 13. Juli 2010 18:29

Antworten

  • Wenn durch CoCreateInstance ein Objekt mit der DLL aus dem Debug Verzeichnis geladen wird, dann ist dieses auch zu 100% aktuell registriert ;)

    Nur die Registry entscheidet welches Executable geladen wird...


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Mittwoch, 14. Juli 2010 06:21
    Moderator

Alle Antworten

  • Wie debuggst Du denn? Welche DLL wird denn durch das debuggen geladen? Diese registriert natürlich auch die Classfactory beim Laden.

    Mach es mal anders. Lass mal Deine OCX von einem VBS Script laden und attache Dich an den Prozess. Oder benutze die LOG Funktion von Depends. Du wirst sehen, dass dann die registrierte Version geladen wird.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Dienstag, 13. Juli 2010 19:21
    Moderator
  • > Wie debuggst Du denn?

    indem ich im gui-projekt f5 ("debuggen") starte. 

    btw: auch, wenn ich das gui als release baue und starte, seh ich die traceausgaben des controls (per sysinternals dbgview) (trace erfolgt durch MFC-Makro TRACE, entfällt also in release-builds)

     

    > Welche DLL wird denn durch das debuggen geladen?

    nicht dll sondern ocx. das, ausm debug-verzeichnis

     

    > Lass mal Deine OCX von einem VBS Script laden und attache Dich an den Prozess

    kann ich ausprobieren- leider aber vermutlich erst am freitag - ergebnis werde ich hier kundtun

     

    Dienstag, 13. Juli 2010 19:29
  • Wenn durch CoCreateInstance ein Objekt mit der DLL aus dem Debug Verzeichnis geladen wird, dann ist dieses auch zu 100% aktuell registriert ;)

    Nur die Registry entscheidet welches Executable geladen wird...


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Mittwoch, 14. Juli 2010 06:21
    Moderator
  • das gleiche projekt auf einen anderen rechner getragen (nur die ousrcen, nichts generiertes) und kompiliert, funktioniert jedoch, wie erwartet. kann es mir irgendwelchen datein zu tun zu haben, die vs erzeugt???
    Freitag, 16. Juli 2010 22:34
  • Nein!

    Nur die Registry und deren Werte sind für das Erzeugen und laden von solchen Klassen ausschlaggebend.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Sonntag, 18. Juli 2010 11:09
    Moderator