Nservicebus: ILMerged/Costura seems to prevent pipeline from building

[janpieterz]

Though with the flag scanner.ScanAppDomainAssemblies = true; one would assume it scans the assemblies in the app domain, the pipeline itself won't be sufficiently build up when, for example, the final exe is merged and the redundant assemblies have been removed from the final directory.

The NServiceBus assemblies have been loaded (confirmed in Debug->Modules) at the time of the endpoint.Start(), but the following exception is thrown:
https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Pipeline/PipelineModelBuilder.cs#L96

To replicate, see this repository: https://github.com/janpieterz/NServiceBus-Pipeline-Error-V6.2/commits/master

There are two substantial commits, the 2nd commit (time) works, the CleanReferenceCopyLocalPaths target is not installed (though it's replicatable by removing the dll's manually).
The 3rd commit breaks by default when running.

[andreasohlund]

Can you see if there are stages available?

We've seen cases where type comparisons start to fail when Costura is involved. Would you be able to change https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Pipeline/PipelineModelBuilder.cs#L96 to compare on type.FullName and not the type it self?

[janpieterz]

Any idea how I can easily step into this?

It runs in NSB host, so might need to get that repo and run that? I'll see if I can make some time available.

[janpieterz]

Sorry, not running in NSB host at all for this endpoint ;)

On Thu, 6 Apr 2017 at 09:58, Andreas Öhlund [e-mail]
wrote:

Can you see if there are stages
https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Pipeline/PipelineModelBuilder.cs#L82
available?

We've seen cases where type comparisons start to fail when Costura is
involved. Would you be able to change
https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Pipeline/PipelineModelBuilder.cs#L96
to compare on type.FullName and not the type it self?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/4598#issuecomment-292098228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXakif8r7ACBXEoMWlyd7fUPuMSe31aks5rtJsYgaJpZM4M0MZU
.

>

Met vriendelijke groet,

Jan-Pieter Zoutewelle

[andreasohlund]

Don't worry @janpieterz I've been able to run your repro, will report back my findings soon

[andreasohlund]

Found the issue, when Costura is used our scanner can no longer find any types so we can't find any features to activate and that causes the exception you're hitting.

Not sure we can support this at all, what's your use case for Costura?

[janpieterz]

Ease of deployment for certain endpoints that run on premise at customers
(aka deploying a whole load of dll's becomes more manual effort, while
deploying one .exe is very simple). Also for some internal tools we drop
them into single exes, but these could be expanded.

Things to note are that this endpoint used to work in V5 (encountered this
during upgrade) with Costura.

Could I manually load the assemblies into the app domain? Not the nicest
but at least it works.

On Thu, 6 Apr 2017 at 11:04, Andreas Öhlund [e-mail]
wrote:

Found the issue, when Costura is used our scanner can no longer find any
types so we can't find any features to activate and that causes the
exception you're hitting.

Not sure we can support this at all, what's your use case for Costura?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/4598#issuecomment-292113243,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXakqCoa8jN6EAhrHXORwrCXgENE1rQks5rtKqQgaJpZM4M0MZU
.

>

Met vriendelijke groet,

Jan-Pieter Zoutewelle

[andreasohlund]

Why not Ilmerge them?

[janpieterz]

Yeah, that would be the alternative, but would obviously cost some time to
implement over all the endpoints and the build processes.

Not something you guys will pick up as it's regressed from the scanning in
V5?

On Thu, 6 Apr 2017 at 11:12, Andreas Öhlund [e-mail]
wrote:

Why not Ilmerge them?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Particular/NServiceBus/issues/4598#issuecomment-292115252,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXakkL6fjW4KSMHX0Ifzx5ahwxNBYOSks5rtKyPgaJpZM4M0MZU
.

>

Met vriendelijke groet,

Jan-Pieter Zoutewelle

[andreasohlund]

We have some ideas, stay tuned cc @timbussmann

[andreasohlund]

@janpieterz I didn't realized that we supported this in v5. We'll fix this, see https://github.com/Particular/NServiceBus/pull/4603

What's your timeline? (when would you need the fix)

[janpieterz]

No rush at all for this, for our internal tools we've disabled Costura, and for the on premise deployment it would be relevant in two months.

[andreasohlund]

Seems just about right since we should have a 6.3.0 ready in that timeframe

[andreasohlund]

@Particular/nservicebus-maintainers I've added this to the 6.3.0 milestone

[timbussmann]

@janpieterz with the 6.3 release, using ScanAppDomainAssemblies should now also work with assemblies inlined via costura. If you're interested in verifying this, we're happy to help you testing this with an unstable build.

I'm closing this issue for now., but if you're encountering any issues, please let us know. Thanks a lot for raising this!