Assemblies und deren Versionen in VB.NET Dieser Workshop erläutert die Vorgehensweise beim Erstellen und Verteilen eigener Assemblies (DLL's) auf den Endkundensystemen und zeigt, auf was geachtet werden muss, wenn man unterschiedliche Versionen einer DLL erstellt und verteilt (Stichwort Kompatibilität einer DLL).
Autor:  Oliver Greiner	Bewertung:     [ Jetzt bewerten ]	Views:  22.060

Geben Sie hier Ihre persönliche Bewertung ab! Anzahl Bewertungen bisher: 16 Bewertung insgesamt: gut Durchschnittliche Bewertung: 4.2 von 5 Sternen

sehr gut     gut     nützlich     mittelmäßig     mangelhaft

Einleitung
Wer bisher in VB 6 Programmiert hat, muss bei der Umstellung auf VB .Net komplett umdenken.
Die Behandlung von Dll´s gestalltet sich ein wenig anders. Auch die bekannte Binärkompatibilität gibt es in .Net nicht mehr. Bei der Umstellung von VB 6 auf VB .Net haben sich so einige Fragen aufgeworfen, die sich leider nicht immer sofort mit einem zufriedenstellenden Ergebnis sich beantworten ließen. Wie z. B. die Sache mit den unterschiedlichen Versionen einer Dll???

Also hab ich mich im Netz auf die Suche gemacht und einige Zeit mit Recherchen verbracht um diese Fragen beantworten zu können und ich bin fündig geworden.
Ich hab das ganze mal zusammengefasst und mit eigenen Worten beschrieben, wie sich das ganze verhällt.

Wer in VB 6 ActiveX Dll´s entwickelt, behandelt die unterschiedlichen Versionen über die Binärkompatibilität. Nur, auf die Gefahr hin das ich mich wiederhole, die Binärkompatibilität gibt es so, wie es in VB 6 war, in .Net nicht mehr.
Genauso wie die Entwicklung von COM Objekten. Diese wird zwar noch unterstützt, ist aber nicht im Sinne des .Net Frameworks.
Das Framework soll nach und nach die COM´s ablösen. Das hin und wieder noch COM Objekte verwendet werden müssen, weil diese noch nicht umgestellt sind oder der Aufwand diese umzustellen zu gross wäre, ist nicht weiter tragisch. Ist ja auch noch möglich. Nur wer weis wie lange noch. Im Zuge der Weiterentwicklung von .Net Sprachen werden die COM Objekte nach und nach ganz verschwunden sein. Es wird auch so sein das diejenigen, die immer noch in VB 6 unterwegs sind, was ja auch gar nicht schlimm ist, aber dennoch dazu gezwungen werden umzusteigen, weil denjenigen von einem gewissem Heersteller gar keine andere Wahl gelassen wird.

Assemblies bilden die grundlegenden Bausteine des .Net Frameworks. Diese können aus ausführbaren Dateien(exe) oder Dynamik Link Lybraries(DLL) bestehen. Ein in VB .Net erstelltes Assembly lässt sich über die Interoperabilität problemlos in anderen .Net Programmiersprachen verwenden, umgekehrt geht's genauso. Assemblies liefern der Common Language Runtime(CLR) Informationen die zum Erkennen der Typimplementierungen notwendig sind. Man kann sich ein Assembly als eine Auflistung von Ressourcen und Typen vorstellen, die eine Einheit bilden und für ein Zusammenwirken konzipiert sind. Ein in VB .NET erstelltes Assembly unterscheidet sich kaum von den Typbibliotheken in älteren VB Versionen. Der einzige unterschied gegenüber Exe und Dll Dateien aus früheren Windows Versionen besteht darin, dass Assemlys in .Net zusätzlich zu den Informationen einer Typbibliothek noch alle anderen wichtigen Informationen zum Ausführen einer Anwendung oder Komponente enthällt und: Ein in .NET erstelltes Assembly wird nicht registriert, so wie es bei den COM Objekten in älteren VB Versionen der Fall war. Dies ist auch nicht nötig, da das ganze über den Global Assembly Cache (GAC) geregelt wird. Dazu gleich mehr.

Assemblymanifest
Jedes erstellte Assembly erhält so eine Art Inhaltsverzeichnis, das Assemblymanifest mit Informationen über:

• Name, Version(Die Identität)
   
• Eine Tabelle mit Informationen über die übrigen Dateien, aus denen das Assembly besteht.
  Weitere Dateien, auf dem das Assembly beruht, Bitmap und Infodateien.
   
• Eine Verweisliste auf andere Assemblies, also Abhängigkeiten- DLL´s, die nicht von euch erstellt worden sind.

Global Assembly Cache(GAC)
Alle Assemblies, die sich im GAC befinden, sind globale Objekte, die für andere Anwendung sichtbar sind. Der GAC ist vergleichbar mit dem System32, das in früheren VB Versionen der zentrale Anlaufpunkt für Dll´s, OCX und Typelibs war bzw. immer noch ist. Der Visual Basic Namespace ist ein Beispiel für eine Assembly aus dem globalen Assemblycache. Private Objekte müssen sich auf gleicher Ebene oder unterhalb des Verzeichnisses befinden, in dem die Anwendung installiert ist.

Also: globale Assemblies gehören in den GAC installiert und private ins Anwendungsverzeichnis.
Wie Ihr das letztendlich regelt ist eure Sache.
Nachzulesen unter:  http://msdn.microsoft.com/de-de/library/bb979105.aspx

Nun zum GAC:
Dieser ist vergleichbar mit dem System32. Nur verhält dieser sich etwas anders. Während im System32 befindliche Dateien nur einmal mit gleichem Namen existieren können, kann der GAC mehrere Dateien mit gleichen Namen und unterschiedlichen Versionen verwalten (so viel zur Binärkompatibilität). Es ist vollig egal, wie oft sich ein Assembly mit gleichm Namen und unterschiedlichen Versionen im GAC befindet. Die Commom Language Runtime (CLR) nimmt die Version, auf die eure Anwendung verweist.

Die CLR beginnt zur Laufzeit nach dem angeforderten Assembly zuerst im GAC zu suchen ob sich dort ein passendes Assembly befindet, und wenn ja, wird dieses benutzt. Falls dort nicht vorhanden, wird in der Verzeichnissebene der installierten Anwendung gesucht.
Ihr könnt euch den GAC auch mit dem Dateiexplorer ansehen. Dieser befindet sich im %Windir%\assembly. Schaut ihn euch an, dort findet ihr alle globalen Assemblies vom .Net Framework und derer anderer Anwendungen, die auf dem .Net Framework basieren.

Es bleibt letztendlich euch überlassen, wie ihr das handhabt, ob ihr euer Assembly global zur Verfügung stellt oder private im Anwendungsverzeichnis.

Nur!!!
Assemblys, die sich im GAC befinden, müssen mit einem StrongName ausgestatet sein. Dieser enthält einmal den PublicKeyToken und den PrivateKey. Assemblies im GAC gelten grundsätzlich als sicher, sie sind digital signiert. Das bedeutet, es müssen keine security Checks mehr beim Laden stattfinden. Die Assemblies sind vorkompiliert, das heißt: Der JIT Compiler muss kein Native Image erzeugen, da dieses im GAC schon vorliegt.

Ein kleines Beispiel:

Anwendung A benötigt die Datei, ich nenne diese jetzt mal myDll.dll, der Version 1.0.0.0
Anwendung B benötigt diese myDll.dll auch, aber mit der Version 1.0.0.1. Da diese für die Funktionalität der Anwendung B erweitert wurde.

Unter VB 6 oder älteren Versionen habt ihr das über die Binärkompatibilät geregelt und die Dll ins System32 kopiert, die ältere Version ersetzt und am COM Server mit regsvr32.exe angemeldet.
Durch die Binärkompatibilität funktionierte Anwendung A weiterhin und Anwendung B mit den neuen Funktionen der myDll.dll.

Bei .Net könnt Ihr das gänzlich vergessen.
Entweder ihr Installiert das Assembly in den GAC oder ihr belasst die Dll privat im Anwendungsverzeichnis. Installiert Ihr die neue Version unserer myDll in den GAC, habt ihr somit zwei Dateien der myDll dort liegen, jedoch mit unterschiedlichen Versionsnummern. Die CLR weiß, welche sie sich holen muss, egal ob Anwendung A oder Anwendung B gestartet wird, da sich die Information auf die verweisende Dll in der Manifest der Anwendung befindet.

Es besteht natürlich auch die Gefahr, sich den GAC zu zu müllen. Mal angenommen, eure Anwendung A wird im Funktionsumfang erweitert und die myDll.dll der Version 1.0.0.0 reicht nicht mehr aus. Ihr müsst jetzt eine neue Version dieser Dll erstellen und kompiliert eure Anwendung A gegen die myDll.dll Version 1.1.0.0. Somit habt ihr jetzt eine dritte Version der Dll. Ihr Installiert diese auf dem Zielsystem, wo auch Anwendung B noch läuft. Anwendung A wird jetzt gegen die neue ausgetauscht. Die neue Version der myDll.dll wird in den GAC installiert. Schaut ihn euch an.
Ihr habt jetzt mittlerweile drei unterschiedliche Versionen der myDll.dll im GAC liegen.

Anwendung B arbeitet wie gewohnt mit der Version 1.0.0.1. Anwedung A aber jetzt mit der Version 1.1.0.0 der myDll.dll. Was ist jetzt mit der Version 1.0.0.0 ???? Gar nichts! Die bleibt dort einfach liegen und wird nicht genutzt. Man kann sich vorstellen, wie der GAC dann aussieht, wenn man das oft genug macht.
Ihr müsst euch selbst darumm kümmern, wie ihr mit veralteten Versionen verfahrt.

Eine Möglichkeit ist, das Ganze ohne den GAC zu erledigen. Das heißt also, eure Dll im Anwendungsverzeichnis zu lassen (Private Object). Die Nachteile habe ich ja ein par zeilen oberhalb schon beschrieben. Aber der Vorteil ist auch, dass ihr gar nichts mehr installieren müsst. Es reicht dann aus, einfach die Dateien im Anwendungsverzeichnis auszutauschen, Exe, Dll usw.
Soll ja eigentlich auch der Sinn des Frameworks sein, dass Anwendungen durch einfaches Kopieren auf das Zielsystem portiert werden können, ohne irgendwas installieren zu müssen.

Nutzt Ihr den GAC kommt ihr um eine Installationsroutine nicht herum. Ihr müsst nämlich eure Dll´s in den GAC installieren. Ein einfaches Kopieren reicht da nicht aus.
Also eine Assembly Dll durch Copy & Paste in den GAC einzufügen geht nicht. Man kann zwar per Drag & Drop die Datei aus einem Explorer Fenster in den GAC hinein verfrachten. Aber welcher Endanwender kann und will so etwas. Gute Installationsprogramme erledigen das für euch.

Installation in den Global Assembly Cache(GAC)
Genug mit diesem trockenem Gerede. Kommen wir endlich zur Sache!
Ich spreche hier ja immer von der Installation in den GAC. Das voliegende Beispiel soll das mal veranschaulichen.

Zunächst benötigt ihr zwei kleine Tools: GACutil.exe und SN.exe
Diese findet ihr bei Installierten Framework unter :

C:\Programme\Microsoft  SDKs\Windows\v6.0A\bin

Der Ordner v6.0A ist natürlich abhängig von eurer Installation des Frameworks.

Alternativ zum GACutil.exe gibt es ein frei zur Verfügung stehendes Programm (WinGac), das das GACutil mit einer GUI zur verfügung stellt.
Zu finden unter:  http://iridescence.no/post/WinGacaGUIfortheGlobalAssemblyCache.aspx

Für Sn.exe, also StrongName.exe, hab ich noch nichts gefunden. Kurz, ich hab mir dann selbst eines erstellt:
Download hier:  sn.zip (122 KB)

SN.exe braucht man aber nicht unbedingt. Man kann sich über die Projekteigenschaften\Signierung eine neue Schlüsseldatei von VB erstellen lassen.

Um das Ganze mal zu testen, erstellen wir ein neues Projekt vom Typ Klassenbibliothek.
Vergebt den Namen myDll.
Class1.vb nennt ihr um in CSystem.vb. Speichert das ganze Projekt.

Wir nutzen einfach mal die Klasse CSystem um eine Guid zu erstellen.
Das ist z. B. ein Vorteil von .NET. Während ihr bei VB 6 API-Aufrufe einbinden musstet, um ein Guid zu erstellen, liefert das .NET Framework solche Funktionen schon verpackt in Objekte. Es bedarf keinen API-Aufruf mehr.

Quelltext der Klasse
Ich habe hier Shared Funktionen genutzt, damit ich diese direkt über den Namespace aufrufen kann und kein Objekt von CSystem erzeugen muss. Und wenn wir schon dabei sind, überladen wir die Funktion CreateSystemGuid noch. Letztendlich ist es egal, was ihr da reinpackt. Es geht hier nur darum, wie man mit den Versionen von Assemblies umgeht und die Installation in den GAC bzw. alternativ die Verwendung des Assembly im Anwendungsverzeichnis.

Imports System
Public Class CSystem
  Implements IDisposable
 
  ' So ermitteln Sie überflüssige Aufrufe
  Private disposedValue As Boolean = False
 
  ''' <summary>
  ''' Erzeugt eine System Guid
  ''' </summary>
  ''' <returns>String mit der erzeugten Guid</returns>
  Public Overloads Shared Function CreateSystemGuid() As String
    Return Guid.NewGuid.ToString
  End Function
 
  ''' <summary>
  ''' Erzeugt eine System Guid. Hier kann nocht gewählt werden, 
  ''' ob die Sonderzeichen entfernt werden sollen
  ''' </summary>
  ''' <param name="StripSlashes"></param>
  ''' <returns>String mit der erzeugten Guid 
  ''' mit/ohne Sonderzeichen</returns>
  Public Overloads Shared Function CreateSystemGuid( _
    ByVal StripSlashes As Boolean) As String
 
    Dim sGuid As String = Guid.NewGuid.ToString
    Dim sTempGuid As String = ""
 
    If (StripSlashes) Then
      For i As Int32 = 1 To sGuid.Length
        If Not Mid(sGuid, i, 1) = "{" And _
          Not Mid(sGuid, i, 1) = "}" And _
          Not Mid(sGuid, i, 1) = "-" Then
 
          sTempGuid = sTempGuid & Mid(sGuid, i, 1)
        End If
      Next i
      Return sTempGuid.ToString
    Else
      Return sGuid.ToString
    End If
  End Function
 
  ' IDisposable
  Protected Overridable Sub Dispose(ByVal disposing As Boolean)
    If Not Me.disposedValue Then
      If disposing Then
        Dispose()
        ' TODO: Anderen Zustand freigeben (verwaltete Objekte).
      End If
 
      ' TODO: Eigenen Zustand freigeben (nicht verwaltete Objekte).
      ' TODO: Große Felder auf NULL festlegen.
    End If
    Me.disposedValue = True
  End Sub
 
#Region " IDisposable Support "
  ' Dieser Code wird von Visual Basic hinzugefügt, um das 
  ' Dispose-Muster richtig zu implementieren.
  Public Sub Dispose() Implements IDisposable.Dispose
    ' Ändern Sie diesen Code nicht. Fügen Sie oben in Dispose
    ' (ByVal disposing As Boolean) Bereinigungscode ein.
    Dispose(True)
    GC.SuppressFinalize(Me)
  End Sub
#End Region
 
  Public Sub New()
    MyBase.New()
  End Sub
 
  Protected Overrides Sub Finalize()
    Dispose(True)
    MyBase.Finalize()
  End Sub
End Class

Assembly Informationen der Dll
Zu finden im Menü unter Projekt \Eigenschaften
Wählt dann das Register Anwendung und klickt auf Assemblyinformationen.

Die Versionen müsst ihr hier von Hand erhöhen. Für den GAC ist die Assemblyversion wichtig, die Dateiversion nicht.
Die Assemblyversion kann auch Automatisch erhöht werden, indem ihr die Datei AssemblyInfo.vb öffnet und den Eintrag

<Assembly: AssemblyVersion("1.0.0.0")>

ändert. Der dann so aussieht:

<Assembly: AssemblyVersion("1.0.*")>

Jedes mal, wenn ihr die Dll erstellen lasst, wird die Assemblyversion automatisch erhöht.
Belasst die Assemblyversion auf 1.0.0.0. Wir erhöhen diese später von Hand.

Wechselt jetzt in den Projekteigenschaften auf „Signierung“. Setzt ein Häckchen bei „Assembly Signieren“.

Wählt in der ComboBox „Neu“ und gebt den Dateinamen an. Alternativ kann man die snk datei mit Kennwort schützen.

Bestätigt mit „OK“
Es wird im Projektverzeichnis eine Datei mit myDll.snk erzeugt.
Erstellt die Dll. Diese wird jetzt anhand der erstellten Schlüsseldatei mit einem StronName versehen und digital signiert.

Die erstellte Dll befindet sich jetzt im Projektverzeichnis\bin\release.
Belasst sie erstmal dort.
Nun öffnet das Tool WinGac.

Klickt auf „Install“ und öffnet die Dll.

WinGac installiert jetzt die myDll.dll in den GAC und quitiert das Ganze mit:

Bestätigt diesen Dialog mit „OK“.

Wir wollen sehen, wo unsere Dll abgeblieben ist. Gebt einfach ein “my“ im Textfeld ein, um alle Assemblies, die mit „my“ beginnen, zu filtern. Da ist sie, unsere myDll.dll, die wir gerade in den Cache installiert haben.

Mit allen Informationen: Name der Datei, Assemblyversion, Prozessorarchitektur, Kompatibilitätsmodus und der volle Name mit dem PublicKeyToken, den wir mit der Vergabe des starken Namens über die Datei myDll.snk vergeben haben. Zum Vergleich schauen wir nochmal im Cache nach:

Ihr findet sie auch dort.

Nachdem wir die Dll erstellt haben und in den Cache Installiert haben, wollen wir diese auch nutzen.

Startet eure VB IDE, erstellt ein neues Projekt des Typs „Windows Forms Anwendung“ und vergebt den Namen myTestAppA. Speichert das Projekt. Kopiert die Dll aus dem Releaseverzeichnis ins Bin\Debug Verzeichnis unserer Test Anwendung. Ich kopiere die dll deshalb dahin, weil es ja die zwei Möglichkeiten wie vorher beschrieben gibt, die dlls aus dem Cache zu holen oder aus der Anwendungsebene. Ich möchte gleich noch nachweisen können, dass die Exe auch läuft, wenn die Dll nicht mehr im Anwendungsverzeichnis liegt, sondern in den Cache Installiert wurde.

Öffnet die Projekteigenschaften der Testanwendung und geht auf „Verweise“. Klickt auf „Hinzufügen“ und wählt „Verweis“ aus. Es öffnet sich folgender Dialog:

Sucht im .Net Register nach unserer Dll myDll.
Hab Ihr sie gefunden???

Nein!!!

Sie befindet sich zwar im Global Cache, wird aber in der Assembly-Liste nicht aufgeführt. Ihr müsst die Dll zur Entwurfszeit vom lokalen Speicherort aus einbinden.
Nun warum ist das so, oder die Frage, die sich jetzt einige stellen: Was habe ich dann vom Global Cache??!!

Der Global Cache ist nur für die Laufzeit wichtig, nicht für die Entwurfszeit. Sobald euer Programm läuft, sucht die CLR nach dem angeforderten Assembly im Cache.

Ihr müsst die Dll immer noch referenzieren, auch wenn sie im GAC ist. Sonst müsste eure Anwendung zur Entwurfszeit immer automatisch alle Assemblies, die im GAC sind, laden, damit sie sofort zur Verfügung stehen. Und wenn ihr euch mal den GAC anschaut, wieviel da drinn ist! Es werden nur die aufgelistet, die vom Vorlagendesigner vorgesehen sind. Natürlich die, die mit der Installation des Frameworks ausgeliefert werden. Auf meinem System sind knapp 500 Assemblies. Mein RAM wird sich freuen, wenn diese alle automatisch geladen werden müssten, damit sie sofort zur Verfügung stehen. Das ist einiges an Speicher, die der Entwicklungsrechner zur Verfügung stellen müsste.

Zur Laufzeit sieht das ganze dann anders aus. In der Manifest der Testanwendung steht drin, welche Assembly er laden soll und die CLR lädt diese dann anhand des starken Namen aus dem Cache.

Geht auf Register „Durchsuchen“ und wählt die Dll von ihrem Speicherort aus.

Mit „OK“ wird der Verweis gesetzt.

Wie ihr hier sehen könnt, steht unter TYP „.net“. Weil es ein Assembly ist und kein COM. Wenn ihr Com einbindet steht unter TYP „COM“. Durch das gesetzte Häckchen bei den importierten Namespaces braucht es keine Importsanweisung oder dass der Namespace vorangesetzt wird.

Erstellt einen Button auf der Form und gebt folgendes im Klick Event ein:

Public Class Form1
 
  Private Sub Button1_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles Button1.Click
 
    MsgBox(CSystem.CreateSystemGuid())
    ' myDll braucht hier nicht vorangesetzt werden
    ' da der NameSpace beim Verweisvorgang gesetzt werden kann
  End Sub

Startet das Programm und Testet!

Das Ergebnis aus der Funktion CSystem.CreateSystemGuid(), welche die Dll beinhaltet und zurück gibt.

Erstellt nun eure Anwendung. Jetzt befinden sich folgende Dateien im Debug Verzeichnis inklusive unserer Dll, die wir vorher dort hinein kopiert haben.

Startet die myTestAppA.exe. Es folgt das gleicher Ergebnis.
Und jetzt geht ihr hin und löscht die Datei myDll.dll aus dem Anwendungsverzeichnis.
Startet die Exe erneut und ihr erhaltet trotzdem das gleiche Ergebnis wie zuvor.

Die Anwendung läuft immer noch ohne Fehler. Ja natürlich, das Assembly wurde jetzt auch zur Laufzeit aus dem GAC geladen und nicht aus dem Anwendungsverzeichnis.

Eure VB IDE meckert jetzt natürlich, da die Dll, auf die verwiesen wird, fehlt. Kopiert sie wieder zurück.

Nun zur neuen Version von myDll.dll
Öffnet wieder das myDll Projekt. Erweitert die Klasse CSystem um :

  ''' <summary>
  ''' Funktion zeig Hallo Welt die erste
  ''' </summary>
  ''' <returns>String</returns>
  Public Shared Function HelloWorld1() As String
    Return "Hallo Welt die Erste"
  End Function

Ändert die Assembly Version:

Erstellt die Dll und installiert diese mit WinGac in den Global Cache:

Jetzt haben wir zwei Dll´s mit gleichem Namen - aber mit unterschiedlichen Versionen.

Startet ein neues Projekt mit dem Namen „myTestAppB“. Kopiert die neu erstellte Dll mit der Version 1.0.0.1 ins Debug verzeichnis der Anwendung B. Setzt den Verweis.

Erstellt auf der Form1 zwei Buttons. Im Klick Event des Buttons 1 lassen wir uns wieder eine Guid erzeugen. Im Klick Event von Button 2 lassen wir uns dann das "Hallo Welt die Erste" ausgeben.

Public Class Form1
  Private Sub Button1_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles Button1.Click
 
    MsgBox(CSystem.CreateSystemGuid)
  End Sub
 
  Private Sub Button2_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles Button2.Click
 
    MsgBox(CSystem.HelloWorld1)
  End Sub
End Class

Erstellt nun die Anwendung „myTestAppB“ und testet das ganze mal.
Beim Klick auf Button 1 bekommt ihr weiterhin eine Guid ausgegeben. Bei Button 2 das "Hallo Welt."

Jetzt geht hin und löscht die Dll aus dem Debugverzeichnis der myTestAppA und aus dem Debugverzeichnis myTestAppB. Startet beide Exe. Beide Anwendungen laufen jetzt parallel, wobei beide Anwendung auf die myDll verweisen, jedoch unterschiedlicher Assemblyversionen.

Fazit
Beide Anwendungen laufen. Muss ja. Anwendung A ist gegen die Version 1.0.0.0 erstellt worden.
Diese Assemblyversion befindet sich im GAC. Anwendung B ist gegen die erweiterte Version 1.0.0.1 erstellt worden.
Auch diese befindet sich im GAC. In beiden Manifestdateien der Anwendungen steht geschrieben, welche Assembly Version benötigt wird. Die CLR sucht im GAC nach der Verwiesenen Version und lädt diese.

Das Gegenteil könnt ihr testen, indem ihr die beiden Dll´s aus dem GAC deinstalliert, die Version 1.0.0.0 ins Debugverzeichnis von Anwendung A legt und die 1.0.0.1 ins Debugverzeichnis von Anwendung B.

Setzt dementsprechend die Verweise. Ihr werdet feststellen, dass im Verweisfenster dann bei Lokaler Kopie „True“ steht. Sie ist ja nicht mehr im GAC installiert und wird nur noch lokal vom Speicherort aufgerufen. Startet beide Exe. Auch diese laufen beide parallel.

Wie schon gesagt, es bleibt euch überlassen, wie ihr mit den unterschiedlichen Versionen umgeht oder diese verwaltet, da ja jetzt mehrere Versionen ein- und derselben Datei verwendet werden können und nicht nur eine, wie es bei älteren Versionen und dem System32 der Fall war.