Alternativ kannst du ja mal googlen, ob es eine Dokumentation des Thunderbird-"Archiv" gibt, dann könntest du deine gesendeten Mails auch darin ablegen.
Ich muss mich leider nach langem testen hier auch einmal melden. Ich habe meine Software mit einem Setup ausgerollt. Nun soll ein Update erscheinen, was leider nicht klappt. Über die Administration ist alles ordnungsgemäß eingestellt und er lädt auch scheinbar Daten herunter, die jedoch nie im Verzeichnis ankommen. Starte ich das Programm nach dem Update erneut habe ich immer noch die alte Version.
Die Version ermittle ich wie folgt:
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString();
Das Update wird mit folgenden Code angeschoben:
var updateController = new updateSystemDotNet.updateController("http://update.meineDomain.de/Mein Produkt/");
updateController.releaseFilter.checkForAlpha = false;
updateController.releaseFilter.checkForBeta = false;
updateController.releaseFilter.checkForFinal = true;
updateController.projectId = "Meine ID";
updateController.publicKey = "Mein Key";
updateController.requestElevation = true;
updateController.restartApplication = true;
updateController.autoCloseHostApplication = true;
if (updateController.isUpdateDownloaderBusy)
return;
updateController.updateInteractive(this);
Unklar ist auch, wie ich Daten in einem Unterverzeichnis aktualisieren kann. Ich kann zwar einen Ordner auswählen von dem dann der Inhalt erscheint aber wird die Struktur dann auf dem zu aktualisierendem System beibehalten?
EDIT:
Ich habe mal weiter rumgespielt und dabei folgendes herausgefunden. Mein Update funktioniert, wenn ich nur Dateien im Hauptverzeichnis aktualisieren möchte. Unterorder haben bis zu dem Zeitpunkt geklappt, an dem ich eine weitere nicht im Setup gewesene Datei in das Update-Projekt hinzugefügt habe. Seit dem werden die Dateien, die in einen Unterordner sollen auch im Hauptverzeichnis abgelegt.
Meine Idee war nun, das ich mir einfach ein gleichnamiges Verzeichnis erstelle und dort die Dateien ablege. Das führt aber zu einem Fehler beim Versuch das Update zu installieren, weil es den Ordner ja schon gibt. Ein schwerwiegender Folgefehler ist, dass das Update nicht zurückgerollt wird und meine Applikation damit nicht mehr lauffähig ist, weil unteranderem die Anwendungsdatei (exe) schon entfernt war.
Hallo Forum,
ich habe eine Applikation, die pro Anwender nur einmal gestartet werden darf. Sprich pro User eine aktive Instanz. Nun kommt die Anforderung hinzu, dass beim Öffnen weiterer mit dieser Applikation verknüpfter Dokumente diese auch in der Applikation geöffnet werden sollen. Ihr kennt das Verhalten von Excel.
Um zu prüfen, ob die Applikation bereits gestartet ist verwende ich den auf CodeProject und hier schon im Forum verlinkten Beitrag (C# Single Instance App With the Ability To Restore From System Tray (Using Mutex).
Dazu muss man in der Main() Methode
if (!SingleInstance.Start())
{
SingleInstance.ShowFirstInstance();
return;
}
einfügen.
Meine Idee war es die ProgramInfo Klasse zu erweitern. Allerdings sind die Argumente immer die gleichen und somit ist die Idee wertlos.
Ich denke das ich viel mehr über die überschriebene WndProc Methode und deren Message-Parameter gehen muss.
protected override void WndProc(ref Message m)
{
if (m.Msg == SingleInstance.WM_SHOWFIRSTINSTANCE)
{
WinApi.ShowToFront(this.Handle);
}
base.WndProc(ref m);
}
Nur konnte ich nichts finden, was eine Hinweis darauf gibt, in welcher Property die Parameter gespeichert werden.
Hat einer von euch einen Rat?
Meines Wissens nach gibt es OOB nicht die Möglichkeit, da der Windows Installer alle Komponenten der Installation registriert.
Du kannst dir aber eine CustomAction programmieren die diese Aufgabe innerhalb deines Setups durchführt.
Das ist genau das was ich probiert hatte. Ich habe jedoch die Einschränkung das meine Klassen nicht ausgelagert sind. Da dieser Milenstein bis Montag fertig sein muss werde ich das in einem späteren Release gerade ziehen.
Danke aber schon einmal für die Hilfe.
Ich denke gerade darüber nach mir Extension Method zu schreiben, die dann die Wertzuweisungen übernehmen. Eigentlich muss es doch auch anders gehen als so:
public static Service.Contact ToServiceContact(this IContact contact)
{
return new Service.Contact(){FistName = contact.FirstName,...};
}
Hast du irgendwo ein Link wo das näher beschrieben ist? Ich habe mir mal die Service Reference Konfiguration angesehen und damit etwas rumgespielt. Anschließend ging nichts mehr 8o also wieder alles zurück gestellt. 🙁
Ich meine damit, dass die IContact Objekte die gleichen Properties enthalten wie das Objekt, das der Service erwartet. Beides sind Transferobjekte und haben somit keine von mir erstellten Methoden.
Das Service Objekt würde also auch das IContact Interface implementieren. Allerdings tut es das nicht, weil durch die Serialisierung und durch die Proxy-Generierung vom VisualStudio diese Information verloren geht.
Wie kann ich denn die "inneren" Objekte übergeben, wenn Sie laut Compiler nicht vom gleichen Typ sind - in ihrer Implementierung aber schon? Genau das ist doch mein Problem.
@unconnected: Das habe ich jetzt nicht verstanden.
Hallo Forum,
ich habe folgendes Problem bei einem Plug-In System für Datenimporte.
Die PlugIns implementieren eine Methode public List<IContact> LoadData(string path) die vom PlugIn Host aufgerufen wird um die Daten entgegenzunehmen.
Die Daten müssen dann an einen Webservice weitergegeben werden damit sie zentral gespeichert werden können. Und hier tritt mein Problem auf.
Die Daten vom PlugIn implementieren alle IContact. Die Transferobjekte des Webservice tun dies auch nur wissen sie das auf Grund der Proxy-Klassen nicht.
Wie kann ich - ohne großen Aufwand zu betreiben - die Daten einfach an die Webservice Methode SaveContact(Contact contact) übergeben?
Versucht habe ich es schon so:
Service.SaveContact((Service.Contact) iContactObject);
Hier kann er den Typ jedoch nicht wandeln.
Service.SaveContact(iContactObject as Service.Contact);
Hier kann er den Typ auch nicht wandeln und gibt NULL zurück.
Da ich gerade an der gleichen Problematik arbeite, kann ich dir sagen, dass herbivore Recht hat. Du solltest die referenzierte Interface dll auf false bei Lokale Kopie setzen. Und dein Plug-In muss natürlich auch dein IPlugIn Interface implementieren.