TypeLoadException: NEventStore.MongoPersistance v5.0

danielHalan commented 10 years ago

Hi,

Seems to be an issue when Azure.Host scans assemblies, TypeLoadException in ScanAssembliesForEndpoints(). Had similar issue in my ServiceBus MQ Manager, when loading assemblies that have abstract classes. one way would be to just catch and exclude those types, as they probably wont contain IConfigureThisEndpoint.

btw, the scanning is working when using on-premise NSB.Hosting.exe

{"Method 'GetFrom' in type 'NEventStore.Persistence.MongoPersistence.MongoPersistenceEngine' from assembly 'NEventStore.Persistence.MongoPersistence, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.":"NEventStore.Persistence.MongoPersistence.MongoPersistenceEngine"}

yvesgoeleven commented 10 years ago

Can you send me a repro please? (ideally both the azure and on-prem test), as the scanner is the same for both I see no reason for it to blow or not blow dependent on the host it is sitting in. I can only imagine that the azure host has a wrong reference after the build because of how the project has been built.

danielHalan commented 10 years ago

Created a new project, Cut n Paste from one of the Failing ones, and removed Commands and internal references.
Made sure same version of NEventStore is referenced.
Run. OK

Checked again in the other solution, and Inspecting, assemblyScanner.GetScannableAssemblies().Assemblies, where I find that the "NEventStore.Persistence.MongoPersistence.dll" is missing (which contain the class it can not find an implementation for), while the other two NEventStore dlls are there
Now compare all external Libraries, saw that MongoDB driver was 1.8.3 in the new project.
Upgraded MongoDB driver in all projects to 1.8.3
Retry, and still same TypeLoadException.
Used AsmSpy.exe to see what files/versions NEventStore.Persistence.MongoPersistence.dll does reference to, and to my surprise its 1.8.1 (the version I used before), the complete references (except std sys) are, NEventStore and MongoDB.Bson, MongoDB.Driver (1.8.1.20)

Is there any other reason NEventStore.Persistence.MongoPersistence.dll would not be found by the Scanner?

yvesgoeleven commented 10 years ago

Can you place a breakpoint when the ReflectionTypeLoadException is thrown and look in the LoaderExceptions property on the thrown exception instance. That property should contain a description of why it couldn't be loaded

danielHalan commented 10 years ago

Thats the description on top of this thread,

danielHalan commented 10 years ago

Have compared all file versions in both output folders (the one that works and the one that doesn't), and they all match.

yvesgoeleven commented 10 years ago

Maybe the versions match, but that doesn't mean it's the same assembly, can you check that MongoPersistenceEngine class using reflector or dotpeek in both bin folders and validate that they both have that method implemented.

danielHalan commented 10 years ago

Checking the Code for NServiceBus.Hosting.Windows for differences (NSB 4.1.1) and see that the MustRef's are commented out,

   //TODO: re-enable when we make message scanning lazy
   //assemblyScanner.MustReferenceAtLeastOneAssembly.Add(typeof(IHandleMessages<>).Assembly);
   //assemblyScanner.MustReferenceAtLeastOneAssembly.Add(typeof(IConfigureThisEndpoint).Assembly);
   //assemblyScanner.MustReferenceAtLeastOneAssembly.Add(typeof(Program).Assembly);
   assemblyScannerResults = assemblyScanner.GetScannableAssemblies();

danielHalan commented 10 years ago

Think the Problem is that the "assemblyScanner.GetScannableAssemblies().Assemblies" doesn't contain the NEventStore.Persistence.MongoPersistence.dll, while it found the NEventStore.dll

yvesgoeleven commented 10 years ago

Oh now I get it, the regular host is not using the assemblyscanner... sneaky guys... that explains the difference, Now to figure out why MongoPersistence is not picked up by the new one

yvesgoeleven commented 10 years ago

I've opened an issue for this on the main repo, this is an issue with the new assembly scanner, better to track it there

danielHalan commented 10 years ago

Maybe we could verify that theory if you could send me a special build with those lines commented out

yvesgoeleven commented 10 years ago

I think you can trick the scanner though by using a type from the missing assembly in your assembly that contains your endpoint.

danielHalan commented 10 years ago

Didn't help. DLL still not loaded.

danielHalan commented 10 years ago

How do I 'make' a correct build from the src, is there any ilmerges / scripts that I can't find.. as the VS produced DLL has version 0.0.0.0

danielHalan commented 10 years ago

Some progress, I've changed the output version to 4.2.1, added Reference to NSB 4.2 and now tried again, got it working as far as into the Console, but now the Emu keeps killing the processes in an indefinite loop, (ending up with alot of processes) and this is what the Output (in Verbose) states over and over again,

[runtime] Role entrypoint . CALLING OnStart() [runtime] Role entrypoint . COMPLETED OnStart() [runtime] Role entrypoint . CALLING Run() [runtime] Role entrypoint . COMPLETED Run() ==> ROLE RECYCLING INITIATED [runtime] Role instance recycling is starting [runtime] Role entrypoint . CALLING OnStop() [runtime] Role entrypoint . COMPLETED OnStop() [fabric] Role state Stopping [fabric] Role state Busy [runtime] Role entrypoint . CALLING OnStart()

yvesgoeleven commented 10 years ago

I see that behavior when the ServiceRuntime assembly version does not match the VS Tooling version, 4.2.1 requires tooling from SDK 2.2. (In vnext I decoupled from ServiceRuntime to solve this dependency)

danielHalan commented 10 years ago

OK, the Cloud solution is SDK 2.2, See that there is a Windows Azure Service Bus v2.2.1.1 that can be updated from v2.1.4.0, but when trying it says NSB.Azure 4.2.1 doesnt support it.. so guess its not part of SDK2.2 (Would be easier if MS Synced the versions of WindowsAzure.* DLLs with the SDK :)

Ive downloaded the master, where you have decoupled the Dependencies to Azure Libs, but seems as NServiceBus.RoleEntryPoint has been refactored to NServiceBusRoleEntrypoint, with no methods to override. is it still being under development?

yvesgoeleven commented 10 years ago

Azure Servicebus 2.2 released a bit later (I will update develop today), and it will also be in vnext.

To decouple from ServiceRuntime I had to make a breaking change, as we inherited from Azure.RoleEntryPoint, that inheritance had to go. Now you have to do the following: https://github.com/Particular/NServiceBus.Azure.Samples/blob/develop/VideoStore.AzureServiceBus.Cloud/VideoStore.ContentManagement/WorkerRole.cs

danielHalan commented 10 years ago

Ok, crashing now on, private readonly NServiceBusRoleEntrypoint nsb = new NServiceBusRoleEntrypoint();

at, SafeRoleEnv...cs :92

setting = (string)roleEnvironmentType.GetMethod("GetConfigurationSettingValue").Invoke(null, new object[] { name });

Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironmentException was unhandled _HResult=-2147467259 _message=error HResult=-2147467259 IsTransient=false Message=error Source=Microsoft.WindowsAzure.ServiceRuntime StackTrace: at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.ErrorIfFailed(Int32 hr) at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(String configurationSettingName) InnerException: NULL

danielHalan commented 10 years ago

"An exception of type 'Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironmentException' occurred in Microsoft.WindowsAzure.ServiceRuntime.dll and wasn't handled before a managed/native boundary"

yvesgoeleven commented 10 years ago

Can you see which text is in the RoleEnvironmentException?

danielHalan commented 10 years ago

just says "error"

yvesgoeleven commented 10 years ago

Damn, that doesn't say a lot... Can you see which key was passed to it?

danielHalan commented 10 years ago

seems as the key name is prominent on what key is missing, ie if I remove all keys, it will fail on first, I add, and it fails on next key name

yvesgoeleven commented 10 years ago

Do your serviceruntime assembly version and tools version match up? Both should be 2.2

danielHalan commented 10 years ago

Microsoft.WindowsAzure.Configuration - 2.0.0.0 Microsoft.WindowsAzure.Diagnostics - 2.2 Microsoft.WindowsAzure.ServiceRuntime - 2.2 Microsoft.WindowsAzure.Storage - 2.1.0.0 Microsoft.ServiceBus - 2.1.0.0

yvesgoeleven commented 10 years ago

That all looks fine, any chance you can zip this up including binaries and send to me by email?

danielHalan commented 10 years ago

send me a line, to first name dot last name at itq dot com

yvesgoeleven commented 10 years ago

I don’t think this issue has anything to do with nservicebus.

If I put the following 2 lines of code in a regular console app (with no reference to nsb)

MongoPersistenceFactory f = new MongoPersistenceFactory("SystemEventStore", new DocumentObjectSerializer());
f.Build();

Using following packages

<package id="mongocsharpdriver" version="1.8.3" targetFramework="net45" />
<package id="NEventStore" version="4.1.0.10" targetFramework="net45" />
<package id="NEventStore.Persistence.MongoPersistence" version="5.0.0.9" targetFramework="net45" />

I get the exact same issue

Can you open a call with the NEventStore guys, I’m afraid I have no knowledge of what is exactly going on (I don’t see a call to GetFrom in the Build method, so something must be going on behind the scene’s)

Particular / NServiceBus.Azure

TypeLoadException: NEventStore.MongoPersistance v5.0 #70