Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: removing the reason of bindingRedirect doesn't trigger exe.config file to be regenerated #9773

Open
Stalli opened this issue Feb 23, 2024 · 6 comments · Fixed by #11012 · May be fixed by #11411
Open

[Bug]: removing the reason of bindingRedirect doesn't trigger exe.config file to be regenerated #9773

Stalli opened this issue Feb 23, 2024 · 6 comments · Fixed by #11012 · May be fixed by #11411
Assignees
Labels
bug Priority:2 Work that is important, but not critical for the release triaged

Comments

@Stalli
Copy link

Stalli commented Feb 23, 2024

Issue Description

When I add 2 references to 3rd party libraries, which have a version conflict, a bindingRedirect will be automatically added to the config file of the start-up project on the next msbuild.
But when then I remove one of the references, the config file is not regenerated on the next msbuild and still have a bindingRedirect.
A workaround is to call "msbuild /t:Rebuild" explicitly.

Steps to Reproduce

Create a project of the type "Console application" in .Net Framework 4.7.2.
Add a default App.config file.
Add an assembly reference to ServiceStack.Redis.8.0.0 located locally.
Add an assembly reference to System.Runtime.CompilerServices.Unsafe.6.0.0 located locally.
So the csproj file has the following:

<ItemGroup>
        <Compile Include="Program.cs"/>
        <Compile Include="Properties\AssemblyInfo.cs"/>
</ItemGroup>
<ItemGroup>
      <Reference Include="ServiceStack.Redis">
        <HintPath>..\packages\ServiceStack.Redis.8.0.0\lib\net472\ServiceStack.Redis.dll</HintPath>
      </Reference>
      <Reference Include="System.Runtime.CompilerServices.Unsafe">        <HintPath>..\packages\System.Runtime.CompilerServices.Unsafe.6.0.0\lib\net461\System.Runtime.CompilerServices.Unsafe.dll</HintPath>
      </Reference>
    </ItemGroup>
    <ItemGroup>
      <None Include="App.config" />
</ItemGroup>

Execute msbuild in the project folder.

Intermediate result (expected): a file projectName.exe.config has the App.config content plus a bindingRedirect for System.Runtime.CompilerServices.Unsafe.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
  </startup>
  <appSettings></appSettings>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Remove the assembly reference to System.Runtime.CompilerServices.Unsafe.6.0.0.
Execute msbuild in the project folder.
ConsoleApplication472.zip

Expected Behavior

projectName.exe.config file should be regenerated and have no bindingRedirects. It should only contains the content of the original App.config file.

Actual Behavior

projectName.exe.config's content remains unchanged (it was not regenerated from the previous msbuild call). It contains a bindingRedirect.

Analysis

No response

Versions & Configurations

MSBuild version 17.9.5+33de0b227 for .NET Framework
17.9.5.7608

.Net Framework tested: 4.7.2 and 4.8

@Stalli Stalli added bug needs-triage Have yet to determine what bucket this goes in. labels Feb 23, 2024
@AR-May AR-May added Priority:2 Work that is important, but not critical for the release triaged and removed needs-triage Have yet to determine what bucket this goes in. labels Feb 27, 2024
@ladipro
Copy link
Member

ladipro commented Feb 27, 2024

May be caused by or at least related to #8749.

@YuliiaKovalova YuliiaKovalova self-assigned this Feb 29, 2024
@JaynieBai JaynieBai assigned GangWang01 and unassigned GangWang01 Sep 3, 2024
@JaynieBai
Copy link
Member

JaynieBai commented Sep 26, 2024

I repro this issue when build (not rebuild ) the project when remove the reference. And I think it's related with #10644

@JaynieBai
Copy link
Member

JaynieBai commented Oct 23, 2024

@YuliiaKovalova This issue is since @(SuggestedBindingRedirects)' == '' after remove the assembly reference. The task GenerateBindingRedirects won't be executed. Next It should copy the App.config to ConsoleApplication472.exe.config. But the target _CopyAppConfigFile is skipped since Skipping target "_CopyAppConfigFile" because all output files are up-to-date with respect to the input files.. It means that there is no change after removing the assembly reference.
Should we update the task GenerateBindingRedirects to let it generate new config file even if there is no suggested assembly reference?

Here is binlog msbuild.binlog.txt

@rainersigwald
Copy link
Member

Reactivating because I'm about to revert #11012.

@YuliiaKovalova
Copy link
Member

YuliiaKovalova commented Feb 3, 2025

to return the fix we need to exclude the new logic from DTB by adding $(DesignTimeBuild)' != 'true'
@JaynieBai could you please do that and check if if doesn't break the scenario #11362 ?

@JaynieBai
Copy link
Member

to return the fix we need to exclude the new logic from DTB by adding $(DesignTimeBuild)' != 'true' @JaynieBai could you please do that and check if if doesn't break the scenario #11362 ?

@YuliiaKovalova It works after add '$(DesignTimeBuild)' != 'true'. It will block copy \work\VSSDK-Analyzers\obj\test\Microsoft.VisualStudio.SDK.Analyzers.Tests\Debug\net472\Microsoft.VisualStudio.SDK.Analyzers.Tests.exe.withSupportedRuntime.config” to “C:\work\VSSDK-Analyzers\obj\test\Microsoft.VisualStudio.SDK.Analyzers.Tests\Debug\net472\Microsoft.VisualStudio.SDK.Analyzers.Tests.exe.config" in the design time.

Image

@JaynieBai JaynieBai linked a pull request Feb 10, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Priority:2 Work that is important, but not critical for the release triaged
Projects
None yet
7 participants