Hi,
I updated our existing projects to 6.0, and now they show warnings "Found conflicts between different versions of the same dependent assembly. Please set the 'AutoGenerateBindingRedirects' property to true in the project file."
After checking the checkbox "Auto-Generate binding redirects" in the project, the warning is gone.
You set this checkbox also in the demo projects (e.g. "SnippetsParser"). The previous 5.1 sample did not have set this option. So I assume you noticed this problem, too.
I assume that it is caused be "Microsoft.CodeAnalyis.FlowAnalysis.Utilities" 2.9.5.0, which references "Microsoft.CodeAnalysis"2.9.0.0 => thats a strange circular reference, as "Microsoft.CodeAnalyses.Features" 3.4.0.0 references the "...FlowAnalysis..." file AND "Microsoft.CodeAnalysis"3.4.0.0.
Do you have any idea about this? As it is Roslyn code, you probably don't have a chance to fix this.
Wolfgang
Don't think that this version mismatch is the reason - I changed the reference version in the textfile created by "ildasm", then rebuild the DLL with "ilasm" => did not help.
Switching Visual Studio output to "detailed" does not provide helpful information, either.
Hope you have an idea.
Wolfgang
Switching Visual Studio output to "detailed" does not provide helpful information, either.
Hope you have an idea.
Wolfgang
Hi Wolfgang,
We tried to reproduce this problem, but without success. Any chance you could send us cut-down version of your project so we can look at it? Alternatively we can setup remote debug session to troubleshoot the problem
Regards,
Andrew
We tried to reproduce this problem, but without success. Any chance you could send us cut-down version of your project so we can look at it? Alternatively we can setup remote debug session to troubleshoot the problem
Regards,
Andrew
Hi Andrew,
I did not change much to the sample ;-).
I copied the directory "C:\Users\Public\Documents\AlterNET Software\AlterNET Studio v.6" to "C:\Temp\AlterNET Studio v.6_modified", opened the solution "AlterNET.Studio.AllDemos.sln", and modified the settings in project "SnippetsParser": I unchecked the checkbox "Auto-generate binding redirects", see screenshot "changedsetting.png".
This results in the above mentioned warning.
Screenshot and detailed build log can be found in https://www.hg-online.de/downloads/AlterNetReferencesWarning.zip
On my machine, I have the latest Visual Studio update 16.5.4, and hopefully the latest win updates. Also, AlternetStudio 4.0, 5.1 and 6.0 are installed.
It seems some references e.g. ("netstandard") are resolved to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll" (AssemblyFileVersion: 4.6.26011.1, AssemblyVersion: 2.0.0.0), while others are picked from nuget packages.
In our "real" project, we did not use NuGet, but I copied the AlterNet files locally, and all other references are resolved to the locally installed Framework.
Best regards
Wolfgang
I did not change much to the sample ;-).
I copied the directory "C:\Users\Public\Documents\AlterNET Software\AlterNET Studio v.6" to "C:\Temp\AlterNET Studio v.6_modified", opened the solution "AlterNET.Studio.AllDemos.sln", and modified the settings in project "SnippetsParser": I unchecked the checkbox "Auto-generate binding redirects", see screenshot "changedsetting.png".
This results in the above mentioned warning.
Screenshot and detailed build log can be found in https://www.hg-online.de/downloads/AlterNetReferencesWarning.zip
On my machine, I have the latest Visual Studio update 16.5.4, and hopefully the latest win updates. Also, AlternetStudio 4.0, 5.1 and 6.0 are installed.
It seems some references e.g. ("netstandard") are resolved to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll" (AssemblyFileVersion: 4.6.26011.1, AssemblyVersion: 2.0.0.0), while others are picked from nuget packages.
In our "real" project, we did not use NuGet, but I copied the AlterNet files locally, and all other references are resolved to the locally installed Framework.
Best regards
Wolfgang
Interesting: with build log Level = "Normal", I found an interesting info (first line):
1> No way to resolve conflict between "System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". Choosing "System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" arbitrarily.
1> Consider app.config remapping of assembly "Microsoft.CodeAnalysis, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "2.9.0.0" [] to Version "3.4.0.0" [C:\Temp\AlterNET Studio v.6_modified\Demo\packages\Microsoft.CodeAnalysis.Common.3.4.0\lib\netstandard2.0\Microsoft.CodeAnalysis.dll] to solve conflict and get rid of warning.
1> Consider app.config remapping of assembly "System.Collections.Concurrent, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.10.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades\System.Collections.Concurrent.dll] to Version "4.0.11.0" [C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Collections.Concurrent.dll] to solve conflict and get rid of warning.
,...
This is followed by a lot of other "Consider app.config remapping..." hints, but the "System.ValueTuple.dll" seems to be the issue.
You provide 4.0.2.0, and I have installed the same Version in C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib
Best regards
Wolfgang
1> No way to resolve conflict between "System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". Choosing "System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" arbitrarily.
1> Consider app.config remapping of assembly "Microsoft.CodeAnalysis, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "2.9.0.0" [] to Version "3.4.0.0" [C:\Temp\AlterNET Studio v.6_modified\Demo\packages\Microsoft.CodeAnalysis.Common.3.4.0\lib\netstandard2.0\Microsoft.CodeAnalysis.dll] to solve conflict and get rid of warning.
1> Consider app.config remapping of assembly "System.Collections.Concurrent, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.10.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades\System.Collections.Concurrent.dll] to Version "4.0.11.0" [C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Collections.Concurrent.dll] to solve conflict and get rid of warning.
,...
This is followed by a lot of other "Consider app.config remapping..." hints, but the "System.ValueTuple.dll" seems to be the issue.
You provide 4.0.2.0, and I have installed the same Version in C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib
Best regards
Wolfgang
I worked around the warning by adding a bunch of binding redirects to app.config, see below.
Probably the check "auto generate..." does the same. But I prefer not setting the checkbox - up to now there was always something wrong when this warning occured in our projects.
So the question is: why does it happen here?
Below is just a snippet, full file at https://www.hg-online.de/downloads/AlterNetAppConfig.zip
....
Probably the check "auto generate..." does the same. But I prefer not setting the checkbox - up to now there was always something wrong when this warning occured in our projects.
So the question is: why does it happen here?
Below is just a snippet, full file at https://www.hg-online.de/downloads/AlterNetAppConfig.zip
....
Hi Wolfgang,
The problem seems to be caused by the .NET Standard reference assemblies having a “placeholder” version of "0.0.0.0". See https://github.com/dotnet/standard/issues/490
At the same time, some assemblies are referencing exact versions of these assemblies (like System.ValueTuple you mentioned).
Such situations and others require binding redirects. Starting from .NET Framework 4.5.1, Microsoft sets AutoGenerateBindingRedirects project property to "true" by default for desktop application projects. See https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection?redirectedfrom=MSDN
This seems to be a measure to address these problems automatically, as usually a programmer has no better way to resolve them in comparison to what AutoGenerateBindingRedirects does.
Also see these links:
https://stackoverflow.com/questions/46111749/adding-a-bindingredirect-to-a-net-standard-library/46120907#46120907
https://stackoverflow.com/questions/44844798/could-not-load-file-or-assembly-system-valuetuple-version-0-0-0-0-or-one-of-i
https://stackoverflow.com/questions/45978173/system-valuetuple-version-0-0-0-0-required-for-add-migration-on-net-4-6-1-cla
To summarize, you can make the binding redirects manually in your app.config if you want more control, but AutoGenerateBindingRedirects does it automatically good enough ofr the majority of cases.
Regards,
Andrew
The problem seems to be caused by the .NET Standard reference assemblies having a “placeholder” version of "0.0.0.0". See https://github.com/dotnet/standard/issues/490
At the same time, some assemblies are referencing exact versions of these assemblies (like System.ValueTuple you mentioned).
Such situations and others require binding redirects. Starting from .NET Framework 4.5.1, Microsoft sets AutoGenerateBindingRedirects project property to "true" by default for desktop application projects. See https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection?redirectedfrom=MSDN
This seems to be a measure to address these problems automatically, as usually a programmer has no better way to resolve them in comparison to what AutoGenerateBindingRedirects does.
Also see these links:
https://stackoverflow.com/questions/46111749/adding-a-bindingredirect-to-a-net-standard-library/46120907#46120907
https://stackoverflow.com/questions/44844798/could-not-load-file-or-assembly-system-valuetuple-version-0-0-0-0-or-one-of-i
https://stackoverflow.com/questions/45978173/system-valuetuple-version-0-0-0-0-required-for-add-migration-on-net-4-6-1-cla
To summarize, you can make the binding redirects manually in your app.config if you want more control, but AutoGenerateBindingRedirects does it automatically good enough ofr the majority of cases.
Regards,
Andrew
Thanks for the reply!
I feared already that this is something that you cannot influence - seems it is "broken by design" in the framework. But as your component triggered the warning, you were the one to ask first ;-).
So I will add a long list of files to "app.config" (instead of settings the checkbox).
While doing so, I found that in one project I had upgraded only part of the AlterNET dlls - and the "conflicts" warning pointed me to it. So, this proves me true in not setting the checkbox ;-).
Best regards
Wolfgang
I feared already that this is something that you cannot influence - seems it is "broken by design" in the framework. But as your component triggered the warning, you were the one to ask first ;-).
So I will add a long list of files to "app.config" (instead of settings the checkbox).
While doing so, I found that in one project I had upgraded only part of the AlterNET dlls - and the "conflicts" warning pointed me to it. So, this proves me true in not setting the checkbox ;-).
Best regards
Wolfgang
To finalize this: on customer machines, the directory "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib" does not exist on Client machines, and thus the app will crash.
Simple Workaround: copy all DLLs from this Directory to the application Directory.
Better: copy all files to a subdir (e.g. "netstandard2") and add this to app.config:
...
Now it works for me.
Simple Workaround: copy all DLLs from this Directory to the application Directory.
Better: copy all files to a subdir (e.g. "netstandard2") and add this to app.config:
...
Now it works for me.