Hallo Matthias,
Bei einer Anzahl von 200 PC-Systemen sollte mehr als nur die Einfachheit und Eleganz der Verteilung in den Vordergrund gestellt werden.
Eine gemeinsam benutzte Datenbankschnittstelle wird nicht alle Tage umgeschrieben, und Sicheheit sollte die oberste Priorität erhalten. Um so mehr dort, wo auf Unternehmensdaten zugegriffen wird. Deshalb gehe ich davon aus, dass die Datenbankschnittstellen-Assembly
zumindest mit einem starken Namen versehen wird, um die Identität und Integrität der Assembly sicherzustellen.
Gemeinsam genutzte Assemblies werden gewöhnlich im Global Assembly Cache (GAC) installiert. Bei der Bindung von
strong named Assemblies wird eine Dependency zuerst im GAC und erst dann an anderen Orten gesucht, so dass man auch nachträglich, nach Auslieferung einer Anwendung, gemeinsam genutzte Dependencies leicht upgraden kann: Der GAC bietet
Versionierung und Bindungsumleitung über Herausgeberrichtlinien-Dateien, die es erlauben ältere Versionen auf die gewünschte Version (z.B. neueste) umzuleiten.
Um gemeinsam genutzte Assemblies automatisiert zu installieren, wird normalerweise der Windows Installer verwendet. Man kann diesen im unbeaufsichtigten Modus ausführen lassen (msiexec.exe /i Product.msi
/qn), ohne Benutzerinteraktion. Der Windows Installer verfügt darüber hinaus über die Fähigkeit, Assemblies im GAC zu registrieren (der Setup-Assisten in Visual Studio bietet eine sehr einfache Vorgehensweise über
den Ordner Cacheordner für globale Assembly). Voraussetzung dafür sind lokale Administratorrechte, die Du aber sowieso brauchst, wenn Du auf %programfiles% schreibend zugreifst.
Bereitstellung mit Visual Studio Installer
http://msdn.microsoft.com/de-de/library/2kt85ked.aspx
Performing a Silent Installation with a Windows Installer:
http://msdn.microsoft.com/de-de/library/ms227324(v=VS.90).aspx
Arbeiten mit Assemblys und dem globalen Assemblychache:
http://msdn.microsoft.com/de-de/library/6axd4fx6.aspx
Setup-Assistent:
http://msdn.microsoft.com/de-de/library/kay7az51.aspx
Gewusst wie: Erstellen einer Herausgeberrichtlinie
http://msdn.microsoft.com/de-de/library/dz32563a.aspx
File.Copy-Deployment einer privaten Assembly ist in Deinem Szenario eine schöne Illusion (WebClient.DownloadFile() o.Ä. inbegriffen). Im Endeffekt handelt man sich dabei im Enterprise-Einsatz nur Probleme ein. Durch
das Kopieren einer einzigen privaten Assembly ins Anwendungsverzeichnis wird der Versionierungsmechanismus von .NET umgangen, und man kehrt damit zur
DLL-Hölle zurück. Die Codebasis hat sich geändert, aber die Version lautet noch immer z.B. 1.0.0.0, um die Bindung an die bereits ausgelieferten Anwendungen zu ermöglichen. Wie soll da noch eine vernünftige Wartung erfolgen?
Wie sollen Fehlermeldungen effektiv analysiert werden?
Ich weiß nicht, welche Verteilungssoftware ihr z.Z. im Hause im Einsatz habt. Wenn es aber Microsoft System Center Configuration Manager ist o.Ä., dann wäre das m.E. ein klassischer Fall für dessen Einsatz.
System Center Configuration Manager 2007 R2
http://www.microsoft.com/germany/systemcenter/sccm/default.mspx
Gruß
Marcel
