Bekannte Probleme bei der Verwendung von Microsoft Visual Studio 2005 Express-Editionen

Bekannte Probleme bei der Verwendun...

Veröffentlicht: 03. Aug 2006

In diesem Dokument werden bekannte Probleme aufgelistet, die bei der Verwendung von Microsoft Visual Studio 2005 Express-Editionen auftreten können. Informationen zu Problemen bei der Produktinstallation finden Sie in Infodatei: Setup-Probleme bei Microsoft Visual Studio 2005 Express Edition

Eine Liste mit den neuesten Änderungen zwischen Beta 2 und RTM finden Sie unter http://go.microsoft.com/fwlink/?LinkId=51223.

Die neuesten Informationen zu bekannten Problemen bei Visual Studio 2005 Express finden Sie online unter http://go.microsoft.com/fwlink/?LinkId=51325.

Auf dieser Seite

1. Alle Express-Editionen
2. Visual C# Express
3. Visual Basic Express
4. Visual J# Express
5. Visual C++ Express
6. .NET Framework
7. MSDN Express
8. Visual Studio Integrated Development Environment (IDE, Integrierte Entwicklungsumgebung)
9. Visual Web Developer Express

1. Alle Express-Editionen

1.1 Wenn eine Datei erneut in den Editor geladen wird, werden Codierungsänderungen möglicherweise nicht angezeigt

Visual Studio 2005 erkennt keine geänderte Codierung, wenn eine Datei erneut geladen wird. Wenn Sie die Codierung einer Datei außerhalb des aktuellen Editors geändert haben oder einen Quellcode-Verwaltungsvorgang ausgeführt haben, bei dem die Codierung einer im Editor geöffneten Datei geändert wurde, wird die Datei automatisch erneut von Visual Studio geladen. Nach dem erneuten Laden der Datei im Editor wird der Dateiinhalt möglicherweise nicht korrekt angezeigt.

So beheben Sie dieses Problem

Schließen Sie die Datei, ohne die Änderungen zu speichern.
Klicken Sie im Menü Datei auf Öffnen, und wählen Sie anschließend Datei aus.
Klicken Sie im Dialogfeld Datei öffnen auf den Pfeil, der neben der Schaltfläche Öffnen angezeigt wird, und klicken Sie dann auf Öffnen mit.
Wählen Sie im Dialogfeld Öffnen mit den Editor (z. B. den Binär- oder den Ressourcen-Editor) aus, in dem die Datei geöffnet werden soll. Um eine Datei mit einer besonderen Codierung zu öffnen, wählen Sie einen Editor mit Codierungsunterstützung aus, z. B. XML-Editor mit Codierung.
Klicken Sie auf OK.
Wählen Sie im Dialogfeld Codierung in der Dropdownliste Codierung die entsprechende Codierung aus.
Klicken Sie auf OK.

1.2 Ausnahmen von der Gleichwertigkeit des 32-Bit- und 64-Bit-Verhaltens bei Visual Studio und .NET Framework

FrontPage-Servererweiterungen für IA64 WOW64

Wenn mit .NET Framework 1.1 eine Website auf einem IA64-Remotecomputer erstellt wird, auf dem .NET Framework 1.1 ausgeführt wird, wird FrontPage nicht unterstützt. Einige Basisfunktionen funktionieren jedoch über den Dateifreigabemechanismus.
Die Ausführung von J# auf systemeigenen 64-Bit-Plattformen wird nicht unterstützt. J#-Code kann nur in WOW64 auf 64-Bit-Plattformen ausgeführt werden.
SQL Server Express wird auf 64-Bit-Plattformen für .NET Framework 2.0 nicht unterstützt.
Bei ASP.NET-Anwendungen mit hohen Kapazitätsanforderungen, die unter .NET 1.1 in WOW64 für IA64 ausgeführt werden, kann keinerlei Garantie hinsichtlich Leistung oder Skalierbarkeit übernommen werden.
Datenhaltepunkte funktionieren nicht, wenn Visual Studio unter IA64 in WOW64 ausgeführt wird.
Das Debuggerfeature Bearbeiten und Fortfahren funktioniert nicht auf 64-Bit-Plattformen.
VC-ATL-Ausnahmen in Visual Studio 2005:
- Das Buildsystem registriert keine DLL-Dateien bei Verwendung von 64-Bit-Plattformen unter WOW64.
- Fehler ""%1" ist keine gültige Win32-Anwendung" beim Debuggen eines standardmäßigen ATL-Serverprojekts auf einem 64-Bit-Computer.
- Die ausführbare Datei zum Debuggen und der URL werden für ATL-Serverprojekte mit 64-Bit-Konfigurationen nicht vorab aufgefüllt.
- IE wird nicht mit der vom Benutzer angegebenen SRF-Datei gestartet, wenn ein 64-Bit-ATL-Serverprojekt debuggt wird.
- Als Debuggertyp für 64-Bit-ATL-Serverkonfigurationen wird standardmäßig ein lokaler Windows-Debugger anstelle eines Webdienstdebuggers ausgeführt.
- Debugeigenschaften werden nicht in neue Konfigurationen eines Projekts übernommen. Wenn Sie beispielsweise von einem ATL-Serverprojekt in x86 ausgehen und anschließend dafür eine 64-Bit-Konfiguration erstellen, wird das Debuggen erst dann ordnungsgemäß ausgeführt, wenn Sie IE als zu debuggende Komponente verwenden.
Interopdebuggen (verwaltetes + nicht verwaltetes Debuggen im gemischten Modus) wird in 64-Bit-Konfigurationen nicht unterstützt.
Einige MDAs werden auf 64-Bit-Plattformen nicht unterstützt. Beispiele: Reentrancy, LoaderLock, PInvokeStackImbalance
Systeminterne MMX-Funktionen werden von IA64- und x64-C++-Compilern nicht unterstützt.
Inlineassemblys werden von IA64- und x64-C++-Compilern nicht unterstützt.
Die meisten höheren Sprachkonstrukte werden von x64 MASM nicht unterstützt.
MASM unterstützt nicht IA64. Im Lieferumfang ist jedoch der Intel-Assembler (ias.exe) enthalten.
Der VC++-Compilerschalter /ARCH:SSE wird von x64- und IA64-VC++-Compilern nicht unterstützt.
Die System.Diagnostics.Process.MainModule-API und die System.Diagnostics.Process.Modules-API werden unter WOW64 in einem untergeordneten 64-Bit-Prozess nicht ordnungsgemäß ausgeführt.
32-Bit- und 64-Bit-COM+-ServicedComponents mit derselben GUID/CLSID können nicht gleichzeitig registriert werden.
Das 64-Bit-SDK enthält keine systemeigene DBGCLR. DBGCLR ist nur unter WOW64 verfügbar.
Das 64-Bit-SDK enthält keine systemeigene DEXPLORE.EXE. DEXPLORE.EXE ist nur in WOW64 verfügbar.
Für x64 und IA64 gibt es keine Bootstrapper-Manifestpakete. Für ClickOnce oder andere Anwendungen ist kein 64-Bit-Bootstrapper verfügbar. Bei dem Versuch, auf einem beliebigen 64-Bit-Computer mit .NET Framework-Installation eine ClickOnce-Anwendung zu installieren, wird folgende Fehlermeldung angezeigt: "Diese Version von .NET Framework 2.0 wird auf einem 64-Bit-Betriebssystem nicht unterstützt. Wenden Sie sich an den Hersteller der Anwendung." Dies geschieht selbst bei Anwendungen, die ausschließlich als 32-Bit-Anwendungen erstellt wurden und normalerweise unter WOW64 ausgeführt werden.
Visual Studio wird unter IA64 nicht installiert.

VS2005 (alle SKUs) wird unter IA64 nicht installiert (keine Entwurfszeitunterstützung für IA64). VC verfügt über einen systemeigenen Installer für IA64-Befehlszeilentools.
Nur Visual Studio Team System ermöglicht das Erstellen von Anwendungen für IA64.
P/Invoke-Signaturen mit "blitfähigen" Typen (Typen mit gleicher Darstellung in verwaltetem und nicht verwaltetem Code) werden auf 64-Bit-Plattformen anders behandelt.

Da P/Invoke auf 64-Bit-Plattformen anders implementiert wird, kann es vorkommen, dass ungültige P/Invoke-Signaturen, die auf 32-Bit-Plattformen zufällig funktioniert haben, auf 64-Bit-Plattformen nicht funktionieren.
Visual Studio Tools for Office (VSTO) wird auf 64-Bit-Plattformen nicht unterstützt.

1.3 Verweise auf 32-Bit-COM-Komponenten funktionieren möglicherweise nicht in VB- und C#-Anwendungen, die auf 64-Bit-Plattformen ausgeführt werden

Die meisten vorhandenen COM-Komponenten sind nur für 32-Bit-Plattformen verfügbar und werden in 64-Bit-Prozessen auf einer 64-Bit-Plattform nicht unterstützt (obwohl sie in 32-Bit-Prozessen auf einer 64-Bit-Plattform ordnungsgemäß ausgeführt werden). VB- und C#-Anwendungen, die auf diese 32-Bit-COM-Komponenten verweisen, werden standardmäßig nicht auf einer 64-Bit-Plattform ausgeführt, weil die Anwendung standardmäßig als 64-Bit-Prozess gestartet wird.

Das Problem tritt auf, wenn für ein Projekt mit einem oder mehreren COM-Verweisen Folgendes gilt:

Das Projekt wurde auf VS 2005 migriert und wird auf 64-Bit-Plattformen ausgeführt.

– oder –
Das Projekt wurde mit VS 2005 auf 64-Bit-Plattformen erstellt.

Die VB- und C#-Compiler verwenden in VS 2005 die Zielplattformeigenschaft, um zu bestimmen, ob die EXE- oder DLL-Dateien im 32-Bit- oder im 64-Bit-CPU-Architekturmodus ausgeführt werden sollen. Diese Eigenschaft ist in Visual Studio 2005 standardmäßig auf 'AnyCPU' festgelegt. Damit wird angegeben, dass die Anwendung abhängig von der Hostplattform entweder im 32-Bit- oder im 64-Bit-Modus ausgeführt wird. Wenn Sie die Anwendung in solchen Fällen debuggen oder ausführen, wird möglicherweise eine Fehlermeldung mit dem Hinweis angezeigt, dass die Klasse nicht instanziiert werden kann.

So beheben Sie dieses Problem

Legen Sie die Zielplattformeigenschaft für VB- oder C#-Projekte, die Verweise auf COM-Komponenten enthalten, auf 'X86' fest.

Für C#-Projekte:

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und wählen Sie 'Eigenschaften'.
Wählen Sie die Registerkarte Erstellen aus.
Legen Sie die Eigenschaft Zielplattform auf 'X86' fest.

Für VB-Projekte:

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und öffnen Sie 'Eigenschaften'.
Wählen Sie die Registerkarte Kompilieren aus.
Klicken Sie auf die Schaltfläche Erweiterte Kompilierungsoptionen…
Legen Sie die Eigenschaft Ziel-CPU auf 'X86' fest.

Express Edition:

Schließen Sie das Projekt und/oder die Projektmappe.
Klicken Sie im Menü Datei auf Datei öffnen.
Wechseln Sie zum Projektverzeichnis, und markieren Sie die Projektdatei.
Klicken Sie auf die Schaltfläche Öffnen. Die Projektdatei sollte nun im XML-Editor geöffnet werden.
Suchen Sie nach dem ersten <PropertyGroup>-Abschnitt, und fügen Sie folgende Zeile ein:
<PlatformTarget>x86</PlatformTarget>
Speichern Sie die Projektdatei.
Öffnen Sie das Projekt und/oder die Projektmappe erneut, indem Sie im Menü Datei auf Projekt/Projektmappe öffnen klicken.
Fahren Sie mit dem Entwickeln, Debuggen und Testen fort.

Alternativ, wenn die Anwendung für 64-Bit-Plattformen bestimmt ist, können Sie sicherstellen, dass es auf den Entwicklungs- und Bereitstellungscomputern 64-Bit-Entsprechungen für die der Anwendung hinzugefügten COM-Steuerelemente gibt.

1.4 Die Verwendung servergespeicherter Windows-Profile kann dazu führen, dass das beim erstmaligen Start angezeigte Meldungsfeld bei jedem Start angezeigt wird

Wenn ein Produkt der Visual Studio-Produktfamilie mit servergespeicherten Windows-Profilen verwendet wird, wird die beim ersten Start angezeigte Meldung "Visual Studio 2005 konfiguriert die Umgebung für die erste Verwendung. Dies kann einige Minuten dauern." bei jedem Start einer Sitzung angezeigt. Dies kann die Leistungen beim Start unnötig verringern und zu Verzögerungen führen.

So beheben Sie dieses Problem

Klicken Sie auf Extras > Optionen... Wählen Sie "Einstellungen importieren und exportieren", und ändern Sie den unter "Eigene Einstellungen automatisch in folgender Datei speichern:" angegebenen Pfad in einen Pfad, der sich NICHT im Verzeichnis "Eigene Dokumente" befindet.

1.5 Die Optionen Schriftarten und Farben werden nach dem Zurücksetzen nicht sofort wiederhergestellt

Sie können Umgebungseinstellungen zurücksetzen, indem Sie auf Extras > Einstellungen importieren und exportieren... klicken und anschließend "Alle Einstellungen zurücksetzen" auswählen. Sie können Umgebungseinstellungen jedoch auch zurücksetzen, indem Sie im Befehlsfenster den Befehl "Tools.ImportAndExportSettings /reset" ausgeben. In beiden Fällen werden die Optionen Schriftarten und Farben erst nach dem Neustart von Visual Studio wiederhergestellt.

So beheben Sie dieses Problem

Starten Sie Visual Studio erneut, nachdem Sie den Zurücksetzungsvorgang ausgeführt haben.

1.6 DMO funktioniert nicht unter Windows 2000 Service Pack 4

MDAC 2.8 Service Pack 1 wird nicht als Bestandteil der Visual Studio Express-Produkte installiert. Für Anwendungen, die von MDAC 2.8 Service Pack 1 abhängig sind (z. B. Anwendungen, die SQL-DMO verwenden), muss MDAC 2.8 separat gedownloadet werden.

So beheben Sie dieses Problem

Downloaden Sie MDAC 2.8 Service Pack 1 unter http://go.microsoft.com/fwlink/?LinkId=50233.

1.7 Die DataBindings-Eigenschaft für Steuerelemente ist nach dem Kopieren und Einfügen eines Felds aus dem Datenquellenfenster nicht richtig

Wenn Sie Felder aus der Datenbank einer Datenquelle kopieren und einfügen (anstatt diese durch Drag & Drop einzufügen), um Steuerelemente im Windows Forms-Designer zu erstellen, werden die Datenbindungseigenschaften für die Tabelle anstatt für die Felder der Tabelle festgelegt. Objekt- und Webdatenquellen sind davon nicht betroffen.

So beheben Sie dieses Problem

Legen Sie für alle im Windows Forms-Designer hinzugefügten Steuerelemente in den Eigenschaften die richtige Datenquelle für die (DataBindings-)Eigenschaft fest.

Zum Seitenanfang

2. Visual C# Express

2.1 Zeichen für keine Leerstellen sind für Verknüpfungen in C#-Codeausschnitten unzulässig

C#-Codeausschnitte werden in XML in SNIPPET-Dateien definiert. Das Schema kann beispielsweise den Tag <Shortcut></Shortcut> enthalten. Verknüpfungen ermöglichen das schnelle Einfügen von Ausschnitten. Der Benutzer muss lediglich die entsprechende Verknüpfungszeichenfolge eingeben und anschließend die TAB-TASTE drücken.

In Verknüpfungen sind viele Unicode-Zeichen zulässig. Zeichen für keine Leerstellen in komplexen Skriptsprachen werden jedoch nicht als gültige Verknüpfungszeichen erkannt. Daher können einige Zeichenfolgen in komplexen Skriptsprachen nicht als Verknüpfungen verwendet werden. Wenn eine Verknüpfung, die ein Zeichen für keine Leerstellen enthält, eingegeben und anschließend die TAB-TASTE gedrückt wird, wird anstelle eines Codeausschnitts ein Tabulatorzeichen eingefügt.
Hinweis: Die Ausschnittsverknüpfung wird weiterhin in IntelliSense angezeigt.

So beheben Sie dieses Problem

Wählen Sie einen Unicode-Verknüpfungsnamen ohne Zeichen für keine Leerstellen aus.
Fügen Sie den Ausschnitt über die Codeausschnittsauswahl-UI ein, anstatt Verknüpfungen zu verwenden.

2.2 Warnung für Microsoft Visual J# 2.0 Redistributable Package im Dialogfeld Erforderliche Komponenten

Im Dialogfeld Erforderliche Komponenten, das Sie im Projekt-Designer über die Registerkarte Veröffentlichen aufrufen können, ist Microsoft Visual J# 2.0 Redistributable Package mit einem Warnsymbol gekennzeichnet.

So beheben Sie dieses Problem

Die Warnung kann problemlos ignoriert werden.

2.3 Einige mit Express erstellte Anwendungen können unter x64 Windows nicht debuggt oder ausgeführt werden

Für Anwendungen, die mit VB, C# oder J# Express erstellt sind, wird standardmäßig festgelegt, dass sie auf jedem Prozessor geladen werden können (Standardwert "AnyCPU"). Diese Anwendungen werden in der 64-Bit-CLR geladen. Falls diese nicht vorhanden ist, werden sie in der 32-Bit-CLR geladen. Allerdings werden einige Anwendungstypen nicht ordnungsgemäß ausgeführt, wenn sie in der 64-Bit-CLR geladen werden. Dies gilt insbesondere für Anwendungen, die Verweise auf 32-Bit-COM-Komponenten oder auf einige DirectX-Versionen verwenden. Obwohl die Zielplattform in Produkten, die keine Express Edition Visual Studio-Produkte sind, von "AnyCPU" in "x86" geändert werden kann, ist diese Option in Express-Editionen nicht verfügbar.

So beheben Sie dieses Problem

Öffnen Sie Extras->Optionen.
Aktivieren Sie "Alle Einstellungen anzeigen".
Aktivieren Sie "Projekte und Projektmappen->Erweiterte Buildkonfigurationen anzeigen".
Öffnen Sie Erstellen->Konfigurations-Manager.
Wählen Sie das Kombinationsfeld unter der Spalte "Plattform" für das Projekt aus, das unter x86 ausgeführt werden soll.
Wählen Sie "Neu" aus.
Wählen Sie unter "Neue Plattform" x86 aus.
Klicken Sie auf OK und anschließend auf Schließen.
Beachten Sie, dass das Symbolleisten-Kombinationsfeld für die Plattformkonfiguration nun sowohl x86 als auch AnyCPU enthält, wobei x86 aktiviert ist.
Beim Erstellen und Ausführen von Debuggen werden nun ausschließlich x86-Binärdateien erstellt. Wenn Sie dies ändern möchten, können Sie zur AnyCPU-Konfiguration wechseln.

2.4 Die Meldung "Fehler bei Microsoft C# 2005 IntelliSense" wird möglicherweise angezeigt, wenn Sie verschiedene Aktionen in der IDE ausführen

In bestimmten Fällen wird möglicherweise die Meldung "Fehler bei Microsoft C# 2005 IntelliSense. Entschuldigen Sie die Unannehmlichkeiten." angezeigt, wenn im Editor verschiedene Aktionen ausgeführt werden. In den meisten Fällen liegt das daran, dass beim Abrufen der Quelldaten ein Fehler aufgetreten ist.

Beispielsweise könnte dieses Fehlerdialogfeld bei folgenden Aktionen ausgelöst werden:

Umbenennen eines externen Alias
Ausführen einer Suche nach allen Verweisen in einem Webprojekt ohne das Attribut 'runat="server"'

Bei diesem Dialogfeld handelt es sich um keinen schwerwiegenden Fehler. Der Benutzer kann seine Arbeit sicher und ohne Datenverlust fortsetzen, indem er auf die Schaltfläche zum Senden eines Berichts klickt.

So beheben Sie dieses Problem

Es gibt zwei Möglichkeiten, die Anzeige aller nicht kritischen Fehlermeldungen vom C#-Sprachendienst zu deaktivieren. Ändern Sie hierzu die Registrierung unter dem Registrierungspfad:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor]

"Watson_ReportExceptions"=dword:00000001
Durch Hinzufügen dieses Registrierungsschlüssels mit dem angegebenen Wert wird die Fehlerberichterstattung vollständig deaktiviert.
"Watson_DeferSendingUntilLater"=dword:00000000
Wenn Sie diesen Registrierungspfad mit dem angegebenen Wert hinzufügen, wird das Anzeigen der Fehlermeldung deaktiviert. Das Senden von Feedback an Microsoft ist jedoch weiterhin aktiviert. Die IDE wird für einen kurzen Zeitraum nicht reagieren, da die zu sendenden Informationen ermittelt werden.

2.5 Die Verwendung benutzerdefinierter Typen (User-Defined Types, UDT) als Einstellung kann im Einstellungs-Designer unerwartetes Verhalten verursachen

Die Verwendung benutzerdefinierter Typen als Einstellung kann Probleme verursachen, wenn die Assembly, in der der UDT abgelegt ist, aktualisiert wird, während das verwendete Projekt geöffnet ist. Falls dieses Szenario erforderlich ist, können Sie das Problem umgehen, indem Sie für die UDT-Assembly die Verwendung inkrementeller Versionssemantik festlegen.

So beheben Sie dieses Problem

Wenn der als Einstellung verwendete UDT in einer Klassenbibliothek abgelegt ist, müssen Sie die Bibliothek inkrementell versionieren, um das Problem zu beheben. Wenn der UDT in einer EXE-Datei abgelegt ist, muss die IDE geschlossen und erneut gestartet werden, damit Änderungen am UDT wirksam werden.

2.6 VS-Inhaltsinstaller kann nicht ausgeführt werden, wenn C#-Express deinstalliert wurde

Wenn C#-Express und anschließend eine der primären SKUs installiert wird und dann die C# Express-SKU deinstalliert wird, kann der VS-Inhaltsinstaller nicht ausgeführt werden.

So beheben Sie dieses Problem

Reparieren Sie Visual Studio.

Zum Seitenanfang

3. Visual Basic Express

3.1 Keine Forms-Eigenschaft in "My" in einem Benutzersteuerelement-Projekt

My.Forms ist in einem Benutzersteuerelement-Projekt nicht verfügbar.

3.2 Beim Anhalten im Ruhezustand kann die Methode eines Objekts nicht über Remotedebuggen aufgerufen werden

Wenn der nachstehende Code auf einem Remotecomputer ausgeführt wird, und Sie anschließend über Remotedebuggen eine Verbindung mit dem ausgeführten Code herstellen, und die Ausführung beim Aufruf von Sleep() unterbrochen wird, können Sie Member der Variablen c nicht auswerten.

c = New c1     'wobei c1 als gültige Klasse angenommen wird
While True
    Threading.Thread.Sleep(1000)
End While

So beheben Sie dieses Problem

Beenden Sie Sleep(). Anschließend können Objekte normal ausgewertet werden.

3.3 Eine Struktur kann nicht einer variant-Eigenschaft in einem ActiveX-EXE-Objekt übergeben werden

Unter Windows 98 kann eine Struktur nicht einer variant-Eigenschaft in einem ActiveX-EXE-Objekt übergeben werden. Das Problem wird dadurch verursacht, dass auf einem bereinigten Windows 9X-Computer die System-DLL rpcrt4.dll standardmäßig nicht registriert wird, sodass der Registrierungsschlüssel [HKEY_CLASSES_ROOT\CLSID\{B5866878-BD99-11D0-B04B-00C04FD91550}] im Betriebssystem fehlt. Der Aufruf ist aufgrund der fehlenden Registrierung fehlerhaft.

So beheben Sie dieses Problem

Wechseln Sie zu C:\Windows\System, und rufen Sie RegSvr32.exe rpcrt4.dll manuell auf.

3.4 New bei einem Typparameter mit zyklischen Einschränkungen bewirkt, dass der VB-Compiler nicht mehr reagiert und Speicherzuweisungen zunehmen

Wenn folgender Code in eine Konsolenanwendung eingefügt wird, führt dies dazu, dass die Anwendung nicht mehr reagiert.

Class C1(Of U As U)    'die zyklischen Einschränkungen hier verursachen das spätere Problem
End Class

Partial Class C1(Of U)
Dim x As New U        'Problem - dies verursacht Endlosschleife, und die Speicherauslastung wird immer größer,
                       bis der Speicher nicht mehr verfügbar ist

End Class

So beheben Sie dieses Problem

Entfernen Sie die zyklische Einschränkung.

3.5 Parameter für StartupNextInstanceEvent-Handler enthalten keine Befehlszeilenargumente, wenn die Anwendung mit ClickOnce gestartet wird

Parameter für StartupNextInstanceEvent-Handler enthalten nicht die Befehlszeilenargumente der zweiten Anwendungsinstanz, wenn die Anwendung mit ClickOnce gestartet wird. Sie müssen die My.Application.Deployment.ActivationUri-Eigenschaft verwenden, um die Befehlszeilenargumente abzurufen.

So beheben Sie dieses Problem

Verwenden Sie wie folgt die ASP-Laufzeitklassen zum Abrufen der Befehlszeilenargumente:

Imports System.Web

Dim commandLineArgs as NameValueCollection = _
HttpUtility.ParseQuery(My.Application.Deployment.ActivationUri)

3.6 Der VB-Compiler unterstützt nicht das InternalsVisibleTo-Attribut

<Assembly: InternalsVisibleTo("Foo.Dll, PublicKeyToken=a29c01bbd4e39ac5")>

Dieses Attribut macht Friend-Typen für andere Assemblys verfügbar. Dieses Attribut wird vom VB-Compiler nicht unterstützt.

Einige Komponententesttechnologien, die beim Testen privater Typen von diesem Attribut abhängen, funktionieren nicht wie erwartet.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

3.7 Warnung für Microsoft Visual J# 2.0 Redistributable Package im Dialogfeld Erforderliche Komponenten

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

3.8 My.Application.Log.WriteEntry kann eine Ausnahme auslösen, wenn der Benutzer keine Datei-E/A-Berechtigung hat

Erstellen Sie eine neue Konsolenanwendung mit folgendem Code:

My.Application.Log.DefaultFileLogWriter.CustomLocation = "D:\temp"
    My.Application.Log.WriteEntry("Foo")

Führen Sie die Anwendung aus.

ERGEBNIS:
Die Protokolldatei wird in D:\temp erstellt. Das Verzeichnis D:\Dokumente und Einstellungen\<Benutzername>\Anwendungsdaten\Microsoft\WindowsApplication1\1.0.0.0 wird ebenfalls erstellt, sofern es noch nicht vorhanden ist. Falls der Benutzer dazu nicht berechtigt ist, wird eine Ausnahme ausgelöst. Dies tritt wahrscheinlich auf, wenn Sie eine Klassenbibliothek in einer Webanwendung verwenden, weil der ASP.NET-Prozess standardmäßig keine Schreibberechtigung für ein Anwendungsdatenverzeichnis hat.

So beheben Sie dieses Problem

Entfernen Sie über app.config den Standard-FileLogTraceListener, und konfigurieren Sie My.Application.Log neu, um einen anderen TraceListener zu verwenden.
Überwachen Sie das Ereignis Unbehandelte Ausnahme, und fahren Sie einfach fort, wenn dieses Ereignis gemeldet wird.
Führen Sie Try/Catch für jeden Protokollaufruf aus (oder wenigstens für die Aufrufe, die wahrscheinlich zuerst ausgeführt werden).

3.9 Die Verwendung benutzerdefinierter Typen (User-Defined Types, UDT) als Einstellung kann im Einstellungs-Designer unerwartetes Verhalten verursachen

So beheben Sie dieses Problem

3.10 Die Interopunterstützung von Long (VT_I8) ist auf WinXP beschränkt

Spät gebundene Aufrufe unter Windows 2000 oder Windows 9x zur Übergabe eines Long (VT_I8) werden nicht ausgeführt. Windows XP ist die einzige unterstützte Plattform für VT_I8 durch OLE-Automatisierung.

So beheben Sie dieses Problem

Verwenden Sie Integer anstelle von Long.

Zum Seitenanfang

4. Visual J# Express

4.1 Die Verwendung benutzerdefinierter Typen (User-Defined Types, UDT) als Einstellung kann im Einstellungs-Designer unerwartetes Verhalten verursachen

So beheben Sie dieses Problem

Zum Seitenanfang

5. Visual C++ Express

5.1 Die Verwendung benutzerdefinierter Typen (User-Defined Types, UDT) als Einstellung kann im Einstellungs-Designer unerwartetes Verhalten verursachen

So beheben Sie dieses Problem

Zum Seitenanfang

6. .NET Framework

6.1 AuthorizationStoreRoleProvider: Der Autorisierungs-Manager gibt nicht zutreffende oder unklare Fehlermeldungen zurück

AuthorizationStoreRoleProvider ist vom Autorisierungs-Manager abhängig. Einige der vom Autorisierungs-Manager zurückgegebenen Fehlermeldungen geben nicht die zugrunde liegende Ursache eines Problems an. Nachstehend werden Fehlermeldungen aufgelistet, von denen bekannt ist, dass sie entweder unzutreffend oder unklar sind.

"COMException (0x8007052b): Das Kennwort kann nicht aktualisiert werden. Der Wert, der für das aktuelle Kennwort angegeben wurde, ist falsch."
Bei diesem Fehler handelt es sich in Wirklichkeit um einen Zugriffsverweigerungsfehler. Dieser Fehler kann auftreten, wenn sämtliche der folgenden Bedingungen zutreffen: ASP.NET wird unter IIS 5.0, unter Windows XP IIS 5.1 oder im IIS 5.0-Isolationsmodus unter Windows Server 2003 bereitgestellt; die Anwendung ist für die Verwendung der integrierten Windows-Authentifizierung konfiguriert; die Richtliniendatei ist in der Verzeichnisstruktur der aktuellen ASP.NET-Anwendung abgelegt. Dieser Fehler kann außerdem auftreten, wenn ASP.NET als lokales Computerkonto ausgeführt wird und versucht, in einer Remote-AD-Instanz bzw. Remote-ADAM-Instanz auf einen Richtlinienspeicher zuzugreifen.

"Weitere Daten sind verfügbar."
Dieser Fehler bedeutet, dass der Richtlinienspeicher nicht gefunden werden konnte. Dieser Fehler kann auftreten, wenn die Verbindungszeichenfolge auf eine ADAM-Instanz zeigt und die ADAM-Instanz, auf die verwiesen wird, nicht vorhanden ist. Der Fehler tritt beispielsweise auf, wenn die Verbindungszeichenfolge "LDAP://localhost:4000/Cn=storename, DC=Partition1" angegeben ist und Partition1 nicht in der ADAM-Instanz vorhanden ist.

"Der angegebene Server kann den angeforderten Vorgang nicht ausführen."
Dieser Fehler bedeutet in Wirklichkeit, dass der angebene Server nicht gefunden werden konnte. Dieser Fehler kann auftreten, wenn die Verbindungszeichenfolge auf einen nicht vorhandenen Server zeigt oder die Nummer eines Anschlusses verwendet, der von AD oder ADAM nicht überwacht wird.

"ArgumentException: Falscher Parameter."
Diese Fehlermeldung gibt in Wirklichkeit an, dass eine LDAP-Abfragegruppe im Autorisierungs-Manager verwendet wird, um zu ermitteln, ob ein Benutzer in einer Rolle ungültig ist.

So beheben Sie dieses Problem

Überprüfen Sie mögliche Ursachen anhand der oben aufgelisteten Fehlerbedingungen. Wenn eine der möglichen Ursachen auf die Anwendungskonfiguration zutrifft, verwenden Sie die oben aufgeführten Informationen, um die Anwendungskonfiguration zu ändern bzw. die damit verbundenen Probleme zu beheben.

6.2 SQL Server Express-Benutzerinstanzen müssen auf freigegebenen Hostcomputern deaktiviert sein

ASP.NET 2.0 ist mit SQL Server Express 2005 integriert, um die automatische Erstellung der Datenbank bereitzustellen, die für viele der neuen ASP.NET 2.0-Anwendungsdienste erforderlich ist. Diese Funktionalität ist von der SQL Server Express-Unterstützung für die Generierung von Serverprozessen abhängig, die entweder mit der Identität des interaktiven Benutzers oder mit der Identität des Workerprozesses, der ASP.NET hostet, ausgeführt werden. In nicht vertrauenswürdigen Umgebungen (z. B. ein freigegebener Hostserver) sollte die Generierung von SQL Server-Workerprozessen nicht aktiviert sein, um die unbeabsichtigte Freigabe von Daten zwischen ASP.NET-Anwendungen zu verhindern.

So beheben Sie dieses Problem

Wenn Sie SQL Server Express mit dem eigenständigen Installer installieren, können Sie die erweiterten Setupoptionen verwenden, um die Unterstützung für Benutzerinstanziierung zu deaktivieren.

Alternativ können Sie die Benutzerinstanziierung für eine vorhandene SQL Server Express-Installation wie folgt manuell deaktivieren:

Melden Sie sich als lokaler Administrator an, und öffnen Sie ein Befehlsfenster, indem Sie cmd.exe ausführen.
Falls osql.exe in den Verzeichnissen, die in der PATH-Umgebungsvariablen aufgelistet sind, nicht verfügbar ist, ändern Sie die Verzeichnisse in das SQL Server Express-Verzeichnis, das osql.exe enthält.
Stellen Sie eine Verbindung zur übergeordneten SQL Server-Instanz her: osql –E –S .\sqlexpress

Geben Sie folgende SQL-Befehle aus:

exec sp_configure 'show advanced option', '1' 
go
reconfigure with override
go
exec sp_configure 'user instances enabled', 0
     go
reconfigure with override
go

6.3 Permanente Cookies für die Formularauthentifizierung haben nun dieselbe Timeouteinstellung wie sitzungsbasierte Cookies

In früheren ASP.NET-Versionen hatten permanente Fomularauthentifizierungscookies eine hartcodierte Lebensdauer von 50 Jahren. In ASP.NET 2.0 ist das Ablaufdatum für permanente Formularauthentifizierungscookies folgendermaßen festgelegt: aktueller Zeitpunkt plus dem Wert des "timeout"-Attributs aus der Konfiguration. Dies bedeutet, dass permanente Cookies standardmäßig eine Lebensdauer von 30 Minuten haben. Wenn Sie eine längere Lebensdauer festlegen möchten, müssen Sie für das "timeout"-Attribut einen höheren Wert festlegen. In ASP.NET 2.0 bedeutet dies, dass der neue Timeoutwert von den in sitzungsbasierten und den in permanenten Cookies gespeicherten Formularauthentifizierungstickets verwendet wird.

So beheben Sie dieses Problem

Wenn für permanente Cookies andere Timeoutwerte verwendet werden sollen, können Entwickler einen Verweis auf den Formularauthentifizierungscookie abrufen, nachdem das Cookie ursprünglich mit einer Methode wie FormsAuthentication.SetAuthCookie festgelegt wurde. Entwickler können anschließend durch Aufruf von Response.Cookies[FormsAuthentication.FormsCookieName] einen Verweis auf das Cookie abrufen. Entwickler können anschließend die Expires-Eigenschaft des sich ergebenden HttpCookie auf einen anderen Wert festlegen.

6.4 Falsches Verhalten der DeleteRole-Methode von AuthorizationStoreRoleProvider

Bei dem Versuch, eine vorhandene Rolle zu löschen, löst die DeleteRole-Methode des Anbieters fälschlicherweise die Ausnahme "Element nicht gefunden" aus. Der Anbieter sollte stattdessen false zurückgeben. Bei dem Versuch, eine Rolle zu löschen, die vorhandene Benutzer enthält, gibt der Anbieter false zurück, anstatt eine Ausnahme auszulösen.

So beheben Sie dieses Problem

Schließen Sie alle Aufrufe der DeleteRole-Methode des Anbieters in einen Try-Catch-Block ein. Auf diese Weise wird sichergestellt, dass zukünftige Problembehebungen, die Ausnahmen beim Löschen aufgefüllter Rollen erneut aktivieren, keine Auswirkungen auf den vorhandenen Code haben.
Überprüfen Sie, ob die Rolle bereits vorhanden war, bevor versucht wurde, sie zu löschen.

6.5 Es können Fehler bei der Ausführung des ASP.NET-Profilfeatures auftreten, wenn XML-Serialisierung und eine nicht standardmäßige Anwendungsidentität verwendet wird

Für das ASP.NET-Profilfeature wird die XML-Serialisierung als Standardmechanismus zur Serialisierung von Eigenschaften verwendet. Wenn die ASP.NET-Prozessidentität weder ASPNET (unter IIS 5.0 und IIS 5.1) noch NETZWERKDIENST (für IIS 6) ist, führt dies beim XML-Serialisierungsprozess zu einem Fehler mit folgender Ausnahme: "InvalidOperationException: Temporäre Klasse kann nicht generiert werden." Dasselbe Problem tritt beim Anwendungsidentitätswechsel auf. Diese Ausnahmen treten auf, weil XmlSerializer temporäre Klassendateien in das Verzeichnis %windir%\temp schreibt. Dieses Verzeichnis gewährt den ASP.NET-Standardkonten standardmäßig nur die Berechtigungen "Ordner auflisten/Daten lesen". Nicht standardmäßige ASP.NET-Konten können temporäre Dateien in dieses Verzeichnis schreiben, sind jedoch nicht dazu berechtigt, anschließend nach den von XmlSerializer verwendeten temporären Klassen zu suchen.

So beheben Sie dieses Problem

Für sichere Umgebungen sollten Entwickler einen anderen Serialisierungsmechanismus verwenden, d. h. entweder die binäre Serialisierung oder die Zeichenfolgenserialisierung. Für Anwendungen, bei denen es eher unwahrscheinlich ist, dass temporäre Klassendateien versehentlich anwendungsübergreifend freigegeben werden, kann dem Identitätswechsel des Workerprozesses oder der Anwendung die Berechtigung "Ordner auflisten/Daten lesen" für das Verzeichnis %windir%\temp gewährt werden.

6.6 ASP.NET-Sitzungszustandsbeschränkungen bei der Verwendung von SSE

SSE sollte nur in Entwicklungsumgebungen mit SQL Server-basiertem ASP.NET-Sitzungszustand verwendet werden, weil kein SQL Server-Agent-Dienst mit SSE installiert wird. Daher wird der Auftrag zur Bereinigung des Sitzungszustands nie ausgeführt, und die Sitzungszustandsdaten sammeln sich in der Datenbank an. Abgelaufene Sitzungen können manuell bereinigt werden, indem Sie eine Verbindung mit SSE herstellen und den folgenden Befehl ausführen: "EXECUTE DeleteExpiredSessions".

So beheben Sie dieses Problem

Verwenden Sie für Produktionsanwendungen die SQL Server 2005-Standardversionen.

6.7 AuthorizationStoreRoleProvider: Der Standardwert für ApplicationName verursacht einen Fehler vom Autorisierungs-Manager

Der Autorisierungs-Manager lässt die Verwendung des Zeichens "/" in Anwendungsnamen nicht zu. Falls applicationName in der Konfiguration nicht festgelegt wurde, folgt AuthorizationStoreRoleProvider der Logik anderer ASP.NET-Anbieter, um einen Standardwert für applicationName zu bestimmen. Bei Ausführung in ASP.NET führt dies zu einem Wert, der mit dem Zeichen "/" beginnt.

So beheben Sie dieses Problem

Legen Sie in der Konfiguration immer das applicationName-Attribut fest, wenn Sie AuthorizationStoreRoleProvider in einer ASP.NET-Anwendung verwenden.

6.8 System.Net hat die Logik für das Timeout einer DNS-Auflösung entfernt, wenn es kleiner ist als das Timeout in der nicht verwalteten API, die von System.Net zum Ausführen der Auflösung aufgerufen wird

In früheren .NET Framework-Versionen fügte der DNS von System.Net dem DNS-Typ Timeoutlogik hinzu, um das lange systemeigene Timeout zu umgehen. Ohne ein genaues DNS-Timeout können keine genauen Timeouts für andere Webanforderungen festgelegt werden. Zur Implementierung dieses Timeouts wird die DNS-Auflösung allerdings in einen anderen Thread verschoben. Wenn die Threadpoolstufe niedrig ist, wartet die DNS-Auflösung bis zum Timeout auf einen verfügbaren Thread, sodass eine Ausnahme ausgelöst wird. Um diese Ausnahme zu verhindern, wurde die DNS-Timeoutlogik entfernt.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

6.9 SqlCacheDependency erfordert Initialisierung mit einem Aufruf von System.Data.SqlClient.SqlDependency.Start

Da die Funktionsweise von Abfragebenachrichtigungen mit SQL Server 2005 geändert wurde, müssen Entwickler vor dem Verwenden von SqlCacheDependency mindestens einmal die Start-Methode für SqlDependency aufrufen. Ein logischer Ort zum Aufruf von Start befindet sich in der Application_Start-Methode einer Webanwendung in global.asax:

void Application_Start(object sender, EventArgs e) 
{
System.Data.SqlClient.SqlDependency.Start("connection string");
}

Es muss dieselbe Verbindungszeichenfolge verwendet werden wie bei der Ausgabe von Befehlen zur Verwendung mit SqlCacheDependency.

6.10 System.Net fügt beim Aufruf von WebClient.UploadValues() kein CRLF-Zeichen mehr hinzu

In früheren .NET Framework-Versionen wurde dem geuploadeten Inhalt beim Aufruf von WebClient.UploadValues() ein CRLF hinzugefügt, was zu Serveranwendungsfehlern führte. Die CRLF-Zeichen verletzen das in der HTML 4.01-Spezifikation erläuterte Codierungsschema application/x-www-form-urlencoded für den Inhaltstyp. Das CRLF wird nicht mehr hinzugefügt.

So beheben Sie dieses Problem

Fügen Sie mit WebClient.UploadData() das CRLF hinzu, und kompilieren Sie erneut die Anwendung, oder beheben Sie das Problem der Serveranwendung, sodass diese kein CRLF-Zeichen erwartet.

6.11 UriBuilder löscht nicht mehr die Fragment- oder Abfrageeigenschaften, nachdem diese festgelegt wurden

Bei UriBuilder handelt es sich um einen Typ, mit dem eine URI-Instanz Stück für Stück erstellt werden kann. In früheren .NET Framework-Versionen konnten die Abfrage- und Fragmenteigenschaften nicht gleichzeitig festgelegt werden. Dieser Fehler wurde in Version 2.0 behoben. Die Abfrage- und Fragmenteigenschaften werden nun festgelegt, ohne dass dabei Felder versehentlich gelöscht werden. Die Logik von Anwendungen, die das frühere Verhalten umgangen haben, muss möglicherweise angepasst werden, um fehlerhaftes Verhalten zu vermeiden.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

6.12 Die Berechtigungen, die erforderlich sind, bevor die im system.net-Element einer Anwendungskonfigurationsdatei vorhandenen Werte angewendet werden, wurden geändert

Die Berechtigungen, die erforderlich sind, um die im System.Net-Element einer Anwendungskonfigurationsdatei vorhandenen Einstellungen anzuwenden, wurden in der aktuellen .NET Framework-Version geändert. Nun sind zum Anwenden von Werten aus der Konfigurationsdatei dieselben Berechtigungen erforderlich, die beim Ändern der Einstellung im Code für die verknüpfte Eigenschaft erforderlich sind.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

6.13 Beim Senden einer FTP-Anforderung gefolgt von einer FTP-Anforderung über SSL (FTPs) an dasselbe Verzeichnis wird die Ausnahme "Datei kann nicht gefunden werden" ausgelöst

Wenn eine Anwendung eine FTP-Anforderung an einen Server und anschließend eine weitere FTP-Anforderung mit SSL-Aktivierung an denselben Server und Pfad ausgibt, tritt bei der zweiten Anforderung ein Fehler auf. Es wird eine Ausnahme ausgelöst, die angibt, dass die Datei nicht gefunden wurde. Die zweite Anforderung wird jedoch erfolgreich ausgeführt, wenn sie nicht an denselben Pfad gesendet wird.

6.14 WebRequest.ServicePoint.Address erfordert nur dann unbeschränkte Webberechtigung, wenn der entsprechende Dienstpunkt ein Proxyserver ist

Diese neue Anforderung verhindert, dass Anwendungen mit teilweiser Vertrauenswürdigkeit Netzwerkproxyadressen erkennen. Wenn die Adresse auf einen Proxyserver zeigt, erhalten teilweise vertrauenswürdige Anwendungen, die die ServicePoint.Address-API verwenden, möglicherweise eine SecurityException.

So beheben Sie dieses Problem

Verwenden Sie HttpWebRequest.Address.

6.15 System.Net registriert nun eine FtpWebRequest-Standardimplementierung, die unter Umständen bewirkt, dass Anwendungen mit einer eigenen FTP-Komponente nicht mehr funktionieren

Vor .NET Framework, Version 2.0, konnten Anwendungen eine Komponente registrieren, um FTP-Anforderungen mit dem erweiterbaren austauschbaren Protokollframework von System.Net zu behandeln. Komponenten zum Behandeln verschiedener Webanforderungen werden registriert, indem die jeweilige Komponente einem bestimmten URI-Präfix zugeordnet wird. Daraufhin wird jede Webanforderung, die mit diesem Präfix übereinstimmt, von der entsprechenden Komponente behandelt. In .NET Framework 2.0 unterstützt nun System.Net eine FtpWebRequest-Komponente, die standardmäßig für das Präfix "ftp:" registriert wird. Die (vor dieser Version) für dieses Präfix registrierten Anwendungen werden möglicherweise unterbrochen, weil das Präfix (FTP) bereits belegt ist.

So beheben Sie dieses Problem

Aktualisieren Sie die Anwendungskonfigurationsdatei, um die FTP-Standardprotokollkomponente zu entfernen, bevor Sie Ihre eigene FTP-Komponente registrieren:

<system.net>
<webRequestModules>
<remove prefix = "ftp:" />
</webRequestModules>
</system.net>

6.16 In .NET Framework 2.0 verhält sich GlobalProxySelection.Select anders als in Version 1.1, wenn die Datei machine.config ein leeres System.Net-Tag enthält

Wenn in .NET Framework, Version 1.1, in der Datei machine.config ein leeres System.Net-Element festgelegt wird, gibt GlobalProxySelection.Select eine leere Webproxyinstanz zurück, die angibt, dass kein Proxy verwendet werden soll. Der neue Standard der Version 2.0 gibt vor, dass in einem solchen Fall die Systemproxyeinstellungen (dieselben, die in Internet Explorer festgelegt sind) verwendet werden.

So beheben Sie dieses Problem

Bearbeiten Sie die Datei machine.config wie folgt, um die Standardproxyeinstellungen zu deaktivieren.

<system.net>
<defaultProxy enabled="false" />
</system.net>

6.17 System.Uri enthält nicht die IPv6-Bereichskennung mit dem Host

Wenn in früheren .NET Framework-Versionen eine URI-Instanz unter Verwendung einer IPv6-Adresse erstellt wurde, war die Bereichskennung immer in der Hostadresse enthalten. Die Bereichskennung verweist auf den Index eines lokalen Netzwerkadapters und ist für Remotehosts ohne Bedeutung. In der Syntax der Bereichskennung wird außerdem das Zeichen '%' verwendet, was einen Konflikt mit dem Escapeformat '%hh' verursacht. Wenn die Bereichskennung im Host enthalten ist, wird die System.Uri-Funktionalität, mit anderen URI-Parsern und -Resolvern zusammenzuarbeiten, außer Kraft gesetzt. In Version 2.0 fügt System.Uri nicht mehr die Bereichskennung mit einem IPv6-Host in einer URI-Instanz hinzu. System.Uri hat zusätzlich DnsSafeHost als neue Eigenschaft hinzugefügt, die die Bereichskennung mit einer IPv6-Hostadresse zurückgibt.

So beheben Sie dieses Problem

Verwenden Sie Uri.DnsSafeHost, um die Bereichskennung mit einer IPv6-Hostadresse zurückzugeben.

6.18 Wenn über die System.Transactions-Konfiguration ein Cluster als Remoteproxy festgelegt wird, wird beim Clusterfailover möglicherweise eine TransactionException ausgelöst

Wenn in der Konfiguration ein Cluster als Remoteproxy angegeben wird, indem für DistributedTransactionManagerName ein Cluster festgelegt wird, wird beim Clusterfailover möglicherweise eine TransactionException ausgelöst.

So beheben Sie dieses Problem

Um einen Cluster als Remoteproxy anzugeben, verwenden Sie die Komponentendienste MMC, um in der Konfiguration von MSDTC festzulegen, dass der Cluster als Remote-MSDTC verwendet werden soll.

6.19 NullReferenceException wird bei dem Versuch ausgelöst, die DistributedIdentifier-Transaktionen während der Transaktionsheraufstufung abzurufen

Der Versuch, DistributedIdentifier für eine Transaktion abzurufen, während die Transaktion heraufgestuft wird, kann eine NullReferenceException auslösen.

So beheben Sie dieses Problem

Es gibt zwei Möglichkeiten, dieses Problem zu umgehen.

Stellen Sie sicher, dass der Zugriff auf die Transaktion synchronisiert ist.

- oder -

Stellen Sie sicher, dass die Transaktion vor dem Aktivieren der DistributedIdentifier-Eigenschaft heraufgestuft wird.

6.20 Die mit Webverweis hinzufügen generierten ASP.NET-Webdienstproxys verwenden denselben URL aus der Konfigurationsdatei, selbst wenn der Dienst mehrere Endpunkte mit verschiedenen URLs hat

Wenn ein Webverweis in Visual Studio 2005 hinzugefügt wird, wird der URL des Diensts automatisch aus dem AppSettings-Abschnitt der Konfigurationsdatei übernommen. Wenn der Webdienst mehrere Endpunkte mit verschiedenen URLs hat, werden mehrere Proxytypen generiert, die jedoch alle denselben, aus der Konfigurationsdatei übernommenen URL-Wert verwenden.

So beheben Sie dieses Problem

Es gibt zwei Möglichkeiten:

Bearbeiten Sie das WSDL-Dokument, und gliedern Sie jeden Dienst in einem separaten Dokument auf.

- oder -
Bearbeiten Sie die Konfigurationsdatei, um jedem Webdienst einen Schlüssel hinzuzufügen. Lesen Sie anschließend die Werte in den Code unter Verwendung von System.Configuration.ConfigurationSettings.AppSettings. Legen Sie die URL-Eigenschaft für die entsprechenden Proxyinstanzen fest, indem Sie diese Werte verwenden.

6.21 Die standardmäßige Unterstützung von Nullable<T> in generierten ASP.NET-Webdienstproxys kann vorhandenen Code außer Kraft setzen, wenn der Proxy neu generiert wird

Wenn ein Schema importiert wird, das das Attribut nullable="true" für einen ASP.NET-Webdienst enthält, enthält der generierte Proxy Nullable<T>-Typen, während das Attribut früher ignoriert wurde. Diese Änderung kann Entwurfszeit- oder Laufzeitunterbrechungen in Anwendungen verursachen.

So beheben Sie dieses Problem

Sie haben folgende Möglichkeiten, dieses Problem zu umgehen: das erneute Generieren der Proxytypen vermeiden, den Code mithilfe des neuen Nullable<T>-Musters umgehen, oder das Schema so ändern, dass es nicht mehr das Attribut nullable="true" verwendet.

6.22 Wenn die Proxyeigenschaft in einer Webdienstproxy-Instanz auf NULL festgelegt wird, wird dadurch nicht erzwungen, dass die Anforderung direkt an den Server gesendet wird

Wenn die Proxyeigenschaft in einer Webdienstproxy-Instanz auf NULL festgelegt wird, soll damit erzwungen werden, dass die Anforderung jegliche Webproxyserver-Einstellungen umgeht und direkt an den Server gesendet wird. Diese Funktionalität funktioniert zum jetzigen Zeitpunkt jedoch nicht. Der NULL-Wert wird ignoriert, und stattdessen werden die konfigurierten Webproxyserver-Einstellungen verwendet.

So beheben Sie dieses Problem

Sie können die Proxyeigenschaft für den zugrunde liegenden WebRequest direkt durch Ableitung aus dem Proxytyp und Überschreiben der GetWebRequest-Methode festlegen:

protected override WebRequest GetWebRequest(Uri uri)
{
WebRequest req = base.GetWebRequest(uri);
req.Proxy = this.proxy;
return req;
}

6.23 Verwenden von .NET Remoting und Laufzeitserialisierung auf verschiedenen .NET Framework-Versionen

Wenn Daten zwischen Anwendungen ausgetauscht werden, die auf verschiedenen .NET Framework-Versionen ausgeführt werden (unter Verwendung von .NET Remoting- oder Laufzeitserialisierung), können bei der Serialisierung oder Deserialisierung bestimmter Framework-Typen Ausnahmen auftreten. Die Ausnahmen geben an, dass diese Typen in unterschiedlichen Framework-Versionen nicht kompatibel sind. Daher können diese Typen nicht von einer Framework-Version an eine andere Framework-Version gesendet werden.

.NET Framework 2.0 enthält eine Technologie, die als versionstolerante Serialisierung bezeichnet wird, mit der dieses Problem behoben werden kann. Für frühere Framework-Versionen besteht dieses Problem jedoch weiterhin. Daher wird ein Patch zur Verfügung gestellt, der einige Funktionen der versionstoleranten Serialisierung in .NET Framework einfügt. Für diesen Patch ist Service Pack 1 erforderlich. Nachdem der Patch installiert wurde, kann eine unter Framework ausgeführte Anwendung mit einer Anwendung kommunizieren, die unter .NET Framework 2.0 ausgeführt wird, ohne dass dieses Versionsproblem auftritt. Es ist nicht geplant, diesen Patch für .NET Framework 1.0 bereitzustellen.

Beachten Sie, dass die versionstolerante Serialisierung nur dann die Versionsprobleme behebt, wenn die binäre Serialisierung verwendet wird (entweder direkt oder über .NET Remoting). Falls die SOAP-Serialisierung (entweder direkt über die SoapFormatter-Klasse oder über .NET Remoting) für verschiedene Framework-Versionen verwendet wird, können die erläuterten Versionsprobleme weiterhin auftreten.

So beheben Sie dieses Problem

Informationen zum Abrufen dieses Patchs finden Sie im folgenden Knowledge Base-Artikel: http://support.microsoft.com/?kbid=907262.

6.24 Die Angabe einer nicht standardmäßigen Ablaufverfolgungsüberwachung für die System.Transactions-Ablaufverfolgung funktioniert nicht bei teilweiser Vertrauenswürdigkeit

Die Angabe einer bestimmten Ablaufverfolgungsüberwachung für die System.Transactions-Ablaufverfolgung in der Konfiguration wird bei teilweiser Vertrauenswürdigkeit nicht unterstützt und löst eine Ausnahme aus.

So beheben Sie dieses Problem

Die standardmäßige Ablaufverfolgungsüberwachung wird bei teilweiser Vertrauenswürdigkeit unterstützt, sodass die Ablaufverfolgungen von der Standardüberwachung aufgefangen werden und in debug.outputstring gedruckt werden. Diese Ablaufverfolgungen können mithilfe von DBMon.exe bei teilweiser Vertrauenswürdigkeit angezeigt werden.

6.25 Die Berechnungen von Datum und Uhrzeit in Webdienst- oder XML-Serialisierungsszenarios können nach der Migration zu .NET Framework 2.0 fehlerhaft sein

In NET Framework 2.0 wird ein anderes Verfahren verwendet, um Datums- und Uhrzeitangaben in XML zu schreiben bzw. aus XML zu lesen. Diese Änderung betrifft in erster Linie folgende Szenarios:

Szenarios mit Zeitangaben, für die die Zeitzone UTC (Coordinated Universal Time) oder keine Zeitzone angegeben wurde.
Interoperabilitätsszenarios mit Software von Drittanbietern, in denen Zeitwerte in XML geschrieben werden, wobei die Zeitzone UTC oder keine Zeitzone angegeben wird.

Die Änderungen können bewirken, dass Berechnungen und Vergleiche für bestimmte Datums- und Zeitangaben fehlerhaft werden. In solchen Fällen ist es unter Umständen erforderlich, das frühere Datums-/Zeitverhalten wiederherzustellen.

So beheben Sie dieses Problem

Um das frühere Datums-/Zeitverhalten wiederherzustellen, wenden Sie folgende Konfigurationsänderung an:

<system.xml.serialization>
<dateTimeSerialization mode="Local" />
</system.xml.serialization>

6.26 Windows-Benutzerprofile für die automatische ASP.NET-Datenbankerstellung mit SQL Server Express und IIS

Der automatische MDF-Erstellungsprozess von ASP.NET für SQL Serveranbieter unter SQL Server Express und IIS funktioniert nur, wenn IIS entweder als lokales ASPNET-Computerkonto oder als NT-AUTORITÄT\NETZWERKDIENST ausgeführt wird. Der automatische Erstellungsprozess funktioniert außerdem, wenn die Entwicklung mithilfe von Cassini (d. h. mithilfe dateibasierter Webserver) erfolgt. Wenn bei der Entwicklung für IIS allerdings ein anderes lokales Benutzerkonto oder ein Domänenbenutzerkonto verwendet wird, tritt beim automatischen Datenbank-Erstellungsprozess ein Fehler auf, weil diese Konten kein auf dem Webserver verfügbares Windows-Benutzerprofil aufweisen.

So beheben Sie dieses Problem

Es gibt keine Problemumgehung. Die automatische Datenbankerstellung mit SSE für IIS-basierte Websites funktioniert nur für ASPNET- und NETZWERKDIENST-Konten.

6.27 Unicode-Ersatzzeichenverhalten bei ASP.NET-Anbietern, die SQL Server 7.0 oder 2000 verwenden

ASP.NET-Anbieter, die SQL Server verwenden, sind auf die Ebene der Unterstützung von Unicode-Ersatzzeichen beschränkt, die von SQL Server 7.0 und SQL Server 2000 bereitgestellt wird. SQL Server 7.0 und 2000 können Ersatzpaare verlustfrei speichern und abrufen. Es gibt allerdings keinen linguistischen Vergleich für Ersatzzeichen. Bei Verwendung dieser SQL Server-Versionen werden Ersatzzeichen bei Vergleichsvorgängen und Prüfungen auf Eindeutigkeit ignoriert. Dies bedeutet beispielsweise, dass SqlMembershipProvider zwei Benutzernamen, die nur Ersatzzeichen enthalten, als identisch interpretiert. Dieses Verhalten verursacht beim Versuch, einen zweiten Benutzer mit einem Benutzernamen zu erstellen, der sich nur durch Ersatzzeichen von dem vorhandenen Benutzer unterscheidet, eine Verletzung der Eindeutigkeitseinschränkung.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

6.28 FileWebRequest.PreAuthenticate gibt nur false zurück

Typen, die von WebRequest erben, erben eine PreAuthenticate-Eigenschaft. Diese Eigenschaft ermöglicht, dass Authentifizierungsinformationen zusammen mit der Anforderung gesendet werden, ohne auf eine Anfrage des Servers zu warten. Da die Vorauthentifizierung von FileWebRequest nicht unterstützt wird, müsste die zugehörige PreAuthenticate-Eigenschaft immer false zurückgeben. Wenn in früheren .NET Framework-Versionen die PreAuthenticate-Eigenschaft von einer Anwendung auf true festgelegt wurde, gab sie immer true zurück, wenn ihr Wert später abgefragt wurde. Dies ist jetzt nicht mehr der Fall. Die FileWebRequest's PreAuthenticate-Eigenschaft gibt immer false zurück.

So beheben Sie dieses Problem

Benutzer sollten die PreAuthenticate-Eigenschaft für FileWebRequest nicht verwenden.

6.29 Verwenden generischer Typen mit .NET Remoting- und SOAP-Serialisierung

Die .NET Remoting-Technologie unterstützt sowohl die binäre Serialisierung als auch die SOAP-Serialisierung. Dies bedeutet, dass Remotemeldungen in einem Microsoft-spezifischen Binärformat oder als SOAP-XML dargestellt werden. Generische Typen (ein neues Feature in .NET Framework 2.0) können allerdings nur mit der binären Serialisierung verwendet werden. Die Verwendung generischer Typen mit der SOAP-Serialisierung wird weder über .NET Remoting noch durch direkte Verwendung der SoapFormatter-Klasse unterstützt.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt.

6.30 Features zur Versionszuweisung funktionieren in manchen Fällen nicht, wenn generische Typen mit .NET Remoting oder binärer Serialisierung verwendet werden

Sowohl .NET Remoting als auch die binäre Serialisierung können in einem lose verknüpften Modus arbeiten (ausgewählt durch Festlegen von FormatterAssemblyStyle auf Einfach, includeVersions auf False und strictBinding auf False), wobei die Version der Assembly eines serialisierten Typs nicht mit der Version der Assembly übereinstimmen muss, aus der der Typ bei der Deserialisierung geladen wird. Dieses Feature soll die Versionszuweisung vereinfachen. Zum Beispiel: ein .NET Remoting-Server kann aktualisiert werden, ohne dass die Clients ebenfalls aktualisiert werden müssen.

In einigen Fällen funktioniert dieser Mechanismus jedoch nicht. Die Deserialisierung kann insbesondere bei der Verwendung von generischen Typen im lose verknüpften Modus fehlschlagen, wenn sich die Version der Assembly des generischen Parametertyps ändert. Beispiel: Wenn MyType1 mit einem Typparameter des Typs MyType2 deserialisiert wird, kann die Deserialisierung fehlschlagen, wenn die Version der Assembly mit MyType2 bei der Deserialisierung von der Version bei der Serialisierung abweicht.

So beheben Sie dieses Problem

Um diese Einschränkung zu umgehen, vermeiden Sie entweder die Verwendung von generischen Begriffen in .NET Remoting bzw. bei binärer Serialisierung, wenn es wichtig ist, eine Version zuzuweisen, oder verwenden Sie das Feature zur Umleitung der Assemblybindung von .NET Framework, um die Anforderung zum Laden einer nicht vorhandenen Version der Assembly an eine Version umzuleiten, die auf dem Computer, der die Deserialisierung ausführt, vorhanden ist. Eine andere mögliche Vorgehensweise ist, das AssemblyResolve-Ereignis zu verwenden, um das Fehlschlagen des Ladens einer Assembly zu erkennen und zu versuchen, die Assembly erneut unter Verwendung nur eines Teils des Namens zu laden.

Zum Seitenanfang

7. MSDN Express

Es sind aktuell keine Probleme bekannt.

Zum Seitenanfang

8. Visual Studio Integrated Development Environment (IDE, Integrierte Entwicklungsumgebung)

Es sind aktuell keine Probleme bekannt.

Zum Seitenanfang

9. Visual Web Developer Express

9.1 Beim Ausführen eines Umgestaltungsvorgangs in einer C#-Website werden möglicherweise Buildfehler gemeldet, obwohl tatsächlich keine vorhanden sind

Wenn der Benutzer einen Umgestaltungsbefehl in einer C#-Website ausführt, die keine Buildfehler enthält, kann in bestimmten Fällen eine Warnung mit dem Hinweis angezeigt werden, dass das Projekt oder zugehörige Abhängigkeiten aktuell nicht erstellt und Verweise möglicherweise nicht aktualisiert werden.
Dieses Dialogfeld kann problemlos ignoriert werden, indem der Benutzer entweder auf die Schaltfläche Weiter oder auf Vorschau klickt. Die Umgestaltung wird erfolgreich ausgeführt, und alle Verweise werden aktualisiert.

Nachstehend werden Beispiele für allgemeine Projektkonfigurationen aufgeführt, in denen diese Warnung angezeigt wird:

Von früheren Visual Studio-Versionen migrierte Webprojekte, die im Webverzeichnis die Datei global.asax und im Verzeichnis App_Code die Datei global.asax.cs enthalten.
Webprojekte, in denen Webseiten auf Web-Benutzersteuerelemente verweisen, die wiederum auf im Verzeichnis App_Code deklarierte Typen verweisen.

So beheben Sie dieses Problem

Es ist keine Lösung bekannt. Die Warnung kann jedoch problemlos ignoriert werden.

9.2 Zeichen für keine Leerstellen sind für Verknüpfungen in C#-Codeausschnitten unzulässig

C#-Codeausschnitte werden in XML in SNIPPET-Dateien definiert. Das Schema kann beispielsweise den Tag <Shortcut></Shortcut> enthalten. Verknüpfungen ermöglichen das schnelle Einfügen von Ausschnitten. Der Benutzer muss lediglich die Verknüpfungszeichenfolge eingeben und anschließend die TAB-TASTE drücken.

Innerhalb von Verknüpfungszeichenfolgen sind zwar viele Unicode-Zeichen zulässig, doch Zeichen für keine Leerstellen sind unzulässig. Daher können einige Zeichenfolgen in manchen Sprachen nicht als Verknüpfungen verwendet werden. Wenn eine Verknüpfung, die ein Zeichen für keine Leerstellen enthält, eingegeben und anschließend die TAB-TASTE gedrückt wird, wird anstelle eines Codeausschnitts ein Tabulatorzeichen eingefügt.

So beheben Sie dieses Problem

Wählen Sie einen Unicode-Verknüpfungsnamen ohne Zeichen für keine Leerstellen aus.
Fügen Sie den Ausschnitt über die Codeausschnittsauswahl-UI ein, anstatt Verknüpfungen zu verwenden.

9.3 Das Erweitern von Datendateien im Server-Explorer in FTP-Websites kann einen Absturz der IDE verursachen

Wenn Sie eine FTP-Website öffnen und dem Verzeichnis App_Data eine Datendatei (MDB oder MDF) hinzufügen, anschließend das Server-Explorer-Fenster öffnen und die
Verbindung zu der Datendatei unter dem Knoten Datenverbindungen erweitern, kann dies dazu führen, dass die IDE abstürzt oder nicht mehr reagiert, sodass nicht gespeicherte Daten möglicherweise verloren gehen.

So beheben Sie dieses Problem

Entwickeln Sie die Website ausgehend von einem Speicherort für lokale Dateien unter Verwendung einer Dateisystem- oder IIS-Website. Verwenden Sie den Befehl Website kopieren zum Übertragen von Dateien in den bzw. aus dem FTP-Speicherort.

9.4 Die Verwendung benutzerdefinierter Typen (User-Defined Types, UDT) als Einstellung kann im Einstellungs-Designer unerwartetes Verhalten verursachen

So beheben Sie dieses Problem

Zum Seitenanfang

Verwalten Sie Ihr Profil | Impressum | MSDN Flash Newsletter | Kontaktieren Sie uns