MSTest & NHibernate

[Patrick Earl]

For some reason (perhaps related to the use of ilmerge in NHibernate
3.1), there is now an exception being thrown in the relinq code.

This post on the nhusers list has the details:

https://groups.google.com/group/nhusers/browse_thread/thread/c7729f6d56dc022f?hl=es

I tried to file an issue, but I don't have an account.

Confusingly, the issue doesn't seem to happen all the time.

It seems like the easiest place to fix it would be in the code where
it actually throws the exception.

Thoughts?

Patrick Earl

[Fabian Schmied]

Hi Patrick,

> For some reason (perhaps related to the use of ilmerge in NHibernate
> 3.1), there is now an exception being thrown in the relinq code.

re-linq contains the following code:

// typeof (object).Assembly.GetName() will throw an exception in medium trust.
// Therefore, scan references to detect the referenced framework version.
var mscorlibReference =
Assembly.GetExecutingAssembly().GetReferencedAssemblies().Single (name
=> name.Name == "mscorlib");
var referencedFrameworkVersion = mscorlibReference.Version;

This code is safe because the re-linq assembly (returned by
Assembly.GetExecutingAssembly()) will always contain exactly one
reference to mscorlib. This is true even when using a .NET 3.5 build
from .NET 4.0. The only way to break it is to somehow "customize" the
re-linq assembly so that it has two references to mscorlib at the same
time.

We've just tried out using the current merged NHibernate/re-linq (via
nhforge), and we couldn't reproduce the reported exceptions, not even
from MSTest. The merged DLL has only one reference to mscorlib. I can
only imagine that the person who originally reported the issue has
some custom build, post-build-step, instrumentation, or similar that
causes the duplicate references.

I've nonetheless added a feature request to our JIRA:
"https://www.re-motion.org/jira/browse/RM-3832". The code is easy for
us to replace, so you can expect build 1.13.100 of re-linq (to be
released on Friday) to contain the change.
I'd still recommend double-checking the setup of the person who
reported the problem.

> I tried to file an issue, but I don't have an account.

On our JIRA Dashboard, you can click "register here" to get an account
so you can file issues.

Regards,
Fabian

[Patrick Earl]

Thanks for looking at this Fabian. I'll reply to the users thread and
point people here.

It was reported by at least two users, and they indicate that it's
only when running MSTest from the build server that problems are
observed... some MSTest.exe thing? I'm actually completely unfamiliar
with MSTest myself. I still get the feeling there's something odd
going on, but it does seem to be quite an edge case. Hopefully just
picking the first one won't lead to some sort of version strangeness.

I didn't visit the dashboard before, I only ended up in JIRA via some
other link... the regular login screen just says "contact an
administrator to request an account." Thanks for pointing out how to
get an account.

Patrick Earl

[Michael Ketting]

Yeah, that's Jira for you. I've now patched our installation to make it more intuitive (I hope) with useful messages. And by 'patched' I do mean the jar-files and jsps... Now every login form should direct you towards our user management form.

Michael

[Nicholas Blumhardt]

Hi Patrick/Fabian - thanks for following up on this.

I share your suspicions that there's some edge case at work; just to
rule out one possibility - we don't have any kind of special build/
postbuild setup going on. Our MSBuild and Team Build (test) setups are
vanilla.

Though I see from the Jira issue that it is probably too late :)
perhaps the way to avoid further confusion by selecting the First() is
to use Max(a => a.Version) or something similar.

If we track down any more information I'll post it here. Thanks again!

Cheers,
Nick

On Mar 30, 4:14 am, Michael Ketting <michael.kett...@rubicon.eu>
wrote:

[Fabian Schmied]

Hi Nick,

> I share your suspicions that there's some edge case at work; just to
> rule out one possibility - we don't have any kind of special build/
> postbuild setup going on. Our MSBuild and Team Build (test) setups are
> vanilla.

That's really strange. Maybe the code calling GetExecutingAssembly
gets inlined by the JIT compiler to some place that references two
mscorlibs? Never mind, though because...

> Though I see from the Jira issue that it is probably too late :)
> perhaps the way to avoid further confusion by selecting the First() is
> to use Max(a => a.Version) or something similar.

... I've found a better alternative to the code in question and have
already adapted it.

> If we track down any more information I'll post it here. Thanks again!

Although the code has already been removed, I'd be very interested if
you find out the reason for the duplicate references.

Regards,
Fabian