Repository navigation
Tests: Code changes require manual rebuild before testing #391
Description
Issue
Currently, if one modifies code in the ILRepack project, he must do a rebuild of first the ILRepackTool and then the senario projects. Otherwise, a stale version is tested by the scenario tests and therefore producing confusing/wrong test results.
Expectation
Running any test should automatically compile everything necessary beforehand.
Bugfixing Issues
ILRepackTool is .NET 8 and some integration test scenario projects are .NET Framework which makes ProjectReferences difficult.
Possible Solution: Repair ILRepack.targets
It seems this was originally the way to enforce that, but doesn't work anymore.
Don't add a project-reference to ILRepack anymore as this doesn't trigger the build process because ILRepackTool is actually used to repack the scenario projects. On the other hand, adding a reference to ILRepackTool would introduce other issues (multi-targeting, dotnet-tool packaging issues).
Adding simple MSBuild targets to ILRepack.targets and ILRepack.IntegrationTests.csproj to ensure ILRepackTool and the scenario projects are built beforehand seems to be a way around the mentioned issues.
A PR for this will follow.
Activity
warappa commentedon Feb 9, 2025
OK, I'm running into a non-related problem:
The MSBuild targets work basically, but now I found out that ILRepackTool only works for .NET Core assemblies. .NET Framework assemblies have assembly resolution issues!
Warning
This is a general issue of dotnet-tool version of ILRepack (using .NET 8.0), as it means that non-.NET-Framework builds of ILRepack have issues with .NET Framework assemblies!
Background
As ILRepackTool is on .NET 8 and not on .NET 4.7.2, it uses another build of Mono.Cecil - the netstandard2.0 one, not the net40 one. Mono.Cecil has in its source code preprocessor directives to switch between .NET Framework and .NET Core resolution types. This is bad because it is not based on the current input assembly, but on the target-framework of Mono.Cecil itself!
This was already reported in the upstream project: jbevain/cecil#863
ILRepack seems to have a workaround for the .NET Framework builds to work with .NET (Core) assemblies (
TryResolveFromCoreFixVersion).Next Steps
Switching back to ILRepack while still ensuring that all assembiles are up-to-date before test runs.