search

paolosalvatori / ServiceBusExplorer

The Service Bus Explorer allows users to connect to a Service Bus namespace and administer messaging entities in an easy manner. The tool provides advanced features like import/export functionality or the ability to test topic, queues, subscriptions, relay services, notification hubs and events hubs.
MIT License
2.02k stars 588 forks source link

Can't purge Dead Letter Queue Messages (and maybe not normal Messages) #540

Closed sivisal closed 3 years ago

sivisal commented 3 years ago

Version 5.0.2

Connect to service bus in Azure Expand Topics Find topic with Dead letters Right-click and select Purge Dead Letter Queue Messages This pop-ups in the log:

<15:54:13> Exception: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) I have recently got a new computer, where I have just copied over my folder with Service Bus Explorer. Don't know if that has anything to do with it.
SeanFeldman commented 3 years ago

Expand Topics Find topic with Dead letters Right-click and select Purge Dead Letter Queue Messages

Topics don't have messages to be purged. Do you mean you can't purge dead-lettered messages from subscriptions? In that case, is this a duplicate of #541? Thank you.

sivisal commented 3 years ago

You're right - it must be the subscription, not topic - sorry, I just look at the Service Bus - other people know how it actually works :-)

It might be a duplicate. I'm not very familiar with the code (and I'm not a developer), so I'm just going to guess, that it's a duplicate.

ErikMogensen commented 3 years ago

To me it looks like an assembly load failure, similar to #525. The message purging is one of the few places in Service Bus Explorer where it uses the latest Service Bus SDK. That SDK uses a lot of assemblies. It is possible that one or more of those have been put in the GAC causing Service Bus Explorer to load the assembly from the GAC instead.

If you want to find out, set up FusLogVw as described in #525. If you want help with the analysis of the log, put it in this thread.

ErikMogensen commented 3 years ago

It might also be that some required assembly is missing. A log from FusLogVw should tell us.

sivisal commented 3 years ago

Is it correctly understood, that I need to install Visual Studio in order to get FusLogVw, or can I do something smaller than VS?

ErikMogensen commented 3 years ago

I hope not. There is an solution mentioned at https://stackoverflow.com/a/34075957/6850500. Most likely you need to update the path for newer Windows and .NET Versions. On my machine it is located in C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64.

In case it requires that Windows SDK is installed it is described further down on that StackOverflow page how to configure assembly load logging without fuslogvw.

Greybird commented 3 years ago

You might want to take a look at https://github.com/awaescher/Fusion also, which seems a good alternative, but it might not solve potential SDK setup needs.

paolosalvatori commented 3 years ago

@2ndcahl did you solve your problem? Did you miss any assembly? Did you find the root cause?

sivisal commented 3 years ago

I have not had time to look at the problem yet, but I have it on my to-do list. I will keep you posted.

sivisal commented 3 years ago

Hi. I have now got some more logging, using FusLogViwer

*** Assembly Binder Log Entry  (01-06-2021 @ 11:29:35) ***

The operation failed.
Bind result: hr = 0x80131040. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  C:\Tools\Service Bus Explorer\ServiceBusExplorer.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///C:/Tools/Service Bus Explorer/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ServiceBusExplorer.exe
Calling assembly : System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Tools\Service Bus Explorer\ServiceBusExplorer.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Tools/Service Bus Explorer/System.Runtime.CompilerServices.Unsafe.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Tools\Service Bus Explorer\System.Runtime.CompilerServices.Unsafe.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: System.Runtime.CompilerServices.Unsafe, Version=4.0.5.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
ErikMogensen commented 3 years ago

I logged a purge using v5.0.2 on my computer and I see similar complaints about that assembly in the log. However, the purge works and there is no exception in the Service Bus window log.

Perhaps your Windows/.NET or anti-virus has some kind of policy which does not accept loading mismatched assemblies. There was an automatic warning about one of the Nuget packages that needed upgrading due to a security issue, which was done. Please try 5.0.3 and see if that makes a difference. If 5.0.4 has been released, try that one instead.

sivisal commented 3 years ago

Just tried some more and I got it working. Seems like I might be doing something wrong when I update SBE as I have just downloaded a fresh 5.0.3 without copying any configuration files into the new version. Maybe a breaking difference of the configuration files from SBE 4 to 5? I copy Properties.xml and ServiceBusExplorer.exe.Config, but should I only copy Properties.xml ?

ErikMogensen commented 3 years ago

@2ndcahl, good thing you found it. Do not copy servicebusExplorer.exe.config, only extract the section and copy it to the new one. You know that since a version 4.x release you can store the namespace settings and other things in a file in your user profile?

sivisal commented 3 years ago

@ErikMogensen I have been looking at option to store the configuration in my User Profile and might change to that. The reason I have not is that I have SBE on my OneDrive so the configuration is shared between my computers and backed up if anything happened to my computer. Not very important information, just nice that it is setup from the get-go.

I will close this issue as an Error 40 ;-)

eugen-nw commented 8 months ago

I'd fixed the original problem in version 5.0.18 by adding the section below into the C:\ProgramData\chocolatey\lib\servicebusexplorer\tools\ServiceBusExplorer.exe.config file. I'd say that this is a bug that should be fixed.

      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.4.1" newVersion="4.0.6.0" />
      </dependentAssembly>
IanKemp commented 4 months ago

I'd fixed the original problem in version 5.0.18 by adding the section below into the C:\ProgramData\chocolatey\lib\servicebusexplorer\tools\ServiceBusExplorer.exe.config file. I'd say that this is a bug that should be fixed.

      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.4.1" newVersion="4.0.6.0" />
      </dependentAssembly>

For maximum compatibility you should set the upper oldVersion bound appropriately:

<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-4.0.6.0" newVersion="4.0.6.0" />
  </dependentAssembly>
</assemblyBinding>
eugen-nw commented 4 months ago

I did the change @IanKemp suggested, thanks very much!

ErikMogensen commented 4 months ago

I checked the 5.0.18 and the 6.0.0 releases on GitHub and they have:

<dependentAssembly>
    <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.6.0" newVersion="4.0.6.0" />
</dependentAssembly>

and:

<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>

respectively. Therefore, I assume you were using a config file from an older release which may cause problems. We haven't provided any update instructions so this is a common issue. I recommend that you configure the tool to store settings and connection string in the User Configuration File. That way those settings are kept between upgrades.