Skip to content

Delete unnecessary test#124884

Merged
MichalStrehovsky merged 1 commit intodotnet:mainfrom
MichalStrehovsky:testdelete
Feb 26, 2026
Merged

Delete unnecessary test#124884
MichalStrehovsky merged 1 commit intodotnet:mainfrom
MichalStrehovsky:testdelete

Conversation

@MichalStrehovsky
Copy link
Member

Noticed this in #124883 but I don't think it's worth it to fix it up (it needs a fixup because the main is a global method).

See the comment. There is a bit more context on the .NET Framework side:

This tests that we throw an exception when trying to load a module that contains
two TypeDefs with the same name.  We must use binary post-processing to make this
happen since no compiler will allow us to define a duplicate type name.

For simplicity, we have an IL image checked in and we'll just copy it over
to testbin.  Since this is an IL image, it should always work.
However, if this image should ever stop working, the image can be reproduced
by doing the following:
1) ilasm test5.il
2) use pereader to dump the structure of test5.exe
3) Find the index into the string heap for the name of the "Foo" class, copy the index
4) Find the path to the index for the name of the "Bar" class
5) create a file like test5.cpt that writes the Foo index value onto the name index field of the Bar class
(thus, assigning the name "Foo" to the Bar type.)
6) use pewriter /source test5.exe /modify test5.cpt /out test5.cpt.exe to recreate the corrupted executable file.

When running this test, set the environment variable:
COMPLUS_DisableWatsonForManagedExceptions=1
to avoid a debugging pop-up dialog for the expected unhandled exception.

But basically this PE file should be modified and the test harness expects it to crash with an unhandled exception. It is not testing anything interesting without those steps.

Cc @dotnet/appmodel

See the comment. There is a bit more context on the .NET Framework side:

```
This tests that we throw an exception when trying to load a module that contains
two TypeDefs with the same name.  We must use binary post-processing to make this
happen since no compiler will allow us to define a duplicate type name.

For simplicity, we have an IL image checked in and we'll just copy it over
to testbin.  Since this is an IL image, it should always work.
However, if this image should ever stop working, the image can be reproduced
by doing the following:
1) ilasm test5.il
2) use pereader to dump the structure of test5.exe
3) Find the index into the string heap for the name of the "Foo" class, copy the index
4) Find the path to the index for the name of the "Bar" class
5) create a file like test5.cpt that writes the Foo index value onto the name index field of the Bar class
(thus, assigning the name "Foo" to the Bar type.)
6) use pewriter /source test5.exe /modify test5.cpt /out test5.cpt.exe to recreate the corrupted executable file.

When running this test, set the environment variable:
COMPLUS_DisableWatsonForManagedExceptions=1
to avoid a debugging pop-up dialog for the expected unhandled exception.
```

But basically this PE file should be modified and the test harness expects it to crash with an unhandled exception. It is not testing anything interesting without those steps.
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR deletes an incomplete/non-functional test that was testing duplicate TypeDef names in a module. The test requires binary post-processing of the PE file (using a .cpt file) to create a malformed assembly with two types having the same name, but this post-processing setup was never included in the repository. Without the PE modification, the test doesn't actually test the scenario it was designed for (loading a module with duplicate type names), making it ineffective.

Changes:

  • Removed test5.ilproj and test5.il from the Loader classloader regressions test suite

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
src/tests/Loader/classloader/regressions/181424/test5.ilproj Deleted the project file for a non-functional test that required external PE modification
src/tests/Loader/classloader/regressions/181424/test5.il Deleted the IL source for a test that can't work without binary post-processing to create duplicate TypeDef names

@MichalStrehovsky MichalStrehovsky merged commit cb7c257 into dotnet:main Feb 26, 2026
88 checks passed
@MichalStrehovsky MichalStrehovsky deleted the testdelete branch February 26, 2026 06:22
iremyux pushed a commit to iremyux/dotnet-runtime that referenced this pull request Mar 2, 2026
Noticed this in dotnet#124883 but I don't think it's worth it to fix it up (it
needs a fixup because the main is a global method).

See the comment. There is a bit more context on the .NET Framework side:

```
This tests that we throw an exception when trying to load a module that contains
two TypeDefs with the same name.  We must use binary post-processing to make this
happen since no compiler will allow us to define a duplicate type name.

For simplicity, we have an IL image checked in and we'll just copy it over
to testbin.  Since this is an IL image, it should always work.
However, if this image should ever stop working, the image can be reproduced
by doing the following:
1) ilasm test5.il
2) use pereader to dump the structure of test5.exe
3) Find the index into the string heap for the name of the "Foo" class, copy the index
4) Find the path to the index for the name of the "Bar" class
5) create a file like test5.cpt that writes the Foo index value onto the name index field of the Bar class
(thus, assigning the name "Foo" to the Bar type.)
6) use pewriter /source test5.exe /modify test5.cpt /out test5.cpt.exe to recreate the corrupted executable file.

When running this test, set the environment variable:
COMPLUS_DisableWatsonForManagedExceptions=1
to avoid a debugging pop-up dialog for the expected unhandled exception.
```

But basically this PE file should be modified and the test harness
expects it to crash with an unhandled exception. It is not testing
anything interesting without those steps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants