Fehlermeldung mit „DotNetOpenAuth.Core“ in ASP.NET MVC beseitigen

Eine neue Website mit ASP.NET MVC 4, frisch auf einen Server publiziert, lieferte die Fehlermeldung:

Die Datei oder Assembly „DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246“ oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)

Im Englischen klingt das ungefähr so:

Could not load file or assembly ‚DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246‘ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Nach viel Suchen, fand ich schließlich die Lösung:

Da ich dieses „DotNetOpenAuth.Core“ via NuGet installiert hatte, wurde in meiner lokalen Web.config-Datei automatisch Einträge ergänzt. Diese Einträge haben im öffentlichen Web auf dem Webserver noch gefehlt.

Hier der komplette Ausschnitt:

<runtime>
 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
 <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
 <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
 <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
 <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-2.2.13.0" newVersion="2.2.13.0" />
 </dependentAssembly>
 </assemblyBinding>

Sobald ich das ergänzt hatte, war der Fehler weg.

Fehlermeldung „CS0103: Der Name ‚ViewBag‘ ist im aktuellen Kontext nicht vorhanden“ bei ASP.NET MVC 4 lösen

Heute habe ich bei einem neu deployten Projekt mit ASP.NET 4.5 und MVC 4 folgende Fehlermeldung erhalten:

CS0103: Der Name ‚ViewBag‘ ist im aktuellen Kontext nicht vorhanden
CS0103: The name ‚ViewBag‘ does not exist in the current context

Eine ähnliche Meldung lautet:

CS0103: Der Name ‚model‘ ist im aktuellen Kontext nicht vorhanden
CS0103: The name ‚model‘ does not exist in the current context

Lokal lief alles, auf dem Produktivserver kam die Fehlermeldung. Ich habe lange gesucht, bis ich die funktionierende Lösung gefunden habe.

Lösung

Die Lösung war im Endeffekt, dass es zwei Web.Config-Dateien gibt:

Diese im Views-Ordner hat bei mir gefehlt. Sobald ich diese hinzugefügt und entsprechend gefüllt hatte, hat alles funktioniert.

How to solve „An app on your PC needs the following Windows feature: .NET Framework 3.5 (includes .NET 2.0 and 3.0)“ on Windows 8

Are you a software developer and ever got this message when testing your .NET 2.0 WinForms application on Windows 8?

An app on your PC needs the following Windows feature: .NET Framework 3.5 (includes .NET 2.0 and 3.0)

An app on your PC needs the following Windows feature: .NET Framework 3.5 (includes .NET 2.0 and 3.0)

Even though your application would run on .NET 4, too?

Here is my story on why this happended to me and how to solve.

Why this happens

When you run a .NET application, Windows 8 seems to check whether the required .NET Framework is available. If it is not available, the above message is being displayed.

How to solve it

Windows 8 cannot know whether your application, compiled for .NET 2, also runs on .NET 4. It has the following knowledge:

  • The .NET Framework you compiled your application for
  • The processor bitness you compiled your application for (i.e. „x86“ or „Any CPU“)

If you want Windows 8 to be aware of anything other, you have to tell. To change the .NET Framework version, I created a configuration file with the same name as the application, in the same folder.

E.g. if your application is „my-app.exe“, your configuration file has to be „my-app.exe.config“. I use the following content of the file:

<?xml version="1.0"?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v2.0.50727"/>
        <supportedRuntime version="v4.0"/>
    </startup>
</configuration>

I.e. you have to tell the supported runtime.

This is sometimes not enough, though. In my scenario, I had the application compiled as „Any CPU“ and configured for V2.0.50727 and v4.0 but still the above Windows message appeared.

My mistake was that on the test system, I only had a 32 bit V2.0.50727, not 64-bit, although the Windows itself was 64-bit. (I don’t know whether a 64-bit version of the .NET Framework exists at all)

So to solve this, I re-compiled the application to „x86“ and then, everything worked perfectly.

(Please correct me if any of my technical assumptions above are wrong)

Fehlermeldung „Ein Clientvorgang ist fehlgeschlagen“ beim Öffnen fremder Postfächer in Outlook 2010

Obwohl ich Administrator bin, bekomme ich beim Öffnen von eingebundenen Microsoft-Exchange-Postfächern anderer Benutzer eine Fehlermeldung:

Der Ordner kann nicht erweitert werden. Ein Clientvorgang ist fehlgeschlagen.

Fuck for Outlook/Exchange.

Die Lösung (zumindest bei mir) sah dann so aus:

  1. Auf Exchange-Server mit RDP anmelden.
  2. Die „Exchange Management Console“ starten.
  3. Den Baum aufklappen:
    • Microsoft Exchange
    • Microsoft Exchange lokal
    • Empfängerkonfiguration
    • Postfach
  4. In der Liste im Hauptfenster dann das Postfach selektieren.
  5. Im rechten Bereich „Aktionen“ (oder via Rechtsklick auf Element) die Aktion „Berechtigung ‚Vollzugriff‘ verwalten…“ auswählen.
  6. Im erscheinenden Assistent auf „Hinzufügen“ klicken.
  7. Den entsprechenden Benutzer suchen, auswählen und mit „OK“ bestätigen.
  8. Den Assistent mit der „Verwalten“-Schaltfläche“ durchlaufen lassen.
  9. Via „Fertig stellen“ den Assistent schließen.

Ich musste dann mein Outlook 2010 nochmals starten, danach konnte ich aufs Postfach zugreifen. Insgesamt eher eine Brute-Force-Methode, für mich war’s ausreichend.

Fixing „A dynamic link library (DLL) initialization routine failed.“ error on Windows 8

Just fixed an issue with our Zeta Producer 11 that occurs only on the brand new Windows 8. The German error message was:

Die Datei oder Assembly „ZetaHtmlTidy.dll“ oder eine Abhängigkeit davon wurde nicht gefunden. Eine DLL-Initialisierungsroutine ist fehlgeschlagen. (Ausnahme von HRESULT: 0x8007045A)

Translated to English it was:

System.IO.FileLoadException ‚A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)‘

The DLL in concern was a mixed Managed/Unmanaged C++ assembly that wrapped the popular HTML Tidy C sources into a .NET-usable assembly.

So my first idea was that some CRT DLLs were missing:

  • msvcm90.dll
  • msvcp90.dll
  • msvcr90.dll
  • Microsoft.VC90.CRT.manifest

But all were present, even the well-known Dependency Walker/Viewer did not help any further.

Since version 10 of our application worked and version 11 did not work and brought the above error, I was clueless. The main difference was:

  • Version 10 was installed into „C:\Program Files (x86)\Zeta Producer 10“.
  • Version 11 was installed into „C:\Users\YourName\AppData\Local\Zeta Producer 11″ (to bypass administrative setup permissions).

When I moved Version 10 also below the „C:\Users\…“ folder, the error also occurred!

So the cause was not a missing assembly but some kind of (weird?) policy thing.

Some further digging/googling finally lead to the solution on Stack Overflow. The solution was to add some more App.config settings.

My previous, non-working App.config file contained:

<startup>
    <supportedRuntime version="v2.0.50727"/>
    <supportedRuntime version="v4.0"/>
</startup>

My new, working App.config file was:

<startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v2.0.50727"/>
    <supportedRuntime version="v4.0"/>
</startup>

So it seems that setting „useLegacyV2RuntimeActivationPolicy“ to „true“ finally switched something to allow for loading mixed-mode DLLs from local folders. Doh!

Solving „Exception of type ‚System.ComponentModel.Design.ExceptionCollection‘ was thrown.“ error messages in Visual Studio .NET 2010 Windows Forms Designer

Recently I got an error message

---------------------------
Microsoft Visual Studio
---------------------------
Exception of type 'System.ComponentModel.Design.ExceptionCollection' was thrown.
---------------------------
OK
---------------------------

when trying to edit a form in the Windows Forms Designer of Visual Studio .NET 2010. Searching Google for this error brought up some results but didn’t help me.

There was one hint that stated:

Sometimes I get the message „Exception of type ‚System.ComponentModel.Design.ExceptionCollection‘ was thrown“ When trying to open a Form in designer view.

The real problem of the „ExceptionCollection“ being thrown is that when there is a WSOD (White Screen of Darn) indicating a designer load issue, the designer gets unloaded. These get caught by the unload method and get displayed in the dialog box you see.

So, to fix this you should:

  • Attach a visual studio debugger to VS. Turn on exception catching when first thrown (in the Debug|Exceptions menu).
  • Open the designer with the debugger attached
  • Determine what component is throwing the exception.

This was actually a copy from a Microsoft Connect bug report. I tried this, but the error message still popped up and the debugger never stopped at this message (although it stopped at other native errors).

Steps to solve

Since all this didn’t help, I did another approach that was finally successfully:

  1. Make a SVN commit for the file.
  2. Open the „*.designer.cs“ file of the form that shows the error in source view.
  3. Remove larger blocks of form element declarations.
  4. Fix all compilation errors with ReSharper (i.e. ensure that nothing is red anymore on the side-indicator).
  5. Save the file. No need to compile.
  6. Open the Windows Forms Designer of the form.
  7. If the error still shows up, do a SVN revert to go back to the initial state.
  8. Repeat steps 2 to 7 until the error does not show up anymore.
  9. Now you’ve encircled the erroneous child control that causes the error.
  10. Repeat steps 2 to 7 with a smaller amount of controls you remove, until you have only one control left.

In my case it was a user control inside a group control inside a tab control, so I first identified the tab control, then the group control and then the user control.

You could isolate the user control inside a new form to further investigate. In my case it was rather easy; I put checks for design mode around most of the functions inside my control to ensure the code only gets executed if the control is not in design mode.

This fixed my error.

See also:

Automatically restart Microsoft IIS if website is not available

To automatically restart the Microsoft Internet Information Services (IIS) web server if a website is not available, you need:

  • Administrative access to your web server.
  • The WGET command line utility.
  • A text editor like Notepad to create a batch script file.
  • the Task Scheduler to make the batch script run every n Minutes (e.g. every 10 Minutes)

The batch file I created for one of my own web servers looks like:

@REM ==============================================
@REM Automatically restart IIS if website is not available.
@REM (Checks for a sub string in a page of the website).
@REM
@REM Created 2011-10-28, Uwe Keim uk@zeta.li
@REM ==============================================

@REM Remove any existing previous downloads.
del d:\scripts\index.html

@REM Change drive and folder so that WGET stored in a
@REM well-defined location.
D:
cd d:\scripts

@REM Download file.
D:\scripts\wget.exe ^
    --timeout=30 ^
    --tries=1 ^
    http://www.my-server.com/index.html 

@REM Search for the term in the previously downloaded file.
find /I /C "Some String On Website" d:\scripts\index.html

@REM Restart IIS if string is not found.
IF ERRORLEVEL 1 iisreset /RESTART /TIMEOUT:120 /REBOOTONERROR

Please note the following:

  • WGET downloads the URL to a file with the same file name („index.html“ in my above example)
  • The scheduled task must be created to run with an administrative user.
  • The scheduled task must have the „Run with highest privileges“ checkbox set, because IISRESET only runs with administrative privileges.

Fehlermeldung „Column does not belong to table“

Bei mir trat/tritt von Zeit-zu-Zeit die Fehlermeldung „Column does not belong to table“ auf, jeweils mit einer angegebenen Spalte, z.B.

Column ‚TestPlanID‘ does not belong to table

Oder

Column ‚ParentID‘ does not belong to table

Bzw. auf Deutsch

Spalte ‚RunnableTestCaseID‘ gehört nicht zu Tabelle

Da das nur teilweise auftritt und nur bei manchen Kunden und nur wenn viele SQL-Anfragen hintereinander ausgeführt werden, hat mir dieser Blogpost hier geholfen.

Der Autor dort geht davon aus, dass er ggf. Connections nicht rechtzeitig schließt. Als er das beseitigt hatte und der Fehler immer noch auftrat, hat er folgende Schlussfolgerungen/Aktionen daraus gezogen:

  1. Use „iisreset“ command every time you stop the IIS server.
  2. Walk through your code and make sure you are closing connection properly.
  3. Use „Connection Lifetime“ property of connection pool if required.
  4. Try to use ClearAllPools/ClearPool in appropriate application event.

Bei mir hat das teilweise geholfen, ggf. ist das ja doch irgend ein .NET-Bug, der irgendwann mal mit den neuesten Treibern für Microsoft SQL Server beseitigt sind.

Ergänzung 1:

Gerade heute bekomme ich wieder eine ähnliche Meldung bei einem Oracle-Projekt:

Column „FACH“ does not belong to table

Ich deute das so, dass das auch beim Oracle-Treiber so ein Issue ist. Es handelt sich hier um eine ASP.NET-4.0-Webanwendung. Andere sprechen auch darüber, dass es bei Ihnen auch bei Oracle auftritt. Vermutlich also ein Issue in ADO.NET. Einer schreibt:

We had this exact problem and we solved it.

Using static (C#) or shared (VB) .Net data classes on a multi-processor server will cause this error. The data class and its objects, e.g. DataTable, get resused across threads for some reason. So when when two requests come in at the same time, the second request overwrote the DataTable object variable with its own results, causing the first request to fail when it went looking for its tables, columns, etc.

This problem only occurred on multi-processor servers and went away when we declared our data classes without static or shared.

Wobei ich ihm das nicht ganz glaube. der Oracle provider hat auch eine Funktion ClearAllPools/ClearPool, diese werde ich jetzt mal aufrufen.

Ergänzung 2:

Den Fehler konnte ich jetzt beim Oracle erfolgreich beseitigen, indem ich meinen (eigenen) Cache deaktiviert habe. Eventuell hängt es mit dem Background-Cache-Aufräumen zusammen oder mit zu vielen Elementen im Cache.

Ergänzung 3 (2013-04-22):

Hatte jetzt erneut so einen Fall, den ich durch Cache-Deaktivieren lösen konnte.

Eventuell ist es ja sinnvoll, wenn eine DataTable aus dem Cache geholt wird, diese zu clonen, so dass nur die gleiche, nicht jedoch dieselbe DataTable genutzt wird und es so nicht zu Concurrency-Issues kommen kann. (Habe das jetzt probiert, hat in meinen Tests keine Änderung gebracht, leider).

C#-Windows Forms-Designer-Fehlermeldungen in Visual Studio.NET 2005

(View this article in Google-translated English)

Dieser Artikel hier soll mein Versuch werden, verschiedene Fehlermeldungen im leider nicht perfekten C#-Windows Forms-Designer von Visual Studio.NET 2005 zu interpretieren und möglichst zu lösen.

Ich werde den Artikel nach und nach um alle im Laufe der Zeit bei mir so auftretenden Fehlermeldungen und möglichst auch Lösungen ergänzen.

1.) Fehlermeldungen aufgrund von Fehlern im eigenen Code

Der Windows Forms-Designer ruft auch während des Designens Code auf den Ihr geschrieben habt (Details habe ich nie erforscht, welchen und was er ausführt, aber zumindest der Konstruktor des Forms wird aufgerufen).

Deshalb kann es vorkommen, dass Code von Euch Ausnahmen werfen, die wiederum im Designer dann sichtbar werden und ein graphisches Arbeiten verhindern. Z.B. nachfolgendes Bildschirmfoto:


Bildschirmfoto 1: Fehlermeldungen im Form-Designer (Klick für Großbild)

Textuell kommt folgende Fehlermeldung:

Object reference not set to an instance of an object.

at System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object component, Object value)
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase. DeserializeAssignStatement( IDesignerSerializationManager manager, CodeAssignStatement statement )
at System.ComponentModel.Design.Serialization.CodeDomSerializerBase. DeserializeStatement( IDesignerSerializationManager manager, CodeStatement statement )

Wichtig zu verstehen ist, dass es eine beliebige Fehlermeldung sein kann, nicht nur die hier oben angegebene Null-Referenz-Ausnahme.

In meinem Beispiel war folgendes die Ursache:

Ich habe in dem Form eine eigenes Benutzer-Steuerelement („UserControl“) verwendet, das im Designermodus eine Ausnahme ausgelöst hat, und zwar beim Zuweisen einer Eigenschaft.

Der Grund für diese Ausnahme im Steuerelement war, dass zur Laufzeit gewisse Ereignis-Behandlungsroutinen aufgerufen werden (z.B. das „Load“-Ereignis des Formulars) und in diesen Behandlungsroutinen dann Variablen initialisiert werden.

Im Designmodus werden diese Behandlungsroutinen nun eben nicht aufgerufen und die Variablen eben nicht initialisiert. Deswegen hat dann die Eigenschaft eine Ausnahme ausgelöst.

Auch wenn im Designer-Fenster keine genaue Fehlerposition angegeben wurde, so zeigte die „Error List“ die genaue Position an, und zwar in Form einer „Warning“ (siehe Bildschirmfoto oben).

Ein Doppelklick auf die „Warning“-Liste öffnete dann die „*.designer.cs“-Quelltextdatei und zeigte wo der Fehler war. In meinem Beispiel war das die Zeile

this.imageControl.ImageObjectID = null;

Ein beherzter Rechtsklick mit der Maus auf ImageObjectID und dann „Go to Definition“ öffnete dann den Quelltext der ImageObjectID-Eigenschaft meines Benutzer-Steuerelements im Editor. Darin war also irgendwo der Fehler.

Lösung:

Oftmals war es für mich gar nicht nötig den genauen Fehler zu lokalisieren, da dieser ja nur im Designmodus auftrat; zur Laufzeit verhielt sich die Anwendung korrekt.

Deswegen habe ich mir eine statische Methode geschrieben die prüft, ob ein Steuerelement im Designmodus ist:

/// <summary>
/// Checks whether a control or its parent is in design mode.
/// </summary>
/// <param name="c">The control to check.</param>
/// <returns>Returns TRUE if in design mode, false otherwise.</returns>
public static bool IsDesignMode(
  Control c )
{
  if ( c == null )
  {
    return false;
  }
  else
  {
    while ( c != null )
    {
      if ( c.Site != null && c.Site.DesignMode )
      {
        return true;
      }
      else
      {
        c = c.Parent;
      }
    }

    return false;
  }
}

Diese Funktion, zentral abgelegt, rufe ich immer dann auf, wenn ich einen Codeblock quasi für den Designmodus „auskommentieren“ möchte, also eben nicht ausführen.

Ein Bisschen ein Hack, aber sehr effektiv und funktionierend.

Alternative Lösung:

Wenn Eigenschaften nicht zur Laufzeit gesetzt werden müssen, folgende Attribute an die Eigenschaft anhängen:

[Browsable(false)]
[EditorBrowsable(EditorBrowsableState.Never)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]

Das sorgt dafür, dass der Designer die Eigenschaften komplett in Ruhe lässt.

Falls Ihr nachträglich diese Attribute setzt, müsst Ihr in den Designer-Dateien bereits vorhandene unnötige Zuweisungen zu den Eigenschaftswerten entfernen, damit es im Design-Modus funktioniert.

2.) Ein Form das im Designer geöffnet wird ist leer und zeigt keine Steuerelemente mehr an

Ich hatte einige wenige Male das Phänomen, dass ein bereits funktionierendes Formular mit zahlreichen Steuerlementen auf einmal beim Öffnen im Form-Designer komplett leer war.


Bildschirmfoto 2: Leeres Form im Form-Designer (Klick für Großbild)

Ein Blick in die „*.designer.cs“-Datei des Forms zeigte dann, dass ganz am Ende der Funktion InitializeComponent eine oder beide dieser Zeilen fehlte:

this.ResumeLayout( false );
this.PerformLayout();

Nachdem ich diese ergänzt hatte, das Form wieder geschlossen, neu kompiliert und geöffnet hatte, war alles wieder im Form-Designer vorhanden und auch zur Laufzeit voll funktionsfähig. Manchmal reicht auch schlicht das Ergänzen der fehlenden Zeile, ohne ein Neukompilieren.


Bildschirmfoto 3: Korrekt gefülltes Form im Form-Designer (Klick für Großbild)

Die Ursache warum der Form-Designer den Code gelöscht hat ist mir leider unbekannt.

Bei meinen Fällen war danach auch der Code dauerhaft vorhanden. Jörg hat leider die Erfahrung gemacht, dass nach jedem manuellen Einfügen und Schließen der Datei, der Form-Designer den Code erneut gelöscht hat. Bei Jörg war es ein Formular mit sehr vielen Steuerelementen (ca. 200), ggf. könnte(!) das eine Ursache gewesen sein.

3.) Die Zuordnung der Eigenschaften Form.AcceptButton und Form.CancelButton gehen verloren

Relativ oft passiert es mir, dass ich einem Form im Form-Designer via Eigenschaftsfenster die Werte für Form.AcceptButton und Form.CancelButton zuweise (also die Schaltflächen die beim Benutzen der Eingabetaste bzw. der Escape-Taste ausgelöst werden) und irgendwann die Zuordnungen wieder verschwunden sind.

Die genaue Ursache kann ich leider nicht ermitteln, mir ist aber aufgefallen wenn ich Änderungen im Form-Designer Rückgängig mache (über Strg+Z oder den „Rückgängig“-Eintrag im „Bearbeiten“-Menü), die Zuordnung auch verschwindet. Ggf. hängt das damit zusammen.

Dieser Punkt ist jetzt nicht mission critical, aber dennoch lästig, weil es halt nicht sofort auffällt.

Manchmal bin ich jetzt dazu übergegangen, im Konstruktor eines Form, nach dem automatisch generierten Aufruf zu InitializeComponent() die Zuordnungen manuell hinzuschreiben, so dass diese dauerhaft erhalten bleiben.

4.) Die Schaltflächen (ToolStripItems) einer Werkzeugleiste (MenuStrip) werden nicht mehr dargestellt

Diesen Effekt hatte Kollege Thilo einmal gehabt, mit dem Ergebnis, dass die Werkzeugleiste komplett „leer“ dargestellt wurde.

Es ist nach einem Absturz der Visual Studio .NET 2005-IDE aufgetreten.

Im Endeffekt haben einige Zuordnungen in der „*.designer.cs“-Quelltextdatei gefehlt.

So sahen die relevanten Zeilen direkt nach dem Absturz aus:

...
//
// toolStrip1
//
this.toolStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.toolStripSeparator1,
this.toolStripSeparator2,
this.toolStripSeparator3});
this.toolStrip1.Location = new System.Drawing.Point(0, 24);
this.toolStrip1.Name = "toolStrip1";
this.toolStrip1.Size = new System.Drawing.Size(809, 25);
this.toolStrip1.TabIndex = 5;
this.toolStrip1.Text = "toolStripMain";
...

Und so die manuell korrigierte, wieder funktionierende Version:

...
//
// toolStrip1
//
this.toolStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.btnPublish,
this.toolStripSeparator1,
this.btnPGedit,
this.btnPGadd,
this.btnPGdel,
this.toolStripSeparator2,
this.btnAGedit,
this.btnAGadd,
this.btnAGdel,
this.toolStripSeparator3,
this.btnAedit,
this.btnAadd,
this.btnAdel});
this.toolStrip1.Location = new System.Drawing.Point(0, 24);
this.toolStrip1.Name = "toolStrip1";
this.toolStrip1.Size = new System.Drawing.Size(809, 25);
this.toolStrip1.TabIndex = 5;
this.toolStrip1.Text = "toolStripMain";
...

Thilo konnte das aus einer Sicherheitskopie (auch „Backup“ genannt) wiederherstellen.

An dieser Stelle mal der erneute Hinweis, wie wichtig Sicherheitskopien sind!

Ich „zippe“ mir immer mal wieder komplette Projektstände und speichere sie mit Datum versehen in einen Ordner (z.B. mit dem Dateinamen „myproject – 2006-07-18.zip“), so dass ich auch mehrere Schritte zurückgehen kann.

Siehe auch: Solving „Exception of type System.ComponentModel.Design.ExceptionCollection was thrown.“ error messages in Visual Studio .NET 2010 Windows Forms Designer