Hi, your error message is completely different to the one reported in this
3 year old thread.
The compiler will usually give you that error when the referenced assembly
is actually marked as being compiled with a newer framework via the
TargetFrameworkAttribute.
I'd make sure you've got the
I've got the same kind of a problem, but with Casle.Core. Yet my solution
doesn't compiles at all when calling (re)build solution, but still can be
compiled one-by-one project.
Here's the VS build output:
> 1>C:\Program Files
>
Obviously, Jono is right.
While I verified that compiling in .net 4 mode emits different code than .net
4.5 mode (thus ruling out any mistake on our part) WIndsor 3.2.1 for .net 4
does indeed do the right thing, therefore rendering my suspicion that something
in our build configuration might
Krzysztof I took your word for it the other day that the .NET 4.0 binaries
were compiled wrong, but after decompiling them with dotPeek I can't
reproduce what you saw. Both the binaries in castle.windsor.3.2.1.nupkg and
both the binaries in a local compile are as I expected.
Miles and Krzysztof
Unfortunately I didn't have much luck getting much more time to look deeper
into it on Tuesday. However, I've got it starred to look into it on the
weekend.
On Thu, Sep 26, 2013 at 2:33 PM, Krzysztof Koźmic
krzysztof.koz...@gmail.com wrote:
Any luck with that?
On 24/09/2013 5:08 PM, Jonathon
Any luck with that?
On 24/09/2013 5:08 PM, Jonathon Rossi j...@jonorossi.com wrote:
Sorry for the delayed reply, I've been on leave.
That is strange. Looking at the build logs for the last master build of
the 4.0 and 4.5 build configurations it is picking the right mscorlib when
calling csc,
Sorry for the delayed reply, I've been on leave.
That is strange. Looking at the build logs for the last master build of the
4.0 and 4.5 build configurations it is picking the right mscorlib when
calling csc, so I'd have expected the 4.0 one to fail compilation, unless
that bit isn't actually
Thanks Krzysztof,
I'll downgrade for the moment.
Cheers,
On Saturday, 21 September 2013 00:05:29 UTC+1, Krzysztof Koźmic wrote:
Hey Miles,
very interesting. It would appear you're correct. The call to
Environment.CurrentManagedThreadId is part of the compiler-generated state
machine
Hi,
I upgraded a .net 4.0 project that was working fine to the latest packages
I could get from nuget:
package id=Castle.Core version=3.2.0 targetFramework=net40 /
package id=Castle.Windsor version=3.2.1 targetFramework=net40 /
The project builds and runs fine from the command line. I
Hey Miles,
very interesting. It would appear you're correct. The call to
Environment.CurrentManagedThreadId is part of the compiler-generated state
machine (notice yield return in the method).
If you install Windsor 3.2 (instead of 3.2.1 that you're currently using) it
works fine, so that may
10 matches
Mail list logo
