LOG: DisplayName = System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51

Question

I'm encountering a similar problem, but with a more recent version. I receive an error stating "System.Diagnostics.DiagnosticSource, Version=6.0.0.0," although Azure.Core utilizes version 6.0.0.1. When I downgrade my NuGet package from 6.0.0.1 to 6.0.0.0, I encounter a different error: "Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.4.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'." Attempting to switch from version 6.0.0.0 to 4.0.4.0 results in a compatibility issue with "Azure.Core" and "Azure.Storage.Blobs," which do not support System.Diagnostics.DiagnosticSource, Version=4.0.4.0. Despite having consistent references to version 6.0.0.1 in both my web.config and the app.config of my new DLL, the error persists.

<dependentAssembly>
        <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.1" newVersion="6.0.0.1" />
</dependentAssembly>

=== Pre-bind state information === LOG: DisplayName = System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 (Fully-specified) LOG: Appbase = file:///D:/System/testsystem/ LOG: Initial PrivatePath = D:\System\testsystem\bin Calling assembly : Azure.Storage.Blobs, Version=12.19.1.0, Culture=neutral, PublicKeyToken=92742159e12e44c8.
LOG: This bind starts in default load context. LOG: Using application configuration file: D:\System\testsystem\web.config LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Post-policy reference: System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/4a4892e4/1a9eb44/System.Diagnostics.DiagnosticSource.DLL. WRN: Comparing the assembly name resulted in the mismatch: Revision Number ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. DATE/TIME: 11/21/2023 10:53:57 PM

Answer 1

@@Nelson Hernandez I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

Issue: Facing an issue with a recent version of a software package, receiving an error related to "System.Diagnostics.DiagnosticSource, Version=6.0.0.0." Despite attempting to resolve it by downgrading the NuGet package to version 6.0.0.0, a new error arises, mentioning "System.Diagnostics.DiagnosticSource, Version=4.0.4.0." Trying to switch to this version results in compatibility issues with other packages, specifically "Azure.Core" and "Azure.Storage.Blobs." The user has provided configuration details from web.config and app.config, showing an attempt to redirect from version 0.0.0.0-6.0.0.1 to version 6.0.0.1. The issue persists, and the error log indicates a failure in setting up the assembly.

Solution: The problem was with the recognition of <dependentAssembly> tags in the web.config, causing the new DLL to malfunction. This was attributed to the presence of namespace attributes within the <configuration> tag, leading to the oversight of the <assemblyBinding> tag. The issue was resolved by removing these attributes, ensuring that the assembly classes were recognized correctly and enabling proper redirection to the correct DLLs.

---

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

Answer 2

@Nelson Hernandez Apologies for the delay response!

It looks like you are encountering a version conflict issue with the System.Diagnostics.DiagnosticSource assembly. The error message indicates that the Azure.Storage.Blobs assembly is trying to load version 6.0.0.0 of the System.Diagnostics.DiagnosticSource assembly, but your application is referencing version 6.0.0.1.

One possible solution to this issue is to add a binding redirect to your application's configuration file to redirect requests for version 6.0.0.0 of the System.Diagnostics.DiagnosticSource assembly to version 6.0.0.1. You have already added a binding redirect to your configuration file, but it looks like it may not be working correctly.

To troubleshoot this issue, you can try the following steps:

1. Check that the binding redirect is correctly specified in your configuration file. Make sure that the oldVersion and newVersion attributes are set correctly(Ensure that you are using the latest versions of the Azure.Storage.Blobs and Azure.Core packages. Check for updates on NuGet and update your packages accordingly.)
2. Check that the configuration file is being loaded correctly by your application. You can try adding a test setting to the configuration file and verifying that your application is able to read the setting correctly.
3. Try clearing your application's cache and restarting the application. It's possible that the old version of the System.Diagnostics.DiagnosticSource assembly is still cached by your application and is causing the issue.
4. Check Azure.Core Version Compatibility:Confirm that the versions of Azure.Storage.Blobs and Azure.Core you are using are compatible. Some versions of these libraries are designed to work together, and updating one may require updating the other.
5. Verify Azure SDK Compatibility:Check if your project's target framework is compatible with the Azure SDK version you are using. Sometimes, compatibility issues arise due to framework versions.
6. Review Azure SDK Release Notes:Check the release notes for Azure SDK packages, including Azure.Storage.Blobs and Azure.Core, for any specific guidance on assembly versioning or known issues.
7. Clean and Rebuild:Clean your solution and rebuild it to ensure that the latest versions of the assemblies are correctly referenced
8. Remove Specific Version Attribute: In your web.config, remove the specific version attribute from the bindingRedirect:

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.1" newVersion="6.0.0.1" />
</dependentAssembly>

Use Probing in Web.config: Add a probing element in your web.config to specify the directory where the correct version of the assembly is located:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <probing privatePath="bin" />
  </assemblyBinding>
</runtime>

Please let us know if you have any further queries. I’m happy to assist you further.     

---

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 3

I discovered the solution: The issue was that the <dependentAssembly> tags in the web.config were not being recognized, preventing the new dll from functioning correctly. This was due to the <configuration> tag containing namespace attributes, which resulted in the <assemblyBinding> tag being overlooked.

Incorrect configuration: <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

Correct configuration: <configuration>

After correcting this, the assembly classes were read properly, allowing me to direct the system to the correct dlls.