Comments on: AutoMapper for Silverlight 3.0 Alpha http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/ Strong opinions, weakly held Fri, 17 May 2013 09:02:38 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Philip Laureano http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/#comment-2205 Philip Laureano Sat, 20 Mar 2010 21:59:32 +0000 /blogs/jimmy_bogard/archive/2010/02/18/automapper-for-silverlight-3-0-alpha.aspx#comment-2205 LinFu.DynamicProxy now has a SL3 port: http://is.gd/aQGB2 You can change it back from Castle now :) LinFu.DynamicProxy now has a SL3 port:

http://is.gd/aQGB2

You can change it back from Castle now :)

]]> By: Kelly Brownsberger http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/#comment-2204 Kelly Brownsberger Tue, 02 Mar 2010 18:29:16 +0000 /blogs/jimmy_bogard/archive/2010/02/18/automapper-for-silverlight-3-0-alpha.aspx#comment-2204 Wow - I did the same (CopyLocal=true + Nant + the SL build of nunit) and it worked for me as well - TD.NET is happy, Nant is happy, and Kelly is happy :) Now I'm really confused by what statlight is intended to solve Wow – I did the same (CopyLocal=true + Nant + the SL build of nunit) and it worked for me as well – TD.NET is happy, Nant is happy, and Kelly is happy :)

Now I’m really confused by what statlight is intended to solve

]]> By: Kelly Brownsberger http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/#comment-2203 Kelly Brownsberger Tue, 02 Mar 2010 16:04:02 +0000 /blogs/jimmy_bogard/archive/2010/02/18/automapper-for-silverlight-3-0-alpha.aspx#comment-2203 Thanks Jimmy What's not clear to me is if all the various test runners are capable of loading and running Silverlight assemblies (obviously there needs to be a SL compatible framework/metadata assembly for you testing framework of choice), then why does statlight need to exist? My understanding was it was created as a way to running tests and ultimately invoked the browser under the covers. All this is really confusing... just needed to rant :) You getting it to work is inspiring though - I'm going to keep plugging. Thanks again -kelly Thanks Jimmy

What’s not clear to me is if all the various test runners are capable of loading and running Silverlight assemblies (obviously there needs to be a SL compatible framework/metadata assembly for you testing framework of choice), then why does statlight need to exist? My understanding was it was created as a way to running tests and ultimately invoked the browser under the covers.

All this is really confusing… just needed to rant :)

You getting it to work is inspiring though – I’m going to keep plugging. Thanks again -kelly

]]> By: bogardj http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/#comment-2202 bogardj Tue, 02 Mar 2010 13:39:31 +0000 /blogs/jimmy_bogard/archive/2010/02/18/automapper-for-silverlight-3-0-alpha.aspx#comment-2202 @Kelly I'm using the regular NAnt NUnit task to build. I had to bundle the SL 3.0 assemblies as part of my source tree, and select "CopyLocal" to true for my SL projects for the system dll's. This made sure that the correct system.dll was used, instead of some GAC version. I have no idea how it's working, other than I was getting real test failures in all of my test runners tested (R#, TD.NET, NAnt). I did talk to the statlight guys, and we're talking with the teamcity.codebetter folks to see if we can't get that working on my build server. @Kelly

I’m using the regular NAnt NUnit task to build. I had to bundle the SL 3.0 assemblies as part of my source tree, and select “CopyLocal” to true for my SL projects for the system dll’s. This made sure that the correct system.dll was used, instead of some GAC version.

I have no idea how it’s working, other than I was getting real test failures in all of my test runners tested (R#, TD.NET, NAnt).

I did talk to the statlight guys, and we’re talking with the teamcity.codebetter folks to see if we can’t get that working on my build server.

]]> By: Kelly Brownsberger http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/#comment-2201 Kelly Brownsberger Tue, 02 Mar 2010 12:16:54 +0000 /blogs/jimmy_bogard/archive/2010/02/18/automapper-for-silverlight-3-0-alpha.aspx#comment-2201 I'm trying to get our Silverlight code and accompanying unit test code running w/ our CCNET builds and I'm running into some pain. Forgive my ignorance, but how are you running w/ via NAnt? I followed the links to the NUnitSilverlight build, but it's just a custom build of nunit.framework.dll and nunit.silverlight.dll. It's not clear to me what is loading these and how it's running the tests. This [1] was linked off of the NunitSilverlight blog announcement, which makes me believe this can be done w/ a full .NET process, but according to Jamie's comments he "some ilasm / ildasm tricks and I never got around to automating it". When I try to load up a Silverlight Class Library dll with references to these nunit dll's and try to run it from the full nunit.exe for 2.5.1, I get poopoo'ed (as expected) with failure to load assembly exceptions. What am I missing here? The fact statlight [2] exists leads me to believe I can run my test with the traditional runners, or did they author not now about some trick? Wow - a little surprising this is so difficult :( Any advice would be appreciated [1] http://weblogs.asp.net/nunitaddin/archive/2008/05/01/silverlight-nunit-projects.aspx [2] http://statlight.codeplex.com/ I’m trying to get our Silverlight code and accompanying unit test code running w/ our CCNET builds and I’m running into some pain. Forgive my ignorance, but how are you running w/ via NAnt? I followed the links to the NUnitSilverlight build, but it’s just a custom build of nunit.framework.dll and nunit.silverlight.dll. It’s not clear to me what is loading these and how it’s running the tests. This [1] was linked off of the NunitSilverlight blog announcement, which makes me believe this can be done w/ a full .NET process, but according to Jamie’s comments he “some ilasm / ildasm tricks and I never got around to automating it”. When I try to load up a Silverlight Class Library dll with references to these nunit dll’s and try to run it from the full nunit.exe for 2.5.1, I get poopoo’ed (as expected) with failure to load assembly exceptions.

What am I missing here? The fact statlight [2] exists leads me to believe I can run my test with the traditional runners, or did they author not now about some trick?

Wow – a little surprising this is so difficult :( Any advice would be appreciated

[1] http://weblogs.asp.net/nunitaddin/archive/2008/05/01/silverlight-nunit-projects.aspx
[2] http://statlight.codeplex.com/

]]> By: Chris Tavares http://lostechies.com/jimmybogard/2010/02/19/automapper-for-silverlight-3-0-alpha/#comment-2200 Chris Tavares Sat, 20 Feb 2010 18:37:04 +0000 /blogs/jimmy_bogard/archive/2010/02/18/automapper-for-silverlight-3-0-alpha.aspx#comment-2200 We had similar concerns when building the Silverlight version of Unity. We chose to avoid partial compilation; I started having flashbacks to my Unix days and gigantic tangles of #ifdefs. What we did instead was to segregate the code by file. Every file in the codebase is either just filename.cs (goes in both), filename.Desktop.cs (desktop CLR only) or filename.Silverlight.cs (silverlight version only). The silverlight .csproj file does the same thing you do - it's all linked files, but it omits linking the .Desktop files and includes the .Silverlight ones. And the reverse for the desktop version. Then, we made the classes that had to vary across platform partial classes. So for some types, you'll have <class>.cs and <class>.Desktop.cs and <class>Silverlight.cs. The main file would have the invariant stuff with the partial keyword on it, and the other two would have the variations. Between this and using partial methods to get a hook into the other methods when needed, it worked out quite well. Probably overkill if you've got only a small amount of variation, but it worked well for us and is probably easier to manage if things get bigger. We had similar concerns when building the Silverlight version of Unity. We chose to avoid partial compilation; I started having flashbacks to my Unix days and gigantic tangles of #ifdefs. What we did instead was to segregate the code by file. Every file in the codebase is either just filename.cs (goes in both), filename.Desktop.cs (desktop CLR only) or filename.Silverlight.cs (silverlight version only). The silverlight .csproj file does the same thing you do – it’s all linked files, but it omits linking the .Desktop files and includes the .Silverlight ones. And the reverse for the desktop version.

Then, we made the classes that had to vary across platform partial classes. So for some types, you’ll have .cs and .Desktop.cs and Silverlight.cs. The main file would have the invariant stuff with the partial keyword on it, and the other two would have the variations. Between this and using partial methods to get a hook into the other methods when needed, it worked out quite well.

Probably overkill if you’ve got only a small amount of variation, but it worked well for us and is probably easier to manage if things get bigger.

]]>