Late Binding von Verweisen
Andre Grumbach
ich besch�ftigt seit l�ngerem eine Frage:
Ist es m�glich, Projekte �ber Late Binding mit diversen DLLs zu
Referenzieren?
Hintergrund ist folgender, wir verwenden in all unseren Projekten eine
bestimmte Basisklasse. Diese sollte zwar keine Fehler beinhalten, tut es
aber immer wieder.
Die folge davon ist, es m�ssen alle Tools wieder neu erstellt und
installiert werden.
Ist es nicht auch einfach m�glich, �ber eine Config oder �hnliches die
Version festzulegen, damit ich nur die Basisklasse austauschen muss, bzw.
nur eine neue Version davon in den GAC kopieren muss.
Ist sowas m�glich, wenn ja kann mir einer Informationen dazu zukommen
lassen?
Danke,
Andre
Immo Landwerth
> Ist es nicht auch einfach m�glich, �ber eine Config oder �hnliches die
> Version festzulegen, damit ich nur die Basisklasse austauschen muss,
> bzw. nur eine neue Version davon in den GAC kopieren muss.
Das einfachste ist, die Assembly Version von dem Assembly, das die
Basisklasse enth�lt, nicht zu �ndern. Dann musst Du nur dieses eine
Assembly austauschen.
Andere M�glichkeit sind Publisher Policies.
[How to: Create a Publisher Policy]
http://msdn.microsoft.com/en-us/library/dz32563a.aspx
Davon w�rde ich pers�nlich allerdings abraten, weil sich dieser in de
Praxis als ziemlich viel Arbeit herausgestellt haben.
--
Immo Landwerth
Frank Dzaebel
> Ist es m�glich, Projekte �ber Late Binding mit diversen DLLs zu
> Referenzieren? [...] �ber Config [...]
Zun�chst ist "Late Binding" quasi sp�ter als Config-Handling.
Und ja, es ist auch �ber Config m�glich. Eigentlich, -
betrachtest Du einmal die "machine.config" - ist es eh
schon zum Teil so, dass Du �ber Fallback-Mechanismen
in .NET �ber config's arbeitest selbst bei Herausgeberrichtlinien.
[Umleiten von Assemblyversionen]
http://msdn.microsoft.com/de-de/library/7wd6ex19.aspx
Richtig "latebind" ist es dann, wenn Du im Code das Laden
von Assemblies direkt initiierst. Etwa:
[Assembly.Load-Methode (String) (System.Reflection)]
http://msdn.microsoft.com/de-de/library/ky3942xh.aspx
> Hintergrund ist folgender, wir verwenden in all unseren Projekten
> eine bestimmte Basisklasse. Diese sollte zwar keine Fehler
> beinhalten, tut es aber immer wieder.
> Die folge davon ist, es m�ssen alle Tools wieder neu erstellt und
> installiert werden.
> Ist es nicht auch einfach m�glich, �ber eine Config oder �hnliches
> die Version festzulegen, damit ich nur die Basisklasse austauschen
> muss, bzw. nur eine neue Version davon in den GAC kopieren muss.
Ja klar, das ginge �ber die Methoden in meinem Link.
BTW: die Assembly-Version f�r eine ge�nderte Funktionalit�t
einfach beizubehalten, f�nde ich *sehr* unsauber. Beispielsweise
hat man beim VS 2008 SP1 ein File-Versions-abh�ngiges Setup
sodass Deine Assembly normal gar nicht installiert werden w�rde,
weil das Setup "merkt", dass es sich um die gleiche Datei-Version
handelt - und noch einiges mehr.
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Immo Landwerth
> Ja klar, das ginge �ber die Methoden in meinem Link.
> BTW: die Assembly-Version f�r eine ge�nderte Funktionalit�t
> einfach beizubehalten, f�nde ich *sehr* unsauber.
So unsauber ist das auch wieder nicht -- die Assembly Version steuer das
Verhalten des Binders. Microsoft selbst nutzt das z.B. auch beim .NET
Framework aus (mscorlib hat �ber alle Service Packs hinweg die gleiche
Assembly Version, nur die File Version �ndert sich).
--
Immo Landwerth
FrankDzaebel
> Microsoft selbst nutzt das z.B. auch beim .NET
> Framework aus (mscorlib hat über alle Service Packs
> hinweg die gleiche Assembly Version, nur die File
> Version ändert sich).
ich kenne die File-Versionen ein wenig ;-)
[Determine the Servicepack of .NET Framework]
http://dzaebel.net/NetVersions.htm
ich denke Du musst Dich etwas von "Microsoft" lösen.
Microsoft kann (überwiegend sogar berechtigt) Dinge tun, die
für Nicht-OS-Frameworks/Applikationen nicht als best practice gelten.
Als OS Hersteller gelten andere Gesetze :-)
BTW: in den überwiegenden Fällen macht es MS ja sauber,
etwa bei Office PIAs gehts sauber über Assembly Umleitung
per Policy.
Immo Landwerth
> BTW: in den �berwiegenden F�llen macht es MS ja sauber,
> etwa bei Office PIAs gehts sauber �ber Assembly Umleitung
> per Policy.
Das stimmt nicht. Mindestens Microsoft Project verwendet f�r alle 2007er
Assemblies die Versionsnummer 12.0.0.0. Zwischen der Service Packs
�ndern sie sich auch nicht.
--
Immo Landwerth
Frank Dzaebel
>> BTW: in den �berwiegenden F�llen macht es MS ja sauber,
>> etwa bei Office PIAs gehts sauber �ber Assembly Umleitung
>> per Policy.
>
> Das stimmt nicht.
Doch ;-)
Hier die Liste der umgeleitenden Office PIA Assembly Redirects:
[Office Primary Interop Assemblies]
http://msdn.microsoft.com/en-us/library/15s06t57(VS.80).aspx
Office macht das also �berwiegend sauber.
Das Redirect ist ja normal f�r die 2003er Calls
gedacht. Diese werden dann sauber auf 2007 umgeleitet.
Immo Landwerth
> Doch ;-)
> Hier die Liste der umgeleitenden Office PIA Assembly Redirects:
>
> [Office Primary Interop Assemblies]
> http://msdn.microsoft.com/en-us/library/15s06t57(VS.80).aspx
�h, ja und? Zwischen den Major Releases �ndert sich auch bei Project die
Assembly Version.
> Das Redirect ist ja normal f�r die 2003er Calls
> gedacht. Diese werden dann sauber auf 2007 umgeleitet.
Exakt:
| When a Visual Studio Tools for Office solution that references a
| Microsoft Office 2003 primary interop assembly runs on a computer that
| has the 2007 Microsoft Office version of the same primary interop
| assembly, the binding redirect assembly instructs the .NET Framework
| runtime to load the 2007 Microsoft Office version of the primary
| interop assembly.
> Office macht das also �berwiegend sauber.
Nochmal, das hat nichts mit sauber oder unsauber zu tun, sondern
gew�hrleistet lediglich, dass Anwendungen ohne �nderungen auch nach
Service Packs noch funktionieren. Daher �ndert Microsoft weder vom .NET
Framework noch von Office zwischen Service Packs oder Hotfixes die
Assembly Version.
Warum �ndert Microsoft die Assembly Version zwischen den Major Releases?
Ganz einfach: damit die Assemblyies Side-by-Side f�hig sind. Nur wenn
sich die Assembly Version �ndert, kann man beide Versionen gleichzeitig
z.B. im GAC haben.
Eine durchaus saubere Vorgehensweise ist daher z.B. diese hier:
1. Nur weil das Assembly sich �ndert, muss man nicht zwingend die
Assembly Version �ndern. Die File Version reicht. Windows Installer
benutzt diese z.B. um zu verhindern, dass man eine neuere Datei durch
eine �ltere ersetzt.
2. F�r kleine Bug Fixes und Service Packs w�rde ich Assembly Version
daher gleich lassen.
3. Bei gr��eren Releases, die nicht mehr zwingend kompatibel sind (z.B.
Typen oder Methoden entfernt, umbenannt etc) oder die ganze Features
nicht mehr enthalten, w�rde ich die Assembly Version �ndern.
Nachteil: funktioniert nicht so gut f�r agile Release Zyklen, wo es in
der Regel keine Unterscheidung zwischen gro�en und kleinen Releases
gibt. Dort handelt es sich ja eher um einen kontinuierlichen Strom von
vielen kleinen Releases.
Aber dieses Vorgehen generell als unsauber zu bezeichen, halte ich f�r
schlicht falsch.
--
Immo Landwerth
FrankDzaebel
>>>> BTW: in den überwiegenden Fällen macht es MS ja sauber,
>>>> etwa bei Office PIAs gehts sauber über Assembly Umleitung
>>>> per Policy.
>>> Das stimmt nicht.
>> Doch ;-)
>> Hier die Liste der umgeleitenden Office PIA Assembly Redirects:
> Äh, ja und? Zwischen den Major Releases ändert
> sich auch bei Project die Assembly Version.
Lies Dir genau meine Aussage oben durch, wo Du
fälschlich geantwortet hast, das "stimme nicht".
Aus Deinem Zitat aus meinem verlinkten Artikel
und den ja jetzt für Dich sichtbaren Policy-Assemblies,
die Office eben numal hat, denke ich, dass Du das jetzt
verstanden hast und wir nicht mehr über "stimmen" oder
nicht stimmen diskutieren müssen. Es stimmt. [Punkt]
Zur Info: die Umleitungs-Assemblies fangen mit "policy." an.
> sauber oder unsauber
dazu ggf. später mehr. Soviel aber schon mal ... wenn
Du extensiv Versions-Nummern mit unterschiedlichem Inhalten
gleich belässt (und dann noch ohne sauberes Assembly Redirect),
erzeugst Du etwas wie eine managed "DLL-Hölle". Das ist unsauber.
> Für kleine Bug Fixes und Service Packs würde
> ich Assembly Version daher gleich lassen.
"würde" ist Dein persönliches Empfinden. Das will ich Dir
nicht nehmen. Die MSI-Richtilinen geben klare Leitlinien vor,
wie Patches, Updates oder gar Servicepacks versioniert
werden sollten. Auch für Standard-VS-Setup-Projekte ist
häufig schon vorgegeben, wie Versions-Nummern-Änderungen
zu interpretieren sind. Macht man das anders muss man
ggf. stark manuell eingreifen. Mein "persönliches Empfinden"
hier: "Njet" ;-)
Immo Landwerth
> Lies Dir genau meine Aussage oben durch, wo Du
> f�lschlich geantwortet hast, das "stimme nicht".
Nein, meine Behauptung stimmt immer noch. Ich habe n�mlich nur
behauptet, dass sie sich zwischen _Service Packs_ nicht �ndern.
> Aus Deinem Zitat aus meinem verlinkten Artikel
> und den ja jetzt f�r Dich sichtbaren Policy-Assemblies,
Ja, zwischen Major Releases. Aber das hatte ich auch gar nicht in Frage
gestellt.
>> sauber oder unsauber
>
> dazu ggf. sp�ter mehr. Soviel aber schon mal ... wenn
> Du extensiv Versions-Nummern mit unterschiedlichem Inhalten
> gleich bel�sst (und dann noch ohne sauberes Assembly Redirect),
> erzeugst Du etwas wie eine managed "DLL-H�lle". Das ist unsauber.
Nat�rlich kann man sich damit auch in Fu� schie�en. Du hast das
allerdings pauschal als "unsauber" bezeichnet und das ist IMHO nicht in
voller Allgemeinheit der Fall. Man kann - Microsoft macht es vor -
durchaus sauber damit umgehen. Policy Files sind nur _eine_ M�glichkeit.
Beide M�glichkeiten (Assembly Version stabil lassen, Policy Files
verwenden) haben ihre Vor- und Nachteile. Welche man besser einsetzen
sollte, h�ngt von den Gegebenheiten ab.
> "w�rde" ist Dein pers�nliches Empfinden. Das will ich Dir
> nicht nehmen. Die MSI-Richtilinen geben klare Leitlinien vor,
> wie Patches, Updates oder gar Servicepacks versioniert
> werden sollten.
Selbstverst�ndlich, aber da steht nirgends, das man die Assembly Version
nach jeder �nderung eines Assemblies �ndern _muss_. Das w�re auch mehr
als sinnfrei.
--
Immo Landwerth
FrankDzaebel
> Nein, meine Behauptung stimmt immer noch.
Nein. Es ging um meine Aussage:
"[...] Office PIAs gehts sauber über Assembly
Umleitung per Policy".
wo Du "stimmt nicht" gesagt hast.
Das ist IMHO falsch. Aber ich habe auch keine Lust
auf Streits, dann lassen wir den Punkt einfach.
> Natürlich kann man sich damit auch in Fuß schießen.
> Du hast das allerdings pauschal als "unsauber"
> Man kann - Microsoft macht es vor - durchaus sauber
> damit umgehen. Policy Files sind nur _eine_ Möglichkeit.
Das "kann" findest Du in meinen Aussagen auch wieder.
Sogar das "überwiegend sogar berechtigt". Auch, dass
es nicht nur *eine* Möglichkeit gibt, sondern ich habe
ja sogar in meinem Link *mehr* Möglichkeiten angesprochen,
als die Du beispielsweise ansprachst. Es ist also alles
andere als pauschal. Das "pauschale" entspringt Deiner
Interpretation, bzw. hast Du evtl. einzelne Phrasen ohne
zugehörige Details herausgezogen.
> > "würde" ist Dein persönliches Empfinden. Das will ich Dir
> > nicht nehmen. Die MSI-Richtilinen geben klare Leitlinien vor,
> > wie Patches, Updates oder gar Servicepacks versioniert
> > werden sollten.
>
> Selbstverständlich, aber da steht nirgends, das man die Assembly Version
> nach jeder Änderung eines Assemblies ändern _muss_.
Wenn Du extensiv dieses Verfahren der Gleichlassung
von Versionen trotz Änderungen anwendest, erzeugst Du
eine managed DLL-Hölle. Deswegen - sehr vorsichtig damit.
Vor allen Dingen nicht "einfach" mal so. Dieses auch
mal ausnahmsweise "pauschal".
Thorsten Doerfler
FrankDzaebel schrieb:
>> F�r kleine Bug Fixes und Service Packs w�rde
>> ich Assembly Version daher gleich lassen.
>
Was haben die MSI Richtlinien mit der Assembly Versionierung zu tun?
Thorsten D�rfler
--
Microsoft MVP Visual Basic
vb-hellfire visual basic faq | vb-hellfire - einfach anders
http://vb-faq.de/ | http://www.vb-hellfire.de/
Frank Dzaebel
>>> F�r kleine Bug Fixes und Service Packs w�rde
>>> ich Assembly Version daher gleich lassen.
>>
>> Die MSI-Richtilinen geben klare Leitlinien vor
>
> Was haben die MSI Richtlinien mit der Assembly Versionierung zu tun?
Wenn Du zum Beispiel MSI-basierte Installer [z.B. VS 2008 Setup]
benutzt
und die Datei-Version der Assembly im MSI und auf dem Kundenrechner
gleich ist, w�rde die zu installierende Assembly standardm��ig *nicht*
auf diesem ge-updated werden (auch wenn sie anderen Inhalt h�tte oder
neuer w�re).
Netter Nebeneffekt, man w�rde das nicht mal an der Dateiversion
merken k�nnen, da die ja gleich ist. Der Installer "merkt", dass die
Version
bereits da ist und installiert diese gar nicht erst.
Thorsten Doerfler
Frank Dzaebel schrieb:
>>>> F�r kleine Bug Fixes und Service Packs w�rde
>>>> ich Assembly Version daher gleich lassen.
>>> Die MSI-Richtilinen geben klare Leitlinien vor
>> Was haben die MSI Richtlinien mit der Assembly Versionierung zu tun?
>
> Wenn Du zum Beispiel MSI-basierte Installer [z.B. VS 2008 Setup]
> benutzt und die Datei-Version der Assembly im MSI und auf dem Kundenrechner
> gleich ist, w�rde die zu installierende Assembly standardm��ig *nicht*
> auf diesem ge-updated werden (auch wenn sie anderen Inhalt h�tte oder
> neuer w�re).
MSI interessiert sich aber nicht f�r die AssemblyVersion, sondern nur
f�r die AssemblyFileVersion. Letztere wird aber nur dann automatisch auf
die AssemblyVersion gesetzt, wenn dieses Assembly Attribut nicht in der
AssemblyInfo.cs enthalten ist. By default sind hier aber beide Attribute
angegeben und wenn man jetzt die AssemblyVersion bspw. automatisch
generieren l�sst "1.0.*", was ich pers�nlich als ein sehr fragw�rdiges
Vorgehen und Feature betrachte, bleibt AssemblyFileVersion unver�ndert
"1.0.0.0".
Ich pers�nlich halte es da ganz genauso, wie Immo, die AssemblyVersion
nur bei Major-Releases/Breaking Changes zu ver�ndern. Die
AssemblyFileVersion wird dagegen mit jedem Release angepasst, damit
diese auch bei der Installation aktualisiert werden.
Frank Dzaebel
>> Wenn Du zum Beispiel MSI-basierte Installer [z.B. VS 2008 Setup]
>> benutzt und die Datei-Version der Assembly im MSI und auf dem
>> Kundenrechner
>> gleich ist, w�rde die zu installierende Assembly standardm��ig
>> *nicht*
>> auf diesem ge-updated werden (auch wenn sie anderen Inhalt h�tte
>> oder
>> neuer w�re).
>
> MSI interessiert sich aber nicht f�r die AssemblyVersion,
> sondern nur f�r die AssemblyFileVersion.
Genau, so meine Beschreibung, wenn Du oben liest.
Dort steht: "Datei-Version". AssemblyFileVersion ist nur
ein Attribut, Du meinst eigentlich die Win32 *Datei*versionsressource.
Aber Du fragtest danach, deswegen habe ich es Dir als Beispiel
erkl�rt.
> bleibt AssemblyFileVersion unver�ndert "1.0.0.0".
diese "AssemblyFileVersion" (gibt es so eigentlich nicht,
denn das ist nur ein Attribut) unver�ndert zu lassen w�re
grob fahrl�ssig. Das w�rde dann auch andere Installer
als nur MSI Technologie betreffen.
Ich weiss ja was Du meinst, aber man muss etwas mit den
Begrifflichkeiten aufpassen. AssemblyFileVersion ist nur das
Attribut (normal) in der AssemblyInfo.cs. FileVersionInfo w�re
schon ein besserer Ausdruck denn es ist ja letztlich eine
reine Win32 Dateiversionsressource.
> Ich pers�nlich halte es da ganz genauso, wie Immo, die
> AssemblyVersion nur bei Major-Releases/Breaking
> Changes zu ver�ndern.
Du, jeder soll das pers�nlich so machen, wie er es f�r
gut befindet - wie gesagt, ich halte die Versionierung
bei MS im Gro�en und Ganzen auch f�r angemessen
(dies wurde ja mehrfach erw�hnt) - ok, hier und da gibt
es Kritik. Ich gebe nur Warnungen, welche Szenarien dann
in Richtung DLL-H�lle gehen k�nnten.
Breaking Changes w�re ja die *absolute* Mindest-
Anforderung - sonst w�rden ja gar sogar Methoden
komplett fehlschlagen. Dinge wie Patch, Upgrade, Hotfix,
Minor Update, etc. sind terminologisch und technisch halt von MSI
vorgepr�gt (und es gibt einige weitere ;-), sodass oft ganz
bestimmte Weitergabe-Szenarien im MSI angedacht sind.
Hier mal ein Auszug, um Dir das vielleicht klarer zu machen:
[Patching and Upgrades (Windows)]
http://msdn.microsoft.com/en-us/library/aa370579(VS.85).aspx
> AssemblyFileVersion wird dagegen mit jedem Release
> angepasst, damit diese auch bei der Installation aktualisiert
> werden.
Besser IMHO bei "jeder" �nderung die ggf. irgendwie nach "aussen"
kommen kann (aussen kann auch z.T. innen sein, also IMHO eher
immer), nicht nur bei Releases (es gibt sonst gen�gend M�glichkeiten,
wie es schief l�uft). Vielleicht hast Du aber mit "Release" auch
Beta-Versionen und Minor-Upgrades etc. subsummiert, dann w�ren
wir wieder einer Meinung.
Wichtig ist auch wie denn Deine App nun die Assembly l�dt.
Assembly-Load, LoadFrom etc. k�nnen ja in dynamischen
Szenarien sehr wichtig sein.
Egal, ich denke, jeder hat seinen Deployment-Kontext und
m�gliche Fallstricke sind auch klarer geworden.
Thorsten Doerfler
Frank Dzaebel schrieb:
> ein Attribut, Du meinst eigentlich die Win32 *Datei*versionsressource.
AssemblyFileAttribut ist *das* Attribut, das sich nach "au�en" als
Dateiversion pr�sentiert, wohingegen AssemblyVersion ein internes
Attribut der .NET Framework Infrastruktur bleibt, das normal (aus
Win32-Sicht, um bei Deiner Begrifflichkeit zu bleiben) nicht nach au�en
sichtbar ist. Eben auch nicht f�r den Installer. Daher meine Frage,
inwieweit diese den Installer interessiert. Aber das ist ja nun gekl�rt.
>> AssemblyFileVersion wird dagegen mit jedem Release
>> angepasst, damit diese auch bei der Installation aktualisiert
>> werden.
>
> Besser IMHO bei "jeder" �nderung die ggf. irgendwie nach "aussen"
> kommen kann (aussen kann auch z.T. innen sein, also IMHO eher
> immer), nicht nur bei Releases (es gibt sonst gen�gend M�glichkeiten,
> wie es schief l�uft). Vielleicht hast Du aber mit "Release" auch
> Beta-Versionen und Minor-Upgrades etc. subsummiert, dann w�ren
> wir wieder einer Meinung.
Yep, Release meint alles was nach au�en oder innen zwecks Testing etc. geht.
Frank Dzaebel
>> Dort steht: "Datei-Version". AssemblyFileVersion ist nur
>> ein Attribut, Du meinst eigentlich die Win32
>> *Datei*versionsressource.
>
> AssemblyFileAttribut ist *das* Attribut, das sich nach "au�en" als
> Dateiversion pr�sentiert,
Du meinst AssemblyFileVersion. AssemblyFileAttribut gibt es ja nicht.
Auch AssemblyFileVersionAttribute w�re eine Variante.
Und bzgl. "Datei-Version" sind wir ja einer Meinung.
Damit nicht der Eindruck entsteht, die "AssemblyVersion" w�rde nicht
nach "au�en" pr�sentiert (hast Du explizit ja nicht so gesagt und
wei�t
das nat�rlich auch) hier noch der Hinweis:
Nat�rlich pr�sentiert sich die AssemblyVersion auch nach "au�en" und
ist f�r .NET Framework bezogene Identit�ts- und Bindungs-Themen
sowie f�r die Versionsrichtlinien von gro�er Bedeutung und *die*
Gr��e.
Das AssemblyFileVersion-Attribut spielt f�r die Identit�t vom .NET
Framework aus gesehen keine Rolle, sondern das
AssemblyVersion-Attribut.
___________
Trotzdem nochmal zur�ck zum Thema:
"AssembyVersion gleichlassen bei Updates *unsauber*?"
Vikas Goyal [MVP] hat hier ~vielleicht in unser aller Sinne
ganz treffend kompromisshaft zusammengefasst:
[How to use Assembly Version and Assembly File Version]
http://support.microsoft.com/kb/556041/en-us
Indem er in einem Szenario eines *t�glichen* Assembly-Updates
eine Gleichlassung der Assembly-Version toleriert.
Aber in wirklichen Releases, die nach au�en kommen zu einer
�nderung der 'Assembly Version' r�t (bzw. Angleichung an die
'Assembly File Version').