Opened 12 years ago

Closed 11 years ago

Last modified 10 years ago

#146 closed Bug (fixed)

First start fails with FileNotFoundException

Reported by: Matthäus Wander Owned by: Matthäus Wander
Priority: Important Milestone: CrypTool 2.0 BETA 6
Component: CrypStartup Keywords:
Cc:

Description

  • Close VS2010
  • Delete subdirectory CrypBuild\ or just CrypBuild\x86\Debug\AppReferences\DevComponents.*.dll
  • Open CT2 public solution
  • Build, Run

Expected: CT2 should start.

Actual: Build completes successfully, but CT2 startup fails with FileNotFoundException (DevComponents.WpfRibbon can not be found).

Workaround: Stop execution, start again. CT2 starts as expected.


Enable the Fusion Log Viewer to reproduce the error cause: set HKLM\Software\Microsoft\Fusion\LogFailures as REG_DWORD to 1

Start fusionlogvw.exe as administrator, go to Settings and enable "Log bind failures to disk".

Remove CrypBuild directory again, then open the public solution. Note that VS creates the following files (before the build process has been started):

  • CrypBuild\x86\Debug\CrypStartup.exe.config
  • CrypBuild\x86\Debug\CrypStartup.exe.vshost.exe
  • CrypBuild\x86\Debug\CrypStartup.exe.vshost.exe.config
  • CrypBuild\x86\Debug\CrypStartup.exe.vshost.exe.manifest

Refresh Fusion Log Viewer. Note, that CrypStartup.vshost.exe attempts to load the three DevComponents.*.dll assemblies and fails, as the build process has not been executed and thus the assemblies have not been copied yet.

Build and run CT2. The PreBuild events copy the missing assemblies, but VS does not attempt to search again for the assemblies:

  1. Fusion Log Viewer does not show another failure message
  2. If you run procmon.exe, you won't see any file access to CrypBuild\x86\Debug\AppReferences\Dev...
  3. In the details of the FileNotFoundException you will find the following message: "LOG: The same bind was seen before, and was failed with hr = 0x80070002."

Change History (12)

comment:1 Changed 12 years ago by Matthäus Wander

Workaround 2: Open DevComponents* References of CrypStartup, set Copy Local to true. VS will not attempt to load DevComponents* before the build has run, if it knows that it will have to copy the assembly first. Disadvantage: DevComponents* assembly duplicates will be placed in CrypBuild\x86\Debug\. We could add PostBuild events to remove the duplicate assemblies (would probably fix bug, but is a rather bad design).

comment:2 Changed 12 years ago by Matthäus Wander

Component: GeneralCrypStartup

comment:3 Changed 12 years ago by Paul Lelgemann

Summary: Build fails with FileNotFoundExceptionFirst start fails with FileNotFoundException

Another interesting fact is, that it behaves different depending on how you execute the first launch of CrypStartup.

  1. Perform the initial build
    • Case 1: Start CrypTool with VS: the mentioned error occurs
    • Case 2: Do not start CrypTool within VS, but start CrypStartup.exe directly using the explorer

In Case 2, no error will occur.

comment:4 Changed 11 years ago by Matthäus Wander

@Paul: Yes, because if you start it directly the newly started .NET engine checks for the DevComponents assembly at a moment where it really exists (after the build process has been finished).

If you start it from VS it does not look again for the DevComponents assembly but reuses the result from the previous load attempt (where it has failed because .NET was looking for the assembly *before* the build process was run).

comment:5 Changed 11 years ago by Matthäus Wander

This issue is somewhat more serious than assumed:

  • run build
  • close VS
  • re-open VS, rebuild

Expected: shall attempt to copy AppReferences again to CrypBuild\*\AppReferences (if any binary has been updated or if there is a new binary).

Actual: starts copying but then fails at CrypBuild\*\AppReferences\DevComponents.WpfDock.dll because file is locked (Unzulässiger SHARE-Vorgang). Still, build continues to run and doesn't show any error because after the AppReferences copy command there is another copy command which succeeds, thus the PostBuild events return no error code.

comment:6 Changed 11 years ago by Matthäus Wander

(In [2377]) * Added CopyL10N command line tool to copy CrypWin and AnotherEditor localization resource files to AppSpecialReferences

  • Modified postbuild events so that CrypStartup copies the whole content of the AppSpecialReferences directory to CrypBuild
  • The current trunk build process is broken, see #146 (FileNotFoundException occurs and AppReferences copy fails). It works mostly, though.

build tool (core solution only) override-bad-extension: CopyL10N.exe

AppSpecialReferences: override-bad-extension: AnotherEditor.dll override-bad-extension: AnotherEditor.resources.dll override-bad-extension: CrypWin.resources.dll

comment:7 Changed 11 years ago by Matthäus Wander

Solution proposal (German): AppReferences und AppSpecialReferences abschaffen und die binaries direkt in CrypBuild ablegen. Das bedeutet, Libs laden wir nicht nach AppReferences hoch, sondern nach CrypBuild/Libs, und CrypWin/AnotherEditor werden nicht nach bzw. von AppSpecialReferences kopiert, sondern direkt nach CrypBuild gebaut und dort eingecheckt.

Vorteile:

  • FileNotFoundException beim Start gefixt
  • Die mittlerweile relevanten Localization-Resource-Dateien von CrypWin und AnotherEditor werden an der richtigen Stelle abgelegt (momentan werden sie nicht in AppSpecialReferences kopiert und damit für Nicht-CoreDevs gar nicht rüberkopiert -> z. Zt. keine deutsche Version von CrypWin und AnotherEditor für Trunk-Entwickler)
  • Fast alle PostBuild-Events sind nicht mehr notwendig, was bei zukünftigen Änderungen an der Solution ein wenig robuster ist als bislang

Nachteile:

  • Wenn man CrypBuild komplett löscht, muss man vor dem Rebuild zunächst einen SVN-Checkout durchführen
  • Auch wenn ein CoreDev beim Build die kompilierten Localization-Resource-Dateien an der richtigen Stelle ablegt, muss er neue Dateien trotzdem 1x händisch zum Repository hinzufügen
  • Wenn ein CoreDev "Clean Solution" durchführt, werden relevante binaries gelöscht. Bis zum nächsten Rebuild sollte man also nicht unbedacht CrypBuild committen.

comment:8 Changed 11 years ago by Matthäus Wander

Owner: changed from saternus to Matthäus Wander
Status: newassigned

We decided to not adopt the proposed solution because of the disadvantages. Thus, the issue remains.

Please keep in mind: copying the AppReference and AppSpecialReferences is error-prone (see comment 5) and will fail in some situations! This issue is not just a harmless exception!


Last edited 11 years ago by Matthäus Wander (previous) (diff)

comment:9 Changed 11 years ago by Matthäus Wander

Resolution: fixed
Status: assignedclosed

(In [3646]) CrypStartup:

  • Implemented workaround to close #146: set CopyLocal=true for relevant binaries
  • This leads to duplicate DevComponents.*.dll files but only for trunk developers (not nightly builds) and is thus acceptable

comment:10 Changed 11 years ago by Matthäus Wander

(In [3647]) * the same error that led to startup failures in trunk sln (#146) also leads to startup failures in core sln (#301)

  • implementing the same workaround as in r3646: use CopyLocal=true for DevComponents.WpfDock.dll, DevComponents.WpfEditors.dll, DevComponents.WpfRibbon.dll
  • moving DevComponents.*.dll from AppReferences to AppSpecialReferences -> they will be placed after build in CrypBuild root (instead of AppReferences subdirectory, thus no duplicates)
  • this closes #301 and refs #146

override-bad-extension: DevComponents.WpfDock.dll override-bad-extension: DevComponents.WpfEditors.dll override-bad-extension: DevComponents.WpfRibbon.dll

comment:11 Changed 11 years ago by Matthäus Wander

(In [3648]) wrong pathes (refs #146 #301)

comment:12 Changed 10 years ago by Matthäus Wander

Milestone: CrypTool 2.0 RELEASECrypTool 2.0 BETA 6
Note: See TracTickets for help on using tickets.