- When this problem occurs, you do not receive an error message.
- You may experience this problem intermittently. For example, you may be able to temporarily resolve this problem by cleaning the solution. However, cleaning the solution is not a permanent resolution. The problem may reoccur if the file reference pattern that is mentioned in the "Cause" section is not modified.
- Because the method call is missing from the MSIL code, breakpoints that you set on this line in the source code may move to the next line during debugging.
- The solution contains five or more projects, arranged in a specific configuration. For example, the solution contains five projects that are named Project 1, Project 2, Project A, Project B, and Project C.
- Project 1 has project references to Project A and to Project B. Additionally, Project 1 has a file reference to Project C.
- For more information about project references, visit the following Microsoft Web site:
- A file reference is a direct reference to the compiled assembly.
- Project C has references to Project A and to Project B. These references can be either file references or project references.
- Project 2 has a file reference to Project A.
- You have a class or an interface that is named AA and that is defined in Project A.
- You have a generic class that is named ClassB that is in Project B and that has an interface constraint on a type parameter T for AA.
- You have a class that is named ClassC in Project C and that inherits from ClassB.
- The generic type argument that you use to pass to ClassB is defined in any project that is a file reference in Project 1.Note This project can be Project C itself.
- You make a call to such a class from Project 1.
Note Because this bug applies only to a very specific scenario, it is unlikely that you will experience this problem.
Article ID: 945425 - Last Review: Dec 31, 2007 - Revision: 1