windsor 3.0 in a web environment

[Shawn Hinsey]

Hello,

I was wondering if there was a good write up somewhere of the impact of the changes that were made in how lifestyles work in Windsor 3.0 on how you use Windsor in the context of an ASP.NET MVC app. I'm a little fuzzy on precisely what the implications of these changes are because I haven't been following this list or the dev list as closely as I usually do.

Thanks in advance,

Shawn

[Krzysztof Koźmic]

I'm not sure what you mean by that.

Windsor's lifestyle is orthogonal to ASP.NET MVC

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.

[Shawn Hinsey]

My impression is that there are changes to how lifestyles work, which might impact the PerWebRequestLifestyle and how that's wired into the infrastructure. E.g., do I need to use BeginScope/EndScope somewhere or is that all taken care of for me?

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

Nope,

from user's perspective it just works like it used to.
BeginScope is for ScopedLifestyle. PerWebRequest requires no intervention from the user (not even XML goo in web.config is required anymore).

Krzysztof

[Shawn Hinsey]

Sorry, I meant something like using(container.BeginScope) { ... } rather than BeginScope/EndScope.

[Shawn Hinsey]

Thanks, I just wasn't clear on that. I am having an endlessly frustrating time with an assembly versioning issue with the 2.5.x series and am contemplating upgrading to 3.x, but I've been out of the loop for awhile.

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

what assembly versioning issue?

@K

[Shawn Hinsey]

Oh, I'm not certain it's even being caused by Windsor. We have a fairly complex app with a lot of moving parts. 

During the process of figuring out how we wanted to package it up for nuget, we started running into issues where the 2.5.3 nuget package would somehow end up asCastle.Windsor.dll version 2.5.1 when it was installed by our package. We're upgrading to 2.5.4 to see if that resolves it because the app makes fairly extensive use of type forwarding and it's not a clean upgrade to 3.x. 

While that's going on, I'm looking into what other issues we might run into if we decided to just ditch 2.5.x and make the switch.

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

what assembly versioning issue?

@K

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To post to this group, send email to castle-project-users@googlegroups.com.
To unsubscribe from this group, send email to castle-project-users+unsub...@googlegroups.com.

[Krzysztof Koźmic]

Windsor 2.5.x all have AssemblyVersion 2.5.1 (to allow drop in replacement without recompiling every dependency). Look at file version or description to see which version you have. It will say something like: Castle.Windsor 2.5.4 for .NETFramework v4.0

@K

On 11/02/2012 9:07 AM, Shawn Hinsey wrote:

Oh, I'm not certain it's even being caused by Windsor. We have a fairly complex app with a lot of moving parts. 

During the process of figuring out how we wanted to package it up for nuget, we started running into issues where the 2.5.3 nuget package would somehow end up asCastle.Windsor.dll version 2.5.1 when it was installed by our package. We're upgrading to 2.5.4 to see if that resolves it because the app makes fairly extensive use of type forwarding and it's not a clean upgrade to 3.x. 

While that's going on, I'm looking into what other issues we might run into if we decided to just ditch 2.5.x and make the switch.

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

what assembly versioning issue?

@K

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.

[Shawn Hinsey]

Ah, interesting. The way that this problem presented itself wasn't specifically tied to the assembly version, we just thought it might be the likely culprit.

Specifically what was happening was, relatively out of nowhere, we started getting the "type cannot be loaded" exception from the PerWebRequestLifestyle even though we could physically verify that the assemblies were in the bin directory. 

Does this ring any bells? As I said, it's totally possible something else is causing this problem, but we've been going in circles for awhile and have been unable to make a firm declaration.

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

The only thing I can think of is that you ended up with Client Profile version of the assembly which doesn't have the web stuff in it.

@K

[Shawn Hinsey]

Hmm, interesting, I hadn't considered that. What's the quickest test for that?

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

Assembly title will be "Castle.Windsor 2.5.4 for .NETFramework v4.0 Client Profile"

@K

[Shawn Hinsey]

Wow, I should've asked the list a lot sooner. You nailed it. I appreciate it, you've saved me and my colleague who knows how much more grief on this.

Now to figure out how it's getting there...

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

[Krzysztof Koźmic]

cheers :)

@K

[Shawn Hinsey]

This is definitely a weird one. I went through and checked every project in the sln and none of them had references to the client profile assembly, so I went in and removed it from the package directory in packages, cleaned the solution, and then built it. After that I was able to verify that the assembly in bin was not client profile. Next, I did a crtl-f5 to start the project that exhibited the problem, and after it compiled, the client profile version is back. Does this make any sense or ring any bells?

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

cheers :)

@K

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To post to this group, send email to castle-project-users@googlegroups.com.
To unsubscribe from this group, send email to castle-project-users+unsub...@googlegroups.com.

[Krzysztof Koźmic]

Nah,

Unless you have some customizations to your build process or some leftovers from previous builds I can't see any reason for that.

Did you remove all your /bin  and /obj folders?

@K

On 11/02/2012 10:08 AM, Shawn Hinsey wrote:

This is definitely a weird one. I went through and checked every project in the sln and none of them had references to the client profile assembly, so I went in and removed it from the package directory in packages, cleaned the solution, and then built it. After that I was able to verify that the assembly in bin was not client profile. Next, I did a crtl-f5 to start the project that exhibited the problem, and after it compiled, the client profile version is back. Does this make any sense or ring any bells?

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>

cheers :)

@K

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.

To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.

[Shawn Hinsey]

Well, I resolved the problem. I wish I could say I knew precisely what was causing it, but at least it's fixed. I appreciate the help. I've been working with .NET for 10+ years and this is among the strangest things I've ever seen, without question. 

2012/2/10 Krzysztof Koźmic <krzyszto...@gmail.com>