Why does VB.net compiler crash after I move my project?
I am migrating data from an old laptop to a new laptop, including some vb.net projects in visual studio 2008. But when I try to open some of them on a new laptop, I quickly get a dialog that says the vb compiler crashed and asked me, whether I want to close, debug, or test online solutions. Then the visual studio closes.
Projects don't crash when opened on an old laptop, and other migrated projects open without crashing. Thus, it must be some property of projects that get damaged by moving them.
I did a search and found posts from people with similar problems, but there were no answers. Why is this happening and how can I fix it?
Error details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: devenv.exe
Application Version: 9.0.21022.8
Application Timestamp: 47317b3d
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18215
Fault Module Timestamp: 4995344f
Exception Code: e06d7363
Exception Offset: 0002f328
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 4105
Additional information about the problem:
LCID: 1033
Read our privacy statement:
http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0409
The old laptop is Windows XP and is using visual studio professional. The new laptop is Windows Vista and uses a visual studio team. "Transfer" is a direct copy of the original files.
a source to share
The project crashes because anything equivalent to the following code snippet crashes VS2008 but not VS2008 SP1:
Public Class B(Of T)
Protected Function P(ByVal arg As T) As Boolean
End Function
End Class
Public Class C
Inherits B(Of Integer)
Private Sub New(ByVal arg As Integer)
Dim d = Function() P(arg)
End Sub
End Class
Notes:
- Upgrading to SP1 fixes the problem.
- There is nothing special about "Boolean" or "Integer", they were just convenience types
- The combination of both subsystems in one class makes the problem go away.
- Using a non-shared argument in a base class function causes the error to disappear.
- Using a non-constructor in a child class causes the error to disappear.
- Translating the error naively into C # does not crash the C # compiler.
I can finally blame it on the compiler. Not my fault!
a source to share